Target locking method and apparatus, device, and medium

Abstract

This application relates to a target locking method, apparatus, device, and medium. The method includes: generating a three-dimensional locking region for a player character in a game scene; acquiring pointing operation information corresponding to a player's pointing operation event; updating the locking orientation of the three-dimensional locking region based on the pointing operation information, and calculating the spatial angle and spatial distance between the interactive object within the three-dimensional locking region and the center of the region; selecting candidate lockable interactive objects from among the interactive objects whose spatial angle is within a preset generalization angle, and then selecting the candidate lockable interactive object with the smaller spatial distance as the final locked interactive object. This application improves game operation efficiency and judgment accuracy by optimizing the target locking mechanism, enhancing the player's operating experience and immersion, while ensuring game compatibility and smoothness across multiple devices.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a target locking method, apparatus, device, and medium thereof. Background Technology

[0002] In traditional role-playing and action games, such as massively multiplayer online role-playing games (MMORPGs) with large open worlds, soft target locking is widely used to assist players in selecting and tracking targets in complex combat environments. Traditional implementations typically rely on automatically attracting the nearest enemy unit within a fixed cone or sphere. This judgment logic is relatively static and lacks comprehensive consideration of player intentions, the three-dimensional structure of the battlefield, and differences in target types. In actual gameplay, this mechanism easily leads to frequent target jumps, missed attacks, and severe camera shake. Especially in scenarios with elevation differences or multi-target battles, players often fail to accurately hit their intended targets due to system misjudgments, thus affecting the combat rhythm and operational experience. This makes target tracking easily interrupted during high-speed combos or movement-based attacks, weakening the fluidity and immersion of the combat.

[0003] As players' demands for gaming experience continue to rise, a more user-friendly lock-on mechanism is needed to lower the operational threshold and improve combat accuracy and smoothness. Therefore, there is an urgent need for a soft lock-on method to solve the aforementioned problems and optimize the player's gaming experience. Summary of the Invention

[0004] The purpose of this application is to solve the above-mentioned problems by providing a target locking method and corresponding apparatus, devices, non-volatile readable storage media, and computer program products.

[0005] According to one aspect of this application, a target locking method is provided, comprising: Generate a 3D locked area for the player character in the game scene; Obtain pointing operation information corresponding to the player's pointing operation event, wherein the pointing operation information includes one of the following: controller direction information, player character orientation information, camera orientation information, and player skill aiming direction information; The locking orientation of the three-dimensional locking area is updated according to the pointing operation information, and the spatial angle and spatial distance between one or more interactive objects in the three-dimensional locking area and the center of the three-dimensional locking area are calculated. Candidate lockable interactive objects are selected from the interactive objects whose spatial angle is within a preset generalization angle, and then the candidate lockable interactive objects with smaller spatial distances are selected as the final lockable interactive objects.

[0006] According to another aspect of this application, a target locking device is provided, comprising: The locked area generation module is set to generate a 3D locked area for the player character in the game scene. The pointing operation acquisition module is configured to acquire pointing operation information corresponding to the player's pointing operation event, wherein the pointing operation information includes one of the following: controller direction information, player character orientation information, camera orientation information, and player skill pre-aiming direction information; The angle distance calculation module is configured to: update the locking orientation of the three-dimensional locking area according to the pointing operation information, and calculate the spatial angle and spatial distance between one or more interactive objects in the three-dimensional locking area and the center of the three-dimensional locking area; The interactive object locking module is configured to: select candidate lockable interactive objects from each of the interactive objects whose spatial angle is within a preset generalization angle, and then select the candidate lockable interactive objects with smaller spatial distances as the final lockable interactive objects.

[0007] According to another aspect of this application, a non-volatile readable storage medium is provided, which stores a computer program implemented according to the target locking method in the form of computer-readable instructions, wherein the computer program, when invoked by a computer, executes the steps included in the method.

[0008] According to another aspect of this application, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the method.

[0009] The traditional soft-lock mechanism in games often uses a static, fixed range to automatically attract the nearest target. This lack of comprehensive judgment regarding player intent, the three-dimensional battlefield, and target type easily leads to problems such as target jumping, missed attacks, and tracking interruptions, severely impacting combat smoothness and the user experience. This application addresses these issues by providing an innovative solution, whose beneficial effects are mainly reflected in the following aspects: First, this application effectively solves the target misjudgment problem caused by the fixed cone or spherical range in traditional soft locking mechanisms by constructing a three-dimensional locking area centered on the player character and dynamically updating the locking orientation of this area in conjunction with pointing operation information. This three-dimensional locking area is composed of a combination of circles and fans, and is stretched into a three-dimensional space by vertical height parameters. It can accurately adapt to complex battlefield environments containing terrain with elevation differences, aerial units, or underground structures, avoiding the inclusion of irrelevant objects in the target acquisition range, and significantly improving the spatial accuracy and scene adaptability of target selection.

[0010] Secondly, this application introduces dual quantitative indicators of spatial angle and spatial distance in the target selection process, and sets a generalization angle as a tolerance threshold. This allows the system to intelligently select the most suitable interactive object for the current combat situation while respecting the player's operational intentions. When multiple targets are within the generalization angle range, the target with the smaller spatial distance is prioritized as the final lock target. This ensures the rationality of the locking result and avoids target jumps caused by slight directional deviations, thereby significantly enhancing the hit rate of skill release and the consistency of operational feedback.

[0011] Furthermore, this application establishes the entire locking logic on configurable geometric parameters and dynamic input sources, enabling all calculations to be completed locally on the terminal without relying on server synchronization, thus ensuring low-latency response and high frame rate smoothness. Attached Figure Description

[0012] Figure 1 This application provides an exemplary network architecture; Figure 2 A flowchart illustrating one embodiment of the target locking method of this application; Figure 3 This is a schematic block diagram of the target locking device of this application; Figure 4 This is a schematic diagram of the target locking device used in this application. Detailed Implementation

[0013] The technical solution of this application can be widely applied to various network architectures to adapt to different types and scales of game applications. In a network architecture such as... Figure 1 In the typical network architecture shown, the player's terminal device accesses the game service cluster via the network. This cluster consists of multiple game servers 81. A microservice architecture manages and maintains the runtime resources of these game servers 81, providing multiple service instances. Each service instance is responsible for a different service. For example, some service instances can be used to maintain the front-end service for the terminal device 80 to access the game, while others can each be responsible for the gameplay service of one or more maps in the game's world map, providing players with corresponding map instance gameplay. The player's terminal device 80 has a computer program product implemented according to the target locking method of this application installed and running, or the terminal device can be connected to a cloud server container, where the computer program product runs. After the computer program product runs, it accesses the game service cluster, allowing the player to control their in-game character through the terminal device, interact with various service instances of the game, and explore and interact with different maps.

[0014] Each service instance can maintain a real-time connection with the player's terminal device 80 via the network, handling various events and interactions in the game, such as player character movement, attacks, and item usage. The server provides necessary data support to the terminal device to ensure smooth game operation. This data includes, but is not limited to, map model datasets, which contain map model data for each map and resource model data for its scene resources, such as buildings, player character models, non-player character models, and various other creature or non-creature models, used by the terminal device 80 to render and generate corresponding real-time images. Based on the received map model dataset, the terminal device 80 can generate high-quality real-time images and display them in the graphical user interface, presenting the corresponding game scene to the player. Players obtain visual information about the game through real-time images of the game scene, thereby implementing gameplay.

[0015] This application not only applies to the gaming experience for single players but can also be extended to multiplayer online game environments. In multiplayer games, multiple players' (users') terminal devices simultaneously connect to the game service cluster. Each service instance needs to handle interaction requests from multiple players and update the game status in real time. This application ensures that each player receives consistent and high-quality target locking in multiplayer game scenarios, while optimizing the resource utilization of servers and terminal devices and improving the overall operational efficiency of the game system.

[0016] In an exemplary application scenario of this application, consider a massively multiplayer online role-playing game (MMORPG) where players can freely explore a vast open-world map and control their character to enter various specific dungeon maps to complete quests. In this game, the player character can frequently switch between different maps, such as switching from a bustling city map to a mysterious dungeon map, or from one room to another.

[0017] One exemplary application scenario of this application is a game client, which can also work in conjunction with a server. During game operation, when a player triggers a dodge operation, the client generates a corresponding dodge space model based on the character's dodge path. The dodge space model mentioned in this application can be a scalable collider based on the character's movement path, and its size and shape can be adjusted according to game design requirements. At the same time, the game engine tracks attack behaviors in the current game scene in real time. These attack behaviors typically have corresponding attack collision models used to determine the range of influence of the attack.

[0018] The term "system" as used in this application may refer to a collection of software and hardware environments on the game client and / or server side, used to implement various functions of the game. It includes components such as game engine, physics system, collision detection module, special effects rendering module, and audio system. These components work together to process player input, execute game logic, update game state, generate visual and auditory feedback, and provide players with an interactive experience.

[0019] Please see Figure 2 The target locking method of this application, in some embodiments, includes the following steps: Step S11: Generate the 3D locked area of ​​the player character in the game scene: When generating the aforementioned 3D locking region in a game scene, it first relies on a set of configurable geometric parameters, generally referred to as locking region configuration information. This information defines the spatial shape and extent of the locking region. This region is not a simple sphere or cone, but a composite two-dimensional planar region composed of a circular region and a fan-shaped region, further stretched vertically to form a three-dimensional volume. The circular region is centered on the player character's location, with its radius specified by the "circular radius" parameter in the locking region configuration information, used to cover near-range targets in all directions around the character. The fan-shaped region has the same center as its vertex, and its axis of symmetry is usually aligned with a reference direction (such as the camera's orientation, the character's facing direction, or the joystick input direction). The fan angle determines the width of the opening to the left and right, while the fan radius controls the maximum detection distance in that direction. This composite structure allows the system to respond to targets at a relatively long distance directly in front of the character while also taking into account near-range threats around them, avoiding the blind spots that exist in the sides and rear of traditional pure fan-shaped solutions.

[0020] After constructing this two-dimensional composite region, the entire region is stretched along the vertical axis of the world coordinate system based on the region's vertical height information, defined by the "upper height" and "lower height" parameters in the locked region configuration information. Specifically, starting from each point on the two-dimensional plane, the system extends upwards to the Z-axis offset defined by the upper height and downwards to the negative Z-axis offset defined by the lower height, thus forming a vertically bounded three-dimensional space. The cross-section of this three-dimensional space is the union of the aforementioned circle and sector, and its height range is independent of the horizontal plane, allowing the system to distinguish between air units, ground units, and underground structures. For example, when facing an interactive object in the air, the upper height can be set to 2500 cm to ensure that the controlled interactive object is included in the target acquisition range; while in ordinary ground combat, the lower height can be set to 1500 cm to exclude interference from irrelevant underground objects (such as non-interactive terrain models). This vertical height separation mechanism significantly improves the target selection accuracy in the three-dimensional battlefield.

[0021] The center of the 3D target lock area is generally not directly located at the player character's feet or the model's origin. Instead, it is offset backward by a fixed distance (e.g., 2.5 meters) based on the character's orientation. This offset direction is consistent with the currently used reference orientation (e.g., the camera's yaw direction). This design is called back offset processing, and its purpose is to solve the problem of the character's own model obscuring close-range targets. If the area center is directly below the character, enemies within 1 meter in front of the character may be eliminated because they are inside the character's collision area. Back offset, however, places the starting point for ray or angle calculations behind the character, allowing the line of sight to naturally pass through the space in front of the character, thus reliably capturing targets within melee range. This offset amount can be configured globally and differentiated for different characters or skills. For example, larger characters can use a larger back offset distance to match their visual center.

[0022] All of the above parameters can be dynamically configured through external data tables, adapting to different combat needs without modifying the program logic. For example, a player character with ranged attack capabilities can be configured with a smaller circular radius (e.g., 1000 cm), a larger fan-shaped radius (e.g., 5000 cm), and a wider fan-shaped angle (e.g., 120 degrees) to focus on distant targets in front; while a player character with melee attack capabilities can be configured with a larger circular radius (e.g., 3000 cm), a smaller fan-shaped radius (e.g., 2000 cm), and a narrower fan-shaped angle (e.g., 60 degrees) to emphasize overall defense and rapid reaction. In addition, certain special skills can temporarily override the default parameters. For example, a 360-degree AOE skill (Area of ​​Effect) can have its fan-shaped angle set to 360 degrees, equivalent to using only a circular area; while a precise thrust skill can have its circular radius set to 0, retaining only a narrow-angled fan-shaped area for highly directional attacks.

[0023] Besides the combination of circles and sectors, other geometric constructions can be used as alternative implementations for the 3D target locking area. For example, an ellipsoidal model can be used entirely, with its major axis extending along the reference direction and its minor axis controlling the lateral and vertical range; or multiple segmented cones can be pieced together to form an asymmetrical field of view area to simulate the attack coverage characteristics of specific weapons; or a dynamic scaling mechanism can be introduced to adjust the radius and angle in real time according to the player's movement speed or skill charge level. Despite the different construction methods, the core purpose is to define a candidate area in 3D space that is aligned with the player's operational intentions and can effectively filter out invalid targets. In each logical frame, the terminal regenerates this area based on the current character state (position, orientation, input direction) and skill context to ensure that the target acquisition logic is always synchronized with the player's real-time behavior.

[0024] The resulting three-dimensional locking area serves as the spatial benchmark for subsequent angle and distance calculations. Its geometric integrity and parameter flexibility directly determine the accuracy and responsiveness of target selection. This area is not only used for target selection when releasing skills, but also serves various game functions such as soft-lock camera tracking, automatic target acquisition prompts, and enhanced lock-on triggers. It is the basic spatial carrier of the entire target locking system.

[0025] Step S12: Obtain the pointing operation information corresponding to the player's pointing operation event. The pointing operation information includes one of the following: controller direction information, player character orientation information, camera orientation information, and player skill aiming direction information: Acquiring directional operation information corresponding to player pointing actions is a crucial step in the target locking process for capturing player intentions. Player pointing actions refer to events triggered when a user interacts with a player character via a terminal. For example, a user controls a player character to perform basic attacks or release skills using virtual buttons on the terminal or peripheral devices such as a keyboard, mouse, or game controller. During operation, the terminal continuously monitors various input sources and the game state, and extracts one or more directional data points as pointing operation information when specific interactive events occur. This pointing operation information is not fixed but dynamically selected based on the current skill configuration, player input state, and camera behavior to ensure that the adopted direction accurately reflects the player's expected target location when releasing skills or performing a lock-on operation.

[0026] When a player presses the skill button to trigger a skill release event, the terminal first queries the skill's data table and reads the configuration value of its "Start Orientation" field. If this field is set to "Joystick Direction," the terminal immediately samples the offset vector of the current left joystick. This offset vector typically originates from the touch coordinates of the virtual joystick on mobile devices, while on consoles or PCs, it generally comes from the simulated input of the physical joystick on the game controller. Of course, mobile devices can also be connected to a game controller. The terminal maps this offset vector input to the game world's horizontal plane (XZ plane), removes the vertical component, and normalizes it into a unit vector, forming the corresponding controller direction information. For example, if the player pushes the joystick upwards and to the right, the terminal generates a world vector pointing northeast. If the joystick is in a neutral zone (i.e., the offset is less than the dead zone threshold), the terminal will not consider it valid input but will instead revert to the default direction based on the skill configuration, such as the camera's orientation or the character's facing direction, to avoid target acquisition failure due to lack of input.

[0027] If the "Start Orientation" field is configured as "Character Direction," the terminal directly reads the projection vector of the player character's root skeleton or capsule component's forward axis in the world coordinate system as the player character's orientation information. This method is suitable for melee skills that emphasize the character's actual orientation, such as Spinning Slash or Shield Bash, ensuring that the attack is always based on the character's frontal view and is not affected by the camera angle. In some implementations, the character orientation can be further fine-tuned in conjunction with the animation orientation. For example, in rollover or turn animations, the actual forward direction of the animation root motion is used instead of the static model's orientation to improve motion consistency.

[0028] If the "Start Orientation" field is configured as "Camera Orientation," the terminal extracts the observation direction vector from the currently active camera component and projects it onto the horizontal plane to eliminate the influence of pitch angle, thus forming camera orientation information. This method is widely used in third-person perspective ranged attacks or area-of-effect skills, allowing players to naturally guide the skill direction by rotating the camera. For example, in most action games, the direction of arrow shooting is usually based on the camera orientation; players only need to adjust the camera to aim at the enemy to hit them. In this process, the terminal ignores the camera's pitch component, retaining only the yaw direction, ensuring that the 3D locked area always conforms to the ground combat plane.

[0029] For skills that support pre-aiming, the terminal generates pre-aiming direction information for the player's skill. This information is typically generated by an interactive guidance system: after the player presses and holds the skill button, a draggable aiming line or parabolic trajectory appears on the screen, its endpoint determined by the finger swipe or joystick control. The terminal calculates the position vector of this endpoint relative to the player character, projects it onto a horizontal plane, and normalizes it to obtain the final pre-aiming direction. This type of implementation is common in charged throws, area marking, or projectile prediction skills, allowing players to precisely specify the attack landing point before release. For example, during the holding down of a fireball skill, the game interface will display the flight trajectory; the player can slide to adjust the landing point, and when the button is released, the terminal uses this direction as the pointing operation information.

[0030] In addition to the four main sources mentioned above, the terminal can also integrate multi-source information to generate composite pointing directions. For example, in "joystick direction priority" mode, if the player is detected rotating the camera simultaneously, a fine-tuning angle based on the camera's rate of change is superimposed on the joystick direction; or in soft-lock mode, even if the joystick direction is configured, if there is no input on the joystick, it automatically switches to the direction of the currently soft-locked target. Furthermore, certain special states (such as riding, in a vehicle, or being knocked down) may enable dedicated direction logic. For example, when riding, the mount's orientation may replace the character's orientation, or when knocked down, the joystick direction may be disabled and the camera orientation may be forced to be used to ensure consistent operation.

[0031] All the aforementioned directional operation information is generally stored in the form of a three-dimensional unit vector, and the terminal freezes it immediately after acquisition to ensure consistent direction throughout the target acquisition calculation process, unaffected by subsequent input interference. The terminal strictly limits sampling timing, typically performing a valid read only once at the start frame of skill release, the animation keyframe (AN frame), or when the lock button is pressed. This prevents directional drift caused by multi-frame sampling, ensuring that regardless of how the player moves or rotates the camera during the skill animation, the target acquisition direction always remains consistent with the intention of the operation at the moment of release. Figure 1 This ensures the predictability of skill behaviors and the accuracy of operational feedback.

[0032] Step S13: Update the locking orientation of the three-dimensional locking area according to the pointing operation information, and calculate the spatial angle and spatial distance between one or more interactive objects in the three-dimensional locking area and the center of the three-dimensional locking area: After acquiring the pointing operation information, the terminal updates the locking orientation of the 3D locking area based on the pointing operation information, and calculates the spatial angle and spatial distance between one or more interactive objects within the 3D locking area and the center of the 3D locking area. This process first uses the unit direction vector corresponding to the pointing operation information as the new principal axis direction of the 3D locking area. The terminal then rotates the entire composite target-finding space (composed of the previously described circular and fan-shaped locking areas) to align the 3D locking area with the principal axis direction, thereby ensuring that the 3D locking area always covers the direction the player currently intends to focus on. For example, when the player uses the joystick to specify the northeast direction to release a skill, the axis of symmetry of the 3D locking area rotates to the northeast direction in the world coordinate system, focusing the target-finding logic within this 3D locking area.

[0033] After updating the orientation of the 3D locked area, the terminal iterates through all interactive entities in the current game scene. This includes interactive objects such as hostile monsters, destructible mechanisms, neutral creatures, and static gathering points, and checks each one to determine if it falls within the updated 3D locked area. The determination process is divided into two dimensions: horizontal and vertical. Horizontally, the terminal checks whether the target's position falls within a circular locked area (with the area's center as the center and the circle's radius as the radius) or a sector-shaped locked area (with the area's center as the vertex, the sector's radius as the side length, and the sector's angle as the subtended angle). Vertically, the terminal verifies whether the target's Y-coordinate (or Z-coordinate, depending on the coordinate system definition) lies between the area's center height minus the lower height and the area's upper height. Only objects that simultaneously meet both horizontal and vertical conditions are included in subsequent calculations.

[0034] For interactive objects located within the 3D locked area, the terminal performs an initial screening based on a preset locking priority. Locking priorities are typically set by type, for example, hostile combat units (interactive objects that attack the player) > mechanisms (interactive objects in the game scene that can be controlled by the player) > ecological monsters (interactive objects that are attacked by the player but do not attack the player) = collectibles (interactive objects that can be picked up by the player, such as enemy drops or collectable herbs). Hostile combat units can be configured with more granular priorities, such as higher-level or higher-health hostile combat units, typically bosses in the game scene. Priority ranking can be dynamically adjusted in the future through runtime states (such as buffs), but by default, the system only retains the set of objects with the highest priority, referred to as the first set of interactive objects. Based on this, the terminal further checks whether these objects have a valid aggro state towards the player character, i.e., whether they are actively attacking, tracking, marked by skills, or in a combat-active state. Objects with such states are categorized into the second set of interactive objects as candidate targets for actual angle and distance calculations.

[0035] For each second interactive object, the terminal performs two core geometric calculations. First, it calculates the spatial angle: the terminal constructs a position vector pointing from the center of the 3D locked area to the interactive object, performs a dot product operation with the principal axis direction vector of the 3D locked area, and obtains the minimum angle between the two using the inverse cosine function. The result is expressed as an angle. This angle reflects the degree to which the target deviates from the player's intended direction; the smaller the value, the closer it is to the center of the line of sight. Second, it calculates the spatial distance: the terminal directly calculates the 3D Euclidean distance between the center of the area and the root position of the target, serving as a quantitative indicator of the target's distance. These two data points together form the basis for target ranking.

[0036] In its implementation, the center of the 3D locking area is not located at the player character's feet, but rather offset by a fixed distance (e.g., 2.5 meters) in the opposite direction of the player character, forming a "back offset." This ensures that the starting point for angle calculation is behind the player character, allowing the line of sight to naturally pass through the space in front of the player character. This effectively prevents lockable interactive objects that are close to the player character from being excluded due to obstruction by the player character's own collision objects. For example, in a player's melee combo, if an enemy interactive object is only 1 meter away from the player character, and the area center is at the player's feet, the interactive object might be excluded because it is inside the player character's capsule. The back offset moves the calculation starting point backward, ensuring that the interactive object is properly included in the target acquisition range.

[0037] The terminal supports multiple target selection strategies, all based on the calculated spatial angle and distance data. For example, in "joystick direction priority" mode, the system first determines whether the spatial angle of each second interactive object is less than or equal to the generalized angle (e.g., 45 degrees). The generalized angle is a configurable parameter used to define a tolerance cone, within which the angle priority of all targets is considered the same. If multiple second interactive objects are within the generalized angle, the one with the smallest spatial distance is selected; if the distances are also the same, a random selection is made. If no second interactive object is within the generalized angle, it may revert to other rules, such as directly selecting the nearest second interactive object or abandoning target acquisition. In "distance priority" mode, the system ignores the difference in spatial angle between each second interactive object and the player object, directly sorts them in ascending order of spatial distance, and selects the nearest second interactive object, suitable for omnidirectional AOE skills. In "camera orientation priority" mode, even without joystick input, the system still uses the camera direction as the main axis to ensure that remote skills are always aimed at the center area of ​​the screen.

[0038] In addition to the static geometry-based calculations described above, the terminal can also introduce a dynamic weighting mechanism as an extended implementation. For example, speed compensation can be applied to fast-moving second interactive objects, incorporating their predicted positions into the angle calculation; or a temporary angle discount can be given to high-threat second interactive objects (such as a boss casting a skill), making them easier to select. Furthermore, in multi-player collaborative scenarios, interactive objects that have been locked by teammates can be marked as high priority to achieve coordinated target acquisition. All these variations are built upon the basic spatial angle and spatial distance calculations, triggered by external configuration or runtime state, without requiring modification to the underlying algorithm structure.

[0039] The above calculations are performed in real time within each logical frame, ensuring that the candidate interactive objects in the target list are updated instantly as the player moves, the target shifts, the camera rotates, or the input changes. The calculation results are cached in structured data form, including the angle, distance, priority, and aggro status of each candidate target, for subsequent steps to make the final locking decision. This process is entirely completed locally on the terminal, without relying on server synchronization, ensuring low latency and instant feedback.

[0040] Step S14: Select candidate locking interaction objects from the interactive objects whose spatial angle is within a preset generalization angle, and then select the candidate locking interaction objects with smaller spatial distances as the final locking interaction objects. The terminal reads the currently configured generalization angle parameter, which is usually in degrees. This parameter indicates that within a range extending halfway to the left and right of the main axis direction defined by the operation information, the included angle priority of all interactive objects is considered equal. For example, if the generalization angle is set to 60 degrees, targets within 30 degrees to the left and right of the main axis direction are considered to be within the effective tolerance range. The terminal traverses all interactive objects located within the 3D locking area, comparing their calculated spatial included angles with the generalization angle, and includes targets with included angles less than or equal to the generalization angle into the candidate locked interactive object set.

[0041] For the selected candidate lockable interactive objects, the terminal performs a secondary sorting based on spatial distance. The terminal reads the three-dimensional Euclidean distance value of each candidate object, which was calculated in the previous step and represents the straight-line distance from the center of the three-dimensional lockable area to the location of the interactive object. The system sorts the candidate objects in ascending order of distance. If multiple candidate objects have the same minimum distance, a decision is made according to preset secondary rules, such as randomly selecting by ID order or retaining the target with higher priority. Finally, the candidate lockable interactive object with the smallest distance is confirmed as the final locked interactive object, and the system stores its relevant information (such as unique ID, location coordinates, and type identifier) ​​in the current lock status variable for use by subsequent skill releases, camera tracking, or other interaction logic.

[0042] For example, when a player pushes the joystick to release a skill, the system uses the joystick direction as the main axis. If there are two targets in front: target A (angle 15 degrees, distance 3000 cm) and target B (angle 25 degrees, distance 2800 cm), and the generalization angle is 45 degrees, then both targets are within the tolerance range, and the system selects target B, which is closer, as the final target. If target C (angle 50 degrees, distance 2000 cm) exists, it is excluded even though it is the closest target because its angle exceeds the generalization angle range.

[0043] The terminal also supports implementations that dynamically adjust the generalization angle. For example, when the player object is moving, the system can automatically increase the generalization angle (e.g., from 45 degrees to 75 degrees) to tolerate directional deviations caused by movement input; when stationary, the angle is reduced to improve accuracy. In high-difficulty modes, the system can set the generalization angle to 0 degrees, requiring the player to precisely aim at the target to trigger lock-on, increasing the operational challenge. In addition, certain special skills can temporarily override the global generalization angle setting, such as the precision sniping skill using a very small angle (5 degrees), while the crowd control skill uses a very large angle (120 degrees).

[0044] For handling boundary conditions, the terminal has minimum and maximum distance thresholds. If the distance to all candidate objects exceeds the maximum distance threshold (e.g., beyond skill range), the system will not select any target and may prompt the player that the distance is too far. If the distance to the nearest target is less than the minimum distance threshold (e.g., too close to the character), the system may prioritize targets that are slightly farther away but still within the effective range to avoid attack detection issues caused by being too close. In the boundary handling of target disappearance, if the currently locked target suddenly leaves the 3D locking area, the system can immediately start a new round of screening, or execute after a short delay, giving the target a chance to return. These refined boundary handling measures ensure that the locking logic maintains stable and reasonable behavior even under various extreme conditions.

[0045] After selecting the final locked interaction target for the player, various subsequent processing logics can be executed to enhance locking stability and interactive intelligence. When the final locked interaction target experiences an object elimination event, such as when the final locked interaction target's health reaches 0 and it is judged as dead, the terminal immediately cancels the object lock on that final locked interaction target and can decide whether to automatically trigger a new round of target acquisition to find a replacement for the final locked interaction target, depending on the configuration. Alternatively, if the player performs character control operations such as jumping, dodging, or continuous movement, and the enhanced lock-on mode is not currently enabled, the terminal will release the soft lock state to avoid forcibly tracking the target in a non-combat stance.

[0046] If the player object and the final locked interactive object are obstructed by walls, large obstacles, or other barriers, the terminal initiates obstruction lock detection. When the duration of the obstruction exceeds a preset threshold, it is determined to be a valid obstruction and the lock is released. In addition, if the camera's orientation deviates from the initial direction at the time of locking by more than a set angle, the system considers that the player has actively turned to a new area and will also cancel the original lock.

[0047] In forced lock mode, the terminal marks the currently locked interactive object as a forced lock interactive object and drives the camera to continuously follow the target, achieving a lens binding effect similar to "forced lock".

[0048] In one embodiment, when a player triggers a forced lock-on object quick-switch command event—for example, by using a virtual quick-switch lock-on object button on the touchscreen or pressing a physical button on the device corresponding to the quick-switch command—the terminal will respond to the forced lock-on object quick-switch command by searching for all interactive objects with a lock priority no lower than the current forced lock-on target within the current three-dimensional lock area, and selecting the one closest in space to the player character as the new target. If the player specifies a switching direction using a joystick, the terminal will emit a detection ray or sector along that direction, starting from the current forced lock-on target, to find an interactive object that meets the priority condition and is relatively close for switching. When the forced lock-on target is eliminated, the system automatically executes the above switching logic to ensure that the high-value target chain remains intact.

[0049] If the target has enhanced lock-on configuration information, the terminal will generate an independent enhanced lock-on columnar area at its location, with its own radius and vertical height. Within this area, all interactive objects with a lock-on priority no lower than the original target are considered candidates. Once the original target leaves the main lock-on area due to brief disengagement or obstruction, the system selects the closest target in space from the candidate set as the replacement target, achieving a seamless transition. The terminal also supports a target inheritance mechanism after skill release. After a skill release event is triggered, the system can use the currently locked target as the inherited target of the skill, maintaining tracking of the target during the skill animation or effect duration. Even if a brief unlocking event occurs, the system can still restore lock-on to the target within the inheritance time window.

[0050] For handling lock-on conflicts in multi-target environments, the terminal employs a priority queue mechanism to maintain a list of all eligible interactive objects. When multiple candidate lock-on interactive objects simultaneously meet the generalization angle and spatial distance requirements, the system sorts them according to a preset priority rule. This rule can be based on the interactive object type, aggro level, remaining health, or player-defined markers to select the final lock-on interactive object from the candidate objects.

[0051] The soft lock-on mechanism in games often uses a static, fixed range to automatically attract the nearest target. This lack of comprehensive judgment regarding player intent, the three-dimensional battlefield, and target type easily leads to problems such as target jumps, missed attacks, and tracking interruptions, severely impacting combat smoothness and the user experience. As demonstrated by the above embodiments, this application provides an innovative solution to the problems existing in traditional soft lock-on mechanisms. Its beneficial effects are mainly reflected in the following aspects: First, this application effectively solves the target misjudgment problem caused by the fixed cone or spherical range in traditional soft locking mechanisms by constructing a three-dimensional locking area centered on the player character and dynamically updating the locking orientation of this area in conjunction with pointing operation information. This three-dimensional locking area is composed of a combination of circles and fans, and is stretched into a three-dimensional space by vertical height parameters. It can accurately adapt to complex battlefield environments containing terrain with elevation differences, aerial units, or underground structures, avoiding the inclusion of irrelevant objects in the target acquisition range, and significantly improving the spatial accuracy and scene adaptability of target selection.

[0052] Secondly, this application introduces dual quantitative indicators of spatial angle and spatial distance in the target selection process, and sets a generalization angle as a tolerance threshold. This allows the system to intelligently select the most suitable interactive object for the current combat situation while respecting the player's operational intentions. When multiple targets are within the generalization angle range, the target with the smaller spatial distance is prioritized as the final lock target. This ensures the rationality of the locking result and avoids target jumps caused by slight directional deviations, thereby significantly enhancing the hit rate of skill release and the consistency of operational feedback.

[0053] Furthermore, this application establishes the entire locking logic on configurable geometric parameters and dynamic input sources, enabling all calculations to be completed locally on the terminal without relying on server synchronization, ensuring low-latency response and high frame rate smoothness. Simultaneously, this method effectively avoids the occlusion problem of the character's own model on close-range targets by processing the center position of the region through post-offset, making target capture more stable and reliable in close combat. Overall, this technical solution not only optimizes the accuracy and efficiency of target determination but also significantly enhances the player's operational experience and immersion in high-speed combos, multi-target melees, and three-dimensional battlefields.

[0054] Based on any embodiment of the method in this application, the step of generating a three-dimensional locked region for a player character in a game scene further includes: Step S111: Generate a circular locking region based on the circular radius in the locking region configuration information, and generate a sector-shaped locking region based on the sector radius and sector angle in the locking region configuration information: The circular radius defines the size of a circular locking area covering the player character's position in all directions, used to capture interactive objects nearby. The sector radius and sector angle together define a sector detection area with the center of the circular locking area as its vertex and the direction determined by the pointing operation information as its axis of symmetry, used to focus on interactive objects at medium to long distances in front. Both share the same center on the horizontal plane, ensuring the continuity of the spatial structure and the consistency of calculations.

[0055] Step S112: Combine the circular locking region and the sector-shaped locking region into a two-dimensional locking region, wherein the included angle of the sector-shaped locking region in the two-dimensional locking region is located at the center of the circular locking region. The circular locking area and the fan-shaped locking area are combined into a two-dimensional locking area, where the included vertex of the fan-shaped locking area is located at the center of the circular locking area. This combination is implemented using set union operations, meaning that any position falling within either the circular or fan-shaped area is considered to be within the effective target acquisition plane. This composite structure overcomes the shortcomings of a single fan-shaped area having blind spots to the sides and rear, and a single circle lacking directionality, allowing the system to respond to distant targets directly in front while also taking into account threats around the character. For example, melee characters can be configured with a larger circular radius (e.g., 3000 cm) and a smaller fan-shaped radius (e.g., 2000 cm) to emphasize close-range defense; ranged characters can be configured with a smaller circular radius (e.g., 1000 cm) and a larger fan-shaped radius (e.g., 5000 cm) and a wider fan-shaped angle (e.g., 120 degrees) to enhance forward field of view coverage.

[0056] Step S113: Based on the vertical height information of the locked area in the configuration information, convert the two-dimensional locked area into a three-dimensional locked area: Based on the vertical height information of the locked area configuration, the two-dimensional locked area is stretched vertically to form a three-dimensional locked area with upper and lower boundary constraints. Specifically, starting from each point on the two-dimensional plane, the terminal extends upward along the vertical axis of the world coordinate system to the offset defined by the upper height, and downward to the negative offset defined by the lower height, constructing a cylindrical space. The upper and lower heights can be configured independently; for example, in an aerial combat scenario, the upper height can be set to 2500 cm to include flying units, while in an underground scenario, the lower height can be set to 1500 cm to exclude irrelevant underground models. This height separation mechanism enables the system to distinguish targets at different vertical levels, significantly improving the screening accuracy in a three-dimensional battlefield.

[0057] Step S114: Determine the center point and orientation of the player character in the game scene. Position the center of the three-dimensional locking area away from the center point and behind the player character's orientation. The center of this area should be located at the center of the circular locking area within the three-dimensional locking area. The game system determines the center point and orientation of the player character within the game scene. The center of the 3D target locking area is set to be offset from the player character's center point and located behind the player character's orientation. This center is also located at the geometric center of the circular target locking area within the 3D target locking area. This offset distance is a fixed value, such as 2.5 meters, and its direction is consistent with the current reference orientation used for target acquisition, including but not limited to the camera's yaw direction, joystick input direction, or the character's facing direction. This rear offset design ensures that the starting point for angle and distance calculations is behind the character, allowing the line of sight to naturally pass through the space in front of the character. This effectively prevents targets close to the character from being missed due to the character's own collision objects obstructing the view, making it particularly suitable for stable capture of enemies within 1 to 2 meters during high-speed melee combos.

[0058] The above embodiments combine and stretch the circular locking area and the fan-shaped locking area into a three-dimensional locking area, while shifting the center of the area backward. This significantly improves the spatial accuracy and scene adaptability of target selection, effectively avoids misjudgment of close targets caused by the occlusion of the character's own model, and ensures low latency response and high frame rate smoothness. This allows the system to accurately adapt to complex battlefield environments that include terrain with elevation differences, air units, or underground structures.

[0059] Based on any embodiment of the method in this application, the step of obtaining the pointing operation information corresponding to the player pointing operation event includes one of the following steps: Step S121: Respond to the controller control event corresponding to the skill release event, and generate corresponding controller direction information as pointing operation information based on the controller control direction of the controller control event. In response to the controller control event corresponding to the skill release event, the terminal reads the current input state of the controller in real time at the skill trigger frame (i.e. the starting logic frame or animation notification frame of skill release). The controller control event specifically refers to the input event generated by the player through physical or virtual controllers (such as the left joystick of a gamepad, the virtual joystick of a mobile device, or the swipe of a touch screen).

[0060] The terminal maps the controller's two-dimensional offset (input values ​​on the X and Y axes) to the game world's horizontal plane (XZ plane). After removing the vertical component, it calculates the normalized unit vector as the controller's direction information. This information directly reflects the player's active intention when releasing a skill and is suitable for skill types that require manual guidance, such as fan-shaped slashes or directional dashes. In the implementation, the range of the controller offset reading is limited by a preset dead zone threshold (e.g., 0.1). When the offset is less than this threshold, the system does not generate valid controller direction information but instead reverts to the default direction (e.g., camera orientation or character orientation) based on the skill configuration, avoiding misjudgment of direction due to input jitter.

[0061] The generation of controller direction information supports various specific implementation methods, including but not limited to: mobile virtual joystick input processing, where touchscreen coordinates are converted into joystick offsets; console physical controller input processing, utilizing the analog input axis data of the game controller; and hybrid input strategies, such as superimposing touchscreen swipe commands on joystick input to form a composite direction. In the mobile implementation, when the player slides the virtual joystick to the upper right, the system captures the touch coordinate offset (e.g., X=0.6, Y=0.4), maps it to the XZ plane, and normalizes it to (0.83, 0, 0.56), representing the world vector in the northeast direction. In the console implementation, when the left joystick of the game controller is offset to the left by 50%, the system reads the input value (-0.5, 0), normalizes it, and obtains the westward unit vector (-1, 0, 0). Furthermore, the system can be configured to dynamically adjust the dead zone threshold, for example, setting the dead zone to 0.05 in high-speed combat scenarios to improve response sensitivity, or setting it to 0.15 when aiming at a stationary position to suppress input noise.

[0062] The generation of controller direction information is strictly limited to once per skill trigger frame, ensuring that the direction data remains stable during the skill animation and does not update with subsequent input changes. This information is stored in memory as a three-dimensional unit vector, serving as the reference input for subsequent area-locking orientation. It is logically independent but interchangeable with other directional operation information such as player character orientation and camera orientation. For example, when the skill is configured as "Start Orientation: Joystick Direction," the system prioritizes using controller direction information. However, when the player does not make a valid joystick input, it automatically switches to camera orientation information, ensuring the continuity of the skill release process and the accurate transmission of operational intent.

[0063] Step S122: Respond to the skill release event, determine the player character's current orientation to generate corresponding player character orientation information, and use this player character orientation information as the pointing operation information: In response to a skill release event, the terminal immediately reads the forward axis vector of the player character's current root skeleton component or capsule component at the skill trigger frame (i.e., the starting logic frame or animation keyframe of the skill release). This vector represents the character's facing direction in the game world coordinate system, and is used as the player character's facing information. This information directly reflects the character's own facing, independent of external input or camera status, and is suitable for skill types that emphasize the character's own facing, such as the spinning slash or shield bash in melee combos, ensuring that attacks are always based on the character's frontal view and avoiding target acquisition drift caused by camera rotation. After obtaining this vector, the terminal normalizes it into a three-dimensional unit vector, which serves as the core input for pointing to operation information, ensuring dynamic matching with the "starting facing" field in the skill configuration table.

[0064] The generation of player character orientation information supports multiple implementation methods, including but not limited to: static model-based orientation, which directly uses the character model's preset forward axis vector; animation-driven orientation, such as using the root motion's actual forward direction vector provided by the animation system when the character performs a side roll or turn animation, which is calculated and output in real time through the animation blending layer; and dynamic adjustment based on the character's state, such as fine-tuning the orientation vector according to the current movement direction when the character is running, jumping, or rolling to ensure it aligns with the character's actions. Figure 1 In this melee skill implementation, the player character's facing information ensures that the Spinning Slash skill always centers its attack on the character's front. Even with rapid camera rotation, the skill's release direction remains consistent with the character's facing direction, avoiding the attack direction errors caused by camera shifts in traditional mechanisms.

[0065] This generation process is strictly limited to being executed once per skill trigger frame to avoid directional fluctuations caused by repeated sampling, while also ensuring seamless integration with skill configuration logic. When the skill is configured as "Start Orientation: Character Orientation", the system prioritizes using the player character's orientation information as the directional operation information; if the character is in a special state (such as being knocked back or knocked down), the terminal automatically reverts to the default orientation (such as the camera orientation) to ensure the continuity of the operation intent.

[0066] Step S123: Respond to the skill release event, generate corresponding camera orientation information based on the current orientation of the camera in the game scene, and use this camera orientation information as the pointing operation information: In response to a skill release event, the terminal immediately extracts the viewing direction vector from the currently active camera component at the skill trigger frame (i.e., the starting logic frame or animation keyframe of the skill release). This vector represents the camera's line of sight in the world coordinate system. The terminal projects this vector onto the game world's horizontal plane (XZ plane), and generates camera orientation information by culling the vertical component (setting the Y-axis value to zero) and normalizing it to a unit vector. This process ensures that the 3D locked area always fits the ground combat plane, eliminating the interference of camera tilt angles (such as elevation or depression) on direction determination, and making the direction of ranged skills (such as archery or spellcasting) completely consistent with the player's visual focus. For example, when the player rotates the camera to aim at a distant enemy, the system uses the camera orientation information as a reference for skill release direction, avoiding deviation of the skill projection direction from the target due to camera tilt angles.

[0067] The generation of camera orientation information supports various implementation methods, including but not limited to: direct application in standard third-person perspective, where the camera orientation vector is directly used for target acquisition; dynamic lens smoothing, where the system performs low-pass filtering or inter-frame interpolation on the orientation vector when the camera rotates at high speed to generate a more stable intermediate direction, preventing target jumps caused by lens shake; mobile device input adaptation, such as in touchscreen operation, where the camera orientation is calculated in real time based on the player's finger swipe trajectory to ensure the pointing accuracy of mobile remote skills; and multi-camera scene switching processing, where when there are multiple camera components in the game scene (such as cutscenes or special perspectives), the system prioritizes using the data of the currently active camera to avoid confusion of orientation sources. In a remote skill implementation, such as when a mage casts Frostbolt, the player adjusts the aiming angle by rotating the camera, and the system constructs a fan-shaped three-dimensional locking area based on the camera orientation information, ensuring that the skill always points to the center target of the lens, significantly improving the shooting hit rate.

[0068] This generation process is strictly limited to executing once per skill trigger frame, ensuring that the directional data remains stable during the skill animation and does not update with subsequent camera movement. Camera orientation information is stored as a three-dimensional unit vector and is logically processed in a unified manner with controller orientation information, player character orientation information, and other pointing operation information, providing standardized input for subsequent area-locking orientation. When the skill is configured as "Start Orientation: Camera Direction," the system prioritizes using this information as the pointing operation information; if the camera is in a special state (such as camera lock or a cutscene), the terminal automatically reverts to the default direction (such as character orientation), ensuring the continuity of the skill release process and the accurate transmission of operational intent.

[0069] Step S124: Respond to the skill release event, generate corresponding player skill aiming direction information based on the skill aiming direction of the skill release event, and use the player skill aiming direction information as the pointing operation information: In response to a skill release event, the terminal reads the pre-aiming data of the current skill in the skill trigger frame (i.e., the starting logic frame or animation keyframe of the skill release). This data is generated by the player before releasing the skill through a pre-aiming mechanism, such as a draggable aiming line or arc trajectory displayed on the screen after the player presses and holds the skill button. The terminal extracts the world coordinate vector of the trajectory's endpoint relative to the player's character position, removes the vertical component (sets the Y-axis value to zero), projects it onto the game world's horizontal plane (XZ plane), and normalizes it into a three-dimensional unit vector to form the player's skill pre-aiming direction information. This information directly reflects the player's intended direction before releasing the skill and is suitable for skill types that support pre-aiming mechanisms, such as charged throws or trajectory-guided skills, ensuring that the skill release direction is completely consistent with the player's pre-aiming operation.

[0070] The generation process of player skill aiming direction information is strictly limited to one execution within the skill trigger frame to avoid directional jitter caused by dynamic changes in the aiming trajectory. When acquiring trajectory data, the terminal prioritizes using the trajectory endpoint defined in the aiming mechanism as the calculation benchmark. For example, in a charged throw skill, after the player drags the aiming line to the target position and releases the skill, the system captures the coordinates of this endpoint (e.g., X=5000, Z=3000), calculates the position vector (5000, 0, 3000) relative to the player character coordinates (X=0, Z=0), projects it onto the XZ plane, and normalizes it to (0.857, 0, 0.514), representing the world vector in the northeast direction. This vector is used as the input for pointing operation information into subsequent locking logic to ensure that the skill release direction accurately matches the player's aiming intention.

[0071] This generation mechanism supports various implementation methods, including but not limited to: pre-aiming based on dragging the aiming line, where players drag the aiming line on the screen with their fingers or a mouse, and the system calculates the endpoint of the drag in real time; pre-aiming based on arc-shaped trajectory guidance, where an adjustable arc-shaped trajectory (such as a spell projection path) is displayed when the skill is released, and the system generates a direction vector based on the endpoint of the trajectory; pre-aiming based on touchscreen gestures, where mobile players adjust the trajectory by zooming or swiping with two fingers, and the system interprets the coordinates of the gesture endpoint; and pre-aiming based on hardware input, such as dragging the right joystick on a console controller or positioning the mouse pointer, where the system converts the input coordinates into the endpoint of the trajectory. In the example of a charged throw skill, the player drags the aiming line towards the enemy on the right, and the player's skill pre-aiming direction information generated by the system ensures that the skill projection direction is accurately aligned with the target, avoiding the deviation caused by camera rotation in traditional mechanisms.

[0072] Player skill aiming direction information is logically processed in a unified manner with other directional operation information such as controller direction information and player character orientation information, but it is only enabled when the skill is configured as "Start Orientation: Skill Target Direction". When the aiming mechanism fails (such as when no effective drag is performed), the system automatically reverts to the camera orientation information to ensure the continuity of the skill release process.

[0073] The above embodiments provide multiple ways to acquire directional operation information, such as controller direction, player character orientation, camera orientation, and player skill aiming direction, enabling the system to dynamically adapt to different skill types and player operating habits, accurately reflect the player's operating intentions, effectively avoid target jumps and attack misses, and significantly improve the hit rate of skill release and the consistency of operation feedback.

[0074] Based on any embodiment of the method in this application, the step of updating the locking orientation of the three-dimensional locking region according to the pointing operation information, and calculating the spatial angle and spatial distance between one or more interactive objects in the three-dimensional locking region and the center of the three-dimensional locking region includes: Step S131: Update the locking orientation of the 3D locking area based on the controller direction information, player character orientation information, camera orientation information, or player skill aiming direction information. Based on the controller direction information, player character orientation information, camera orientation information, or player skill aiming direction information, the locking orientation of the 3D lock-on area is updated. This process is executed once by the terminal during the skill trigger frame. The unit direction vector corresponding to the pointing operation information is used as the new principal axis direction of the 3D lock-on area, and the entire composite target acquisition space (composed of a circular lock-on area and a fan-shaped lock-on area) is rotated to align with the player's intended direction. When updating the lock-on orientation, the terminal completely aligns the principal axis direction of the 3D lock-on area with the unit vector pointing to the operation information, ensuring that the target acquisition range always covers the direction pointed to by the player's current operation intention. For example, when the player inputs a command to the upper right using the joystick, the system rotates the fan-shaped symmetry axis of the 3D lock-on area to the northeast direction, so that the 3D lock-on area focuses on that direction.

[0075] This update mechanism supports various implementation methods, including but not limited to: When using controller direction information, the system uses the normalized vector of the joystick input as the principal axis direction. For example, when the player slides the virtual joystick to the upper right on the mobile device, the system rotates the 3D locking area to the northeast direction represented by (0.83, 0, 0.56); When using player character orientation information, the system directly uses the forward axis vector of the character's root skeleton as the principal axis direction. For example, when the character faces east, the fan-shaped axis of symmetry of the 3D locking area points east; When using camera orientation information, the system uses the unit vector of the camera's viewing direction projected onto the horizontal plane as the principal axis direction. For example, when the player rotates the camera to aim at an enemy on the right, the 3D locking area rotates to that direction; When using player skill aiming direction information, the system uses the unit vector calculated from the endpoint of the aiming trajectory as the principal axis direction. For example, when the player drags the aiming line to point at an enemy on the right and releases the skill, the 3D locking area aligns with that direction.

[0076] Step S132: Identify the interactive objects in the game scene that are located within the three-dimensional locking area, and filter out one or more first interactive objects with the highest locking priority among the interactive objects: The process of identifying interactive objects within the 3D locked area in the game scene is implemented by the terminal using a spatial detection algorithm. This algorithm iterates through all interactive objects in the game scene, determining whether their positions fall within the geometric boundaries of the 3D locked area. The terminal uses bounding box detection or raycasting methods to calculate the spatial intersection between the collider or root skeleton positions of the interactive objects and the 3D locked area, filtering out all interactive objects located within that area. For example, when a player releases a fan-shaped slash in a skill trigger frame, the system will detect enemy A (hostile unit), mechanism B (destructible obstacle), and collectible C (collectible resource) located within the 3D locked area, and include these objects in the subsequent filtering scope.

[0077] The system filters out one or more first interactive objects with the highest locking priority from among the described interactive objects. This filtering process is based on a preset locking priority rule. Locking priority is usually set by type, as mentioned before, and can be set to enemy combat units > mechanisms > ecological monsters = gathering materials. Enemy combat units can be configured with more granular priorities, such as giving higher priority to enemy combat units with higher levels or health. The priority ranking can be dynamically adjusted in the future through runtime states (such as buffs), but by default, the system only retains the set of objects with the highest priority, called the first interactive objects. The locking priority is calculated numerically, with each target type assigned a priority value, for example, enemy units = 100, mechanisms = 50, ecological monsters = 20, and gathering materials = 20. When multiple targets have the same priority, the system will sort them according to the target ID order or the time they entered the area, ensuring the determinism and predictability of the results.

[0078] Step S133: Select the second interactive object with higher aggro priority from each of the first interactive objects. The aggro priority applies to the player character. From the first interactive objects, second interactive objects with higher aggro priority are selected. This aggro priority applies to the player character, and the selection process is based on the combat status relationship between the interactive object and the player character. The terminal checks whether each first interactive object is in a valid aggro state. Valid aggro states include, but are not limited to: the interactive object actively attacking the player character, continuously tracking the player character, being marked by the player character's skills, or being in a combat-active state (e.g., entering combat after being attacked by the player character). Interactive objects possessing any of these states are included in the second interactive object set as candidate targets for subsequent calculations of spatial angle and spatial distance.

[0079] The determination of aggro priority supports multiple implementation methods, including but not limited to: basic aggro determination, which only checks whether the interactive object is in combat; advanced aggro determination, such as grading based on aggro value (high aggro > medium aggro > low aggro); dynamic aggro determination, such as temporarily increasing the aggro priority of an interactive object when it is marked by a specific skill of the player character; and composite aggro determination, such as comprehensively evaluating factors such as the attack frequency, damage type, and distance of the interactive object. In the melee combo skill implementation, the system only retains hostile units actively attacking the player as secondary interactive objects, excluding inactive hostile units or neutral creatures; in the ranged skill implementation, the system may simultaneously retain multiple hostile units in a tracking state as secondary interactive objects to support multi-target locking.

[0080] When performing aggro filtering, the terminal prioritizes interacting objects most relevant to the player character's current combat status. For example, when a player character is being continuously attacked by a boss, the boss's aggro priority will be raised to the highest level, even if the player character is far away; when a player character has just cast a marking skill, the marked target will immediately gain high aggro priority, even if it was originally neutral. Aggro status is determined in real-time through the game engine's combat system API, ensuring the timeliness and accuracy of the data.

[0081] The calculation of aggro priority uses numerical processing, with each aggro state assigned a corresponding numerical weight. For example: Initiated Attack = 100, Tracking = 80, Marked by Skill = 70, Combat Activation = 60. The system calculates a comprehensive aggro value based on the current aggro state of the interacting objects, which is used for ranking decisions. When multiple interacting objects have the same aggro value, the system will sort them according to target ID order or the order in which they entered the aggro state, ensuring the determinism and predictability of the results.

[0082] Step S134: Calculate the spatial angle and spatial distance between each of the second interactive objects and the center of the three-dimensional locked area: The system calculates the spatial angle and spatial distance between each of the second interactive objects and the center of the three-dimensional locked area. This process is executed by the terminal during the skill trigger frame, and is based on the three-dimensional coordinates of the second interactive object and the coordinates of the area center for precise calculation. The calculation of the spatial angle first involves performing a dot product operation between the position vector of the second interactive object and the principal axis direction vector determined by the pointing operation information. The result is then converted into an angle value using an inverse cosine function. This angle represents the degree of deviation between the second interactive object and the principal axis direction of the locked area. Before calculation, the system projects the position vector onto the horizontal plane (XZ plane) of the game world to eliminate the influence of terrain elevation differences on angle determination, ensuring that the angle value only reflects the deviation in the horizontal plane direction, with a value range of 0 to 180 degrees.

[0083] Spatial distance is calculated using the three-dimensional Euclidean distance formula, i.e., √[(x2−x1)]. 2 + (y2−y1) 2 + (z2−z1) 2 The distance is calculated as follows: (x1, y1, z1) represents the coordinates of the region center, and (x2, y2, z2) represents the coordinates of the second interactive object. This distance represents the straight-line distance from the region center to the interactive object, and is unaffected by terrain or viewpoint. It is the core basis for subsequent filtering. The terminal uses precise floating-point arithmetic during the calculation process to ensure the accuracy of the distance value and avoid filtering errors caused by precision issues.

[0084] This calculation mechanism supports various implementation methods, including but not limited to: offset calculation based on character position, where the area center is located 2.5 meters behind the player character's center point, and this offset position is used as the reference for calculation; simplified calculation based on horizontal plane projection, where the system can use a two-dimensional Euclidean distance approximation to reduce computational overhead when the height difference between interactive objects is small; and adaptive calculation based on dynamic scaling, where the system automatically adjusts the accuracy threshold of distance calculation when the player is in a high-speed movement state to ensure accurate judgment even in high-speed combat. In the melee skill implementation, the system calculates target A with an angle of 15 degrees and a distance of 3000 cm, target B with an angle of 25 degrees and a distance of 2800 cm, and target C with an angle of 50 degrees and a distance of 2000 cm, where A and B are within the effective range, and C is excluded; in the ranged skill implementation, the system calculates target D with an angle of 5 degrees and a distance of 5000 cm, target E with an angle of 10 degrees and a distance of 4800 cm, and target F with an angle of 30 degrees and a distance of 4500 cm, where D, E, and F are all within the effective range, and the system will sort them by distance from smallest to largest. The above embodiments enable the system to accurately lock onto the target that the player intends to target by dynamically updating the locked orientation, filtering interactive objects based on locking priority, further filtering high-threat targets based on aggro status, and accurately calculating spatial angles and distances. This significantly improves the accuracy and stability of target locking and effectively avoids the problems of target jumping and missed attacks caused by directional deviations and improper target priorities in traditional mechanisms.

[0085] Based on any embodiment of the method in this application, the step of selecting the candidate locking interaction object with the smaller spatial distance as the final locking interaction object includes at least one of the following steps: Step S141: In response to the object removal event of the finally locked interactive object, cancel the object locking on the finally locked interactive object: In response to the object removal event of the finally locked interactive object, the terminal immediately listens for and captures the object removal event associated with the finally locked interactive object. This event is typically triggered by game logic, indicating that the finally locked interactive object has been removed from the game scene. For example, when the finally locked interactive object's health drops to 0 and it is judged as dead, it is cleared by a skill effect, or it is actively removed due to game rules. Upon receiving this event, the terminal immediately releases the lock on the finally locked interactive object, terminates the current lock association, and sets the identifier of the finally locked interactive object to a null value, ensuring that subsequent target acquisition logic will not attempt to access objects that no longer exist.

[0086] The object elimination event triggering mechanism supports multiple specific implementation methods, including but not limited to: event triggering based on health status, where the game engine automatically triggers an object elimination event when the health value of an interactive object falls below a preset threshold (e.g., 0); event triggering based on skill effects, such as when a specific skill (e.g., purification, dispel) takes effect on the finally locked interactive object, the system generates an elimination event; event triggering based on game rules, such as when an interactive object is removed by the system after reaching its time limit in a timed battle; and event triggering based on player actions, such as when a player uses a special item to remove a target. In the Boss battle implementation, when the Boss's health reaches zero and it is judged as dead, the system immediately triggers an object elimination event to cancel the lock on the Boss; in normal monster battles, when a player's skill knocks a monster off the map boundary, the system automatically triggers an object elimination event to unlock it.

[0087] Step S142: Respond to the player character's character control operation and cancel the object lock on the final locked interactive object. The character control operation includes the player character's jump operation, player character's dodge operation, or player character's movement operation. In response to player character control actions, the terminal listens for control signals from the player's input device in real time after the skill trigger frame. When it detects that the player character performs a jump, dodge, or movement, it immediately releases the object lock on the last locked interactive object. This mechanism is implemented through the game engine's input system API and is only effective during the skill release animation, ensuring that the player's active control intention takes precedence over the automatic locking logic. For example, when a player presses the jump key to dodge an attack during a melee combo, the system immediately terminates the current lock state to prevent the skill release direction from becoming disconnected from the target due to character movement.

[0088] The unlock mechanism for character control operations supports various implementations, including but not limited to: triggering a jump action, where the system immediately unlocks when the player presses the jump key (such as the spacebar on a keyboard or the A key on a gaming device); triggering a dodge action, where the system unlocks when the player performs a dodge action (such as a slide dodge on a mobile device or a side button dodge on a console device) to accommodate the character's high-speed movement; and triggering a movement action, where the system unlocks when the player generates continuous movement input via the joystick or directional keys (such as shifting the left joystick 50% to the left), allowing the player to reselect a target. In high-speed combo implementations, when the player performs consecutive jump actions, the system automatically unlocks after each jump, enabling the player to precisely control the rhythm of combos.

[0089] Step S143: Respond to the obstacle lock event triggered by an obstacle between the player character and the final locked interaction object. If the continuous response time of the obstacle lock event exceeds a preset time, cancel the object lock on the final locked interaction object. In response to obstacle lock events triggered by the presence of obstacles between the player character and the final locked interactive object, the terminal uses a raycasting algorithm to monitor the spatial connectivity between the player character and the final locked interactive object in real time. When the system detects the presence of obstacles (such as walls, trees, terrain protrusions, or the player's own model), an obstacle lock event is triggered. This event is continuously triggered through the game engine's collision system API to ensure real-time determination of the obstacle's presence. The scope of obstacle determination includes, but is not limited to: static environmental objects (such as building walls), dynamic environmental objects (such as moving obstacles or scene effects), the character's own colliders (such as the player character's head or arm model), and interactive obstacles in the scene (such as destructible boxes or fences).

[0090] The continuous response duration for obstacle lock events is calculated by a timer started by the terminal when the event is triggered, continuously monitoring the duration of the obstacle's presence. When this duration exceeds a preset threshold (e.g., 300 milliseconds), the system determines it as a valid obstacle lock and triggers a lock cancellation operation. The preset threshold can be dynamically configured, for example, set to 150 milliseconds for rapid response in high-speed combat scenarios, or to 500 milliseconds in precise operation scenarios to avoid false alarms. The system uses a frame-level counting mechanism when calculating the continuous response duration, triggering cancellation only when the obstacle persists for more than a preset number of frames (e.g., 15 frames), avoiding misoperations caused by momentary occlusion (e.g., a character's arm briefly obscuring the view).

[0091] This mechanism supports various implementation methods, including but not limited to: obstacle determination based on ray detection, which involves emitting a ray from the player character's position towards the finally locked interactive object and detecting whether the ray collides with an obstacle; obstacle determination based on bounding box detection, which compares whether the bounding boxes of the player character and the interactive object intersect with the bounding boxes of obstacles; collision detection based on the physics engine, which uses the collision callback function of the physics engine to provide real-time feedback on obstacle status; and obstacle determination based on the scene graph, which predefines obstacle layers in the scene graph to quickly filter out invalid obstructions. In the melee combo implementation, when the player character is blocked by a wall and cannot attack enemies in front, the system continuously detects obstruction locking events. When the continuous duration exceeds 300 milliseconds, the lock on the original target is automatically canceled, allowing the player to quickly adjust their position and relock.

[0092] When processing obstacle lock-on events, the terminal strictly limits the trigger to only when an obstacle completely obstructs the player's and target's line of sight, avoiding misjudgments caused by partial obstruction. For example, if an obstacle only obstructs 10% of the target's field of vision, the system will not trigger the event; only when the obstruction ratio exceeds 80% will it be considered a valid obstacle. This mechanism is linked to the skill configuration table and can be dynamically enabled or disabled. For example, in "Precise Lock-on Mode," the system requires an obstacle obstruction ratio of more than 90% to trigger cancellation, while in "Quick Response Mode," it is set to 70%.

[0093] Step S144: Monitor the camera's orientation change angle in the game scene. When the orientation change angle exceeds a preset angle, cancel the object lock on the finally locked interactive object. The system monitors changes in camera orientation within the game scene. The terminal obtains the current camera's orientation vector in real-time via the game engine's camera API and compares it with the orientation vector from the previous frame. The system calculates the difference in the horizontal plane (XZ plane) angle between the two frames; this difference represents the camera's orientation change angle. When this angle exceeds a preset threshold (e.g., 30 degrees), a de-lock operation is triggered. The preset threshold can be dynamically configured; for example, it can be set to 15 degrees in high-speed combat scenarios for rapid camera movement, or to 45 degrees in precise aiming scenarios to avoid misjudgments, ensuring the system only de-locks when there is a significant camera shift.

[0094] The detection of camera orientation changes supports various implementation methods, including but not limited to: calculation based on inter-frame vector difference, i.e., calculating the angle by the dot product of the current camera orientation vector and the vector of the previous frame; dynamic threshold adjustment based on lens rotation rate, for example, automatically reducing the preset angle to 20 degrees when the detected lens rotation speed exceeds 100 degrees per second; simplified processing based on horizontal plane projection, calculating only the angle difference in the XZ plane and ignoring the vertical pitch angle; and adaptation processing based on input device, such as calculating the equivalent angle change through touch screen swiping speed on mobile devices. In the third-person remote skill embodiment, when the player quickly rotates the camera to the left (camera orientation change angle reaches 35 degrees), the system immediately cancels the lock on the original target to prevent the skill projection direction from deviating significantly from the lens focus.

[0095] When calculating the camera's orientation change angle, the system uses a frame-level continuous detection mechanism. Cancellation is only triggered when the orientation change angle of two consecutive frames exceeds a preset threshold, thus avoiding erroneous operations caused by lens shake.

[0096] Through the above embodiments, the locking is immediately canceled when the final locked interactive object is removed, effectively preventing subsequent target acquisition logic from accessing objects that no longer exist, ensuring the continuity and reliability of the skill release process. Furthermore, the locking is immediately canceled when the player character jumps, dodges, or moves, prioritizing the player's active operation intention over the automatic locking logic, significantly improving the real-time response and continuity of combat operations. The locking is also canceled when an obstacle continuously obscures the target for more than a preset time, completely eliminating skill projection deviation caused by environmental obstacles, ensuring the accuracy and hit rate of skill release. In addition, the locking is canceled when the camera orientation changes beyond a preset angle, preventing skill direction deviation caused by large camera rotation, ensuring that the direction of remote skills always remains consistent with the player's visual focus.

[0097] Based on any embodiment of the method in this application, after the step of selecting the candidate locking interaction object with the smaller spatial distance as the final locking interaction object, the method further includes: Step S151: In response to the forced lock object command, the currently locked interactive object is used as the forced lock interactive object, and the camera in the game scene is controlled to face and follow the forced lock interactive object. In response to a forced lock-on command, the terminal listens for specific control signals from the player's input device in real time after the skill trigger frame. When it detects that the player has triggered a forced lock-on command (such as pressing a specific key or performing a specific gesture), the system identifies the current final locked interaction object as the forced lock-on interaction object and initiates the camera follow logic. This command is typically triggered by players who need to continuously lock onto a specific target during combat, such as locking onto a high-threat target in a boss battle to ensure continuous skill tracking, or locking onto teammates in teamwork to maintain tactical coordination. Upon receiving the command, the terminal immediately sets a forced lock-on status flag and stores the ID and location information of the current final locked interaction object in the forced lock-on target cache, ensuring that subsequent camera control logic can accurately reference this object.

[0098] This mechanism supports various implementation methods, including but not limited to: button-triggered forced lock, where the player presses a preset button (such as the F key on a keyboard or the X key on a game controller) to trigger forced lock; gesture-triggered forced lock, where the player triggers forced lock on a mobile device through a specific gesture (such as a long press with two fingers or a specific swipe trajectory); voice command-triggered forced lock, where the player issues a "lock target" command through the voice recognition system to trigger forced lock; and skill combination-triggered forced lock, where the player triggers forced lock within a specific skill release sequence, such as triggering forced lock after pressing skill keys consecutively. In the Boss battle implementation, after the player presses the F key, the system immediately locks onto the Boss and automatically points the camera at the Boss's head, ensuring that the player can clearly observe the Boss's skill release status.

[0099] Step S152: In response to the forced lock object quick switch command, determine the interaction object that is closest to the player character in space and has a lock priority greater than or equal to the current forced lock interaction object, and update that interaction object to the latest forced lock interaction object: In response to a forced target switching command, the terminal monitors specific control signals from the player's input device in real time after the skill trigger frame. When a player triggers a fast switching command (such as repeatedly pressing a specific key or performing a specific gesture sequence), the system immediately initiates the forced target switching process. This command is typically triggered when a player needs to quickly adjust the target during combat, such as quickly switching to a newly appeared high-threat target in a boss battle, or quickly locking onto a newly joined teammate in a team battle.

[0100] The system identifies the closest interactive object to the player character in terms of spatial distance and whose lock priority is greater than or equal to that of the currently forcibly locked interactive object. This determination process is based on a preset lock priority rule. The terminal traverses all interactive objects in the game scene, filters out those with a lock priority greater than or equal to that of the currently forcibly locked interactive object, calculates the spatial distance between these objects and the player character, and selects the closest object as the new target. For example, when the currently forcibly locked interactive object is a Boss (priority 100), the system filters out all interactive objects with a priority ≥ 100 (such as Bosses and high-threat monsters), calculates the distance between these objects and the player character, and selects the closest monster as the new forcibly locked interactive object.

[0101] This mechanism supports various implementation methods, including but not limited to: button-triggered quick switching, where players trigger switching by continuously pressing specific buttons (such as the Q key on a keyboard or the shoulder button on a game controller); gesture-triggered quick switching, where players trigger switching via specific virtual buttons in the touch UI on a mobile device; voice command-triggered quick switching, where players trigger switching by issuing the "switch target" command through the voice recognition system; and skill combination-triggered quick switching, where players trigger switching within a specific skill release sequence, such as triggering quick switching after continuously pressing skill buttons.

[0102] Step S153: Obtain the forced lock switching direction. Starting from the current forced lock interaction object, perform detection in the forced lock switching direction. Detect interaction objects that are spatially close to the current forced lock interaction object and have a lock priority greater than or equal to the current forced lock interaction object, and update that interaction object to the latest forced lock interaction object. To acquire the forced lock-on switching direction, the terminal listens for specific control signals from the player's input device in real time after the skill trigger frame. When a forced lock-on switching command is detected (such as continuously pressing a specific key or performing a specific gesture sequence), the system immediately acquires the forced lock-on switching direction. This direction is usually specified by the player through the controller. For example, when a player swipes the screen to the right on a mobile device, the system captures the direction vector of the swipe trajectory; when a player on a console presses the directional keys on a keyboard or gamepad, the system reads the offset direction vector of the joystick. The forced lock-on switching direction is represented as a three-dimensional unit vector. Its calculation is based on the horizontal plane (XZ plane) of the game world, and is normalized after removing the vertical component to ensure that the direction determination is not affected by terrain undulations. For example, when a player swipes the screen to the right, the system generates an eastward unit vector of (1, 0, 0).

[0103] Starting from the currently locked interactive object, the detection proceeds in the direction of the lock-on switching. The terminal emits a ray or fan-shaped detection area from the coordinates of the currently locked interactive object's position along the lock-on switching direction, scanning for interactive objects in that direction. This detection process uses a ray detection algorithm to calculate the distance between the ray and the interactive object's collision point, or it uses fan-shaped area detection, with the lock-on switching direction as the fan's central axis. The fan angle is typically set to 30 degrees to focus on a local area. The detection range can be dynamically adjusted according to skill configuration; for example, it can be set to 15 degrees in high-speed combat scenarios for precise switching, or to 60 degrees in open scenarios to expand the search range.

[0104] The system detects interactive objects that are spatially close to the currently locked interactive object and have a lock priority greater than or equal to that object. First, it filters out interactive objects with a lock priority greater than or equal to that of the currently locked interactive object. For example, if the currently locked interactive object is a Boss (priority 100), the system filters out all interactive objects with a priority ≥ 100 (such as Bosses and high-threat monsters). Then, among these objects, it calculates the spatial distance to the currently locked interactive object and selects the closest object as the new target. The spatial distance is calculated using the three-dimensional Euclidean distance formula to ensure the accuracy of the distance value. When multiple interactive objects have the same distance, the system sorts them according to the target ID order or the order in which they entered the higher priority state to ensure the determinism of the result.

[0105] This mechanism supports various implementation methods, including but not limited to: direction acquisition based on controller input, where the player specifies a direction via a joystick or touchscreen; direction acquisition based on gesture trajectory, such as the average direction calculated from the swipe trajectory on a mobile device; default acquisition based on the previous direction, where the system automatically detects the direction from the previous direction when the player does not specify one; and direction acquisition based on scene intelligence, such as the system automatically recommending the best direction based on the current combat environment. In the Boss battle implementation, when the player swipes the screen to the right to trigger a forced lock-on quick switch command, the system obtains the forced lock-on switch direction as east, emits a ray from the current Boss position along the east direction, detects a high-threat monster (priority 100) 500 cm away from the Boss, and updates it as the new forced lock-on interaction target.

[0106] Step S154: Respond to the object removal event of the currently forcibly locked interactive object, determine the interactive object that is closest to the player character in space and has a locking priority greater than or equal to the current forcibly locked interactive object, and update that interactive object to the latest forcibly locked interactive object: In response to an object removal event of the currently forcibly locked interactive object, the terminal immediately listens for and captures the object removal event related to the currently forcibly locked interactive object. This event is usually triggered by game logic, indicating that the currently forcibly locked interactive object has been removed from the game scene, such as when the currently forcibly locked interactive object's health drops to 0 and it is judged as dead, cleared by a skill effect, or actively removed due to game rules. After receiving this event, the terminal immediately initiates the forcibly locked target update process. The system determines the interactive object that is currently closest to the player character in spatial distance and has a locking priority greater than or equal to that of the currently forcibly locked interactive object, and updates that interactive object to the latest forcibly locked interactive object.

[0107] The determination process is based on a preset locking priority rule. The terminal traverses all interactive objects in the game scene, filters out interactive objects with a locking priority greater than or equal to the currently forcibly locked interactive object, and then calculates the spatial distance between these objects and the player character, selecting the closest object as the new target. For example, when the currently forcibly locked interactive object is a Boss (priority 100), the system filters out all interactive objects with a priority ≥ 100 (such as Bosses and high-threat monsters), then calculates the distance between these objects and the player character, selecting the closest monster as the new forcibly locked interactive object. When multiple interactive objects have the same distance, the system sorts them according to the target ID order or the order in which they entered the high-priority state, ensuring the determinism of the result.

[0108] This mechanism supports various implementation methods, including but not limited to: event triggering based on health status, where the game engine automatically triggers an object elimination event when the health value of an interactive object falls below a preset threshold (e.g., 0); event triggering based on skill effects, such as when a specific skill (e.g., purification, dispel) takes effect on the currently forcibly locked interactive object, the system generates an elimination event; event triggering based on game rules, such as when an interactive object is removed by the system after reaching its time limit in a timed battle; and event triggering based on player actions, such as when a player uses a special item to remove a target. In the Boss battle implementation, when the Boss's health reaches zero and it is judged as dead, the system immediately triggers an object elimination event, filters out all interactive objects with a priority ≥ 100 (e.g., high-threat monsters), and selects the nearest monster as the new forcibly locked interactive object.

[0109] The above embodiments provide functions such as forced locking, quick switching, directional guidance switching, and automatic target update, enabling players to adjust the locked target instantly and accurately, significantly improving tactical flexibility and operational smoothness in combat, and ensuring that the most threatening interactive object is always locked in complex combat environments.

[0110] Based on any embodiment of the method in this application, after the step of selecting the candidate locking interaction object with the smaller spatial distance as the final locking interaction object, the method further includes: Step S161: Obtain the enhanced locking configuration information of the interactive object, which includes the radius of the enhanced locking area and the vertical height information of the enhanced locking area. The enhanced locking region radius is a numerical parameter that represents the radius of the enhanced locking columnar region on the horizontal plane (XZ plane), usually in centimeters, for example, the default value is 300 centimeters. It is used to determine the horizontal coverage of the columnar region and ensure that the system can accurately define the horizontal boundary of target detection.

[0111] The enhanced locking area height information includes two parameters: upper height and lower height. The upper height represents the upper limit position of the columnar area in the vertical direction (Y-axis), and the lower height represents the lower limit position of the columnar area in the vertical direction. For example, the default upper height is 100 cm and the lower height is -50 cm. This is used to determine the height range of the columnar area in the vertical direction and avoid detection deviations caused by terrain undulations or differences in character height.

[0112] The acquisition of enhanced locking configuration information for interactive objects supports multiple specific implementation methods, including but not limited to: reading preset values ​​from the game configuration file, such as configuring the enhanced locking radius of the Boss in a Boss battle to be 500 cm, the top height to be 150 cm, and the bottom height to be -75 cm; dynamically acquiring the enhanced locking configuration of the current interactive object through the game API, such as when the player switches characters, the system automatically loads the enhanced locking parameters of the corresponding character; allowing players to customize configuration parameters in the settings interface, such as adjusting the size and height range of the enhanced locking area in "Advanced Settings".

[0113] Step S162: When the final locked interaction object is determined, a corresponding enhanced locking columnar region is generated at the final locked interaction object according to the enhanced locking configuration information of the interaction object: Once the final locked interaction object is identified, the terminal generates a corresponding enhanced locking columnar region at the object's location coordinates based on the previously acquired enhanced locking configuration information. This columnar region is a three-dimensional geometric shape, with its horizontal coverage determined by the radius of the enhanced locking region and its vertical height determined by the vertical height information of the enhanced locking region. Specifically, it is a cylindrical space centered on the final locked interaction object, with a horizontal radius equal to the radius of the enhanced locking region, extending vertically from the bottom to the top. For example, when the final locked interaction object is Boss and the configuration information is an enhanced locking region radius of 500 cm, a top height of 150 cm, and a bottom height of -75 cm, the system generates a columnar region at the Boss's location with a horizontal radius of 500 cm and a vertical height ranging from -75 cm to 150 cm, ensuring that this region accurately covers the detection range of high-threat targets around Boss.

[0114] Step S163: Monitor in real time one or more interactive objects existing in the enhanced locking columnar region, and select each interactive object with a locking priority greater than or equal to that of the final locked interactive object as a candidate locked interactive object: The system continuously monitors one or more interactive objects within the enhanced locking columnar region in real time. The terminal uses the game engine's collision system API to continuously detect these objects, employing a frame-level real-time monitoring mechanism to ensure timely response to changes in the interactive objects' states. The terminal treats the enhanced locking columnar region as a three-dimensional detection space. When an interactive object enters or leaves this region, the collision system triggers a corresponding event, which the terminal immediately captures and obtains the interactive object's position, priority, and other attribute information. This monitoring mechanism supports various implementation methods, including but not limited to: real-time detection based on colliders (detection triggered when the collider of an interactive object intersects with the collider of the enhanced locking columnar region); efficient detection based on spatial indexing (quickly querying interactive objects within the region using the game engine's spatial indexing system); event-driven detection (implemented by registering region entry / exit event listeners); and timed detection based on frame intervals (detection performed every frame or every fixed number of frames to ensure efficient system resource utilization).

[0115] The system selects all interactive objects with a locking priority greater than or equal to that of the final locked interactive object as candidate locked interactive objects. The system filters interactive objects based on their locking priority attribute, with higher priority values ​​considered more worthy of attention. For example, when the final locked interactive object is the Boss (locking priority 100), the system filters out all interactive objects with a locking priority ≥ 100 (such as high-threat monsters) and uses these as candidate locked interactive objects. The locking priority is determined based on the game's preset priority rules; a higher priority value indicates a higher threat level. In the Boss battle embodiment, when the Boss is determined as the final locked interactive object, the system monitors the interactive objects within the enhanced locking bar area in real time, filters out all interactive objects with a priority ≥ 100 (such as high-threat monsters), and uses these monsters as candidate locked interactive objects, providing an accurate target list for subsequent forced locking target switching.

[0116] During the screening process, the system employs a priority comparison algorithm to ensure that only interactive objects meeting the criteria are selected, preventing low-priority targets from interfering with the locking logic. When multiple interactive objects have the same locking priority, the system will sort them according to their target ID order or the order in which they entered the high-priority state, ensuring the determinism of the result. This mechanism is tightly integrated with the generation logic of the enhanced locking bar area, ensuring that the screening range is completely consistent with the defined range of the enhanced locking area. This allows the system to accurately identify and screen high-threat targets, providing players with the optimal locking options and significantly improving the efficiency of tactical decision-making and operational accuracy in combat.

[0117] Step S164: In response to the lock release event of the final locked interactive object, filter out the candidate locked interactive objects that are closest in spatial distance to the final locked interactive object, and take the candidate locked interactive object as the latest final locked interactive object: In response to the lock-off event of the final locked interactive object, the terminal immediately listens for and captures the lock-off event related to the final locked interactive object. This event is usually triggered by game logic, indicating that the final locked interactive object can no longer be used as a lock target. For example, when the final locked interactive object's health drops to 0 and it is judged as dead, it is cleared by a skill effect, it cannot be locked due to continuous obstruction by an obstacle for more than a preset time (e.g., 300 milliseconds), or the target leaves the lock range due to a change in camera orientation exceeding a preset angle (e.g., 30 degrees). After receiving this event, the terminal immediately initiates a target switching process. The system filters out the candidate locked interactive objects that are spatially closest to the final locked interactive object and uses that candidate locked interactive object as the latest final locked interactive object.

[0118] Spatial distance is calculated using a three-dimensional Euclidean distance formula to ensure accuracy. The calculation considers the positional differences between the player character and the interactive object on the X, Y, and Z coordinate axes. When multiple candidate locked interactive objects are at the same spatial distance to the final locked interactive object, the system sorts them according to their target ID order or the order in which they entered a high-priority state, ensuring the determinism and predictability of the results.

[0119] In the Boss battle implementation, when the Boss's health reaches zero and it is considered dead, the system triggers a lock-on release event. It then selects the monster closest to the Boss in space (e.g., a monster 400 cm away) from the candidate lock-on targets (high-threat mobs) and updates it as the latest final lock-on target. In the team battle implementation, when the current final lock-on target (teammate) becomes unlockable due to obstruction for more than 300 milliseconds, the system immediately selects the highest-priority teammate closest in space (e.g., a teammate 350 cm away) and updates it as the latest final lock-on target. During target switching, the system strictly limits execution to only after the lock-on release event is triggered, ensuring the accuracy and timeliness of the switching logic. This allows players to seamlessly switch targets without manual intervention during combat, significantly improving the smoothness of combat and tactical execution efficiency.

[0120] The above embodiments, by precisely configuring the enhanced locking area, filtering high-priority interactive objects in real time, and automatically handling lock-off events, can quickly and accurately lock onto the most threatening target after the current locked interactive object is released, significantly improving the accuracy of target locking and the smoothness of operation in battle, and ensuring that players always maintain the best tactical objective in complex combat environments.

[0121] Please see Figure 3According to one aspect of this application, a target locking device includes a locking area generation module 11, a pointing operation acquisition module 12, an angle distance calculation module 13, and an interactive object locking module 14. The locking area generation module 11 is configured to generate a three-dimensional locking area for a player character in a game scene. The pointing operation acquisition module 12 is configured to acquire pointing operation information corresponding to a player pointing operation event, wherein the pointing operation information includes one of controller direction information, player character orientation information, camera orientation information, and player skill aiming direction information. The angle distance calculation module 13 is configured to update the locking orientation of the three-dimensional locking area based on the pointing operation information, and calculate the spatial angle and spatial distance between one or more interactive objects within the three-dimensional locking area and the center of the three-dimensional locking area. The interactive object locking module 14 is configured to select candidate locked interactive objects from among the interactive objects whose spatial angle is within a preset generalization angle, and then select the candidate locked interactive objects with smaller spatial distances as the final locked interactive objects.

[0122] Based on any embodiment of the device in this application, the locking region generation module 11 includes: an initial locking region generation unit configured to generate a circular locking region according to the circular radius in the locking region configuration information, and to generate a fan-shaped locking region according to the fan-shaped radius and fan-shaped angle in the locking region configuration information; a two-dimensional locking region generation unit configured to combine the circular locking region and the fan-shaped locking region into a two-dimensional locking region, wherein the included angle of the fan-shaped locking region in the two-dimensional locking region is located at the center of the circular locking region; a three-dimensional locking region generation unit configured to convert the two-dimensional locking region into a three-dimensional locking region according to the region vertical height information in the locking region configuration information; and a three-dimensional locking region positioning generation unit configured to determine the center point and character orientation of the player character in the game scene, and to offset the center point of the three-dimensional locking region from the center point and position it behind the character's orientation, wherein the center of the region is located at the center of the circular locking region in the three-dimensional locking region.

[0123] Based on any embodiment of the device in this application, the pointing operation acquisition module 12 includes: an operator direction information generation unit configured to respond to a operator control event corresponding to a skill release event, and generate corresponding operator direction information as pointing operation information according to the operator control direction of the operator control event; a player character orientation information generation unit configured to respond to a skill release event, determine the current orientation of the player character to generate corresponding player character orientation information, and use the player character orientation information as pointing operation information; a camera orientation information generation unit configured to respond to a skill release event, and generate corresponding camera orientation information according to the current orientation of the camera in the game scene, and use the camera orientation information as pointing operation information; and a player skill pre-aiming direction information generation unit configured to respond to a skill release event, and generate corresponding player skill pre-aiming direction information according to the skill pre-aiming direction of the skill release event, and use the player skill pre-aiming direction information as pointing operation information.

[0124] Based on any embodiment of the device in this application, the included angle distance calculation module 13 includes: a lock orientation update unit configured to update the lock orientation of the three-dimensional lock area according to the controller direction information, player character orientation information, camera orientation information, or player skill aiming direction information of the pointing operation information; a first interactive object filtering unit configured to determine the interactive objects in the game scene that are located in the three-dimensional lock area, and filter out one or more first interactive objects with the highest lock priority among the interactive objects; a second interactive object filtering unit configured to filter out second interactive objects with higher aggro priority from each of the first interactive objects, the aggro priority being applied to the player character; and an included angle distance calculation unit configured to calculate the spatial angle and spatial distance between each second interactive object and the center of the three-dimensional lock area.

[0125] Based on any embodiment of the device in this application, it further includes: an interactive object elimination response unit configured to respond to an object elimination event of a finally locked interactive object and cancel the object lock on the finally locked interactive object; a character control operation response unit configured to respond to a character control operation of a player character and cancel the object lock on the finally locked interactive object, wherein the character control operation includes a player character jump operation, a player character dodge operation, or a player character movement operation; an obstacle lock response unit configured to respond to an obstacle lock event triggered by an obstacle between the player character and the finally locked interactive object, wherein when the continuous response duration of the obstacle lock event exceeds a preset duration, the object lock on the finally locked interactive object is canceled; and an orientation change angle monitoring unit configured to monitor the orientation change angle of the camera in the game scene, wherein when the orientation change angle exceeds a preset angle, the object lock on the finally locked interactive object is canceled.

[0126] Based on any embodiment of the device in this application, it further includes: a forced locking interactive object determination unit configured to respond to a forced locking object command, take the current final locked interactive object as the forced locking interactive object, and control the camera in the game scene to follow the forced locking interactive object; a forced locking object fast switching unit configured to respond to a forced locking object fast switching command, determine the interactive object that is currently closest to the player character in space and has a locking priority greater than or equal to the current forced locking interactive object, and update that interactive object as the latest forced locking interactive object; a forced locking switching direction response unit configured to obtain the forced locking switching direction, detect from the current forced locking interactive object towards the forced locking switching direction, detect the interactive object that is relatively close to the current forced locking interactive object in space and has a locking priority greater than or equal to the current forced locking interactive object, and update that interactive object as the latest forced locking interactive object; and an object elimination event response unit configured to respond to the object elimination event of the current forced locking interactive object, determine the interactive object that is currently closest to the player character in space and has a locking priority greater than or equal to the current forced locking interactive object, and update that interactive object as the latest forced locking interactive object.

[0127] Based on any embodiment of the device in this application, it further includes: a reinforced locking configuration acquisition unit configured to acquire reinforced locking configuration information of interactive objects, the reinforced locking configuration information of interactive objects including the radius of the reinforced locking area and the vertical height information of the reinforced locking area; a reinforced locking columnar area generation unit configured to generate a corresponding reinforced locking columnar area at the location of the final locked interactive object according to the reinforced locking configuration information of the interactive object when the final locked interactive object is determined; a candidate locked interactive object detection unit configured to monitor one or more interactive objects existing in the reinforced locking columnar area in real time, and select each of the interactive objects with a locking priority greater than or equal to that of the final locked interactive object as candidate locked interactive objects; and a final locked interactive object update unit configured to respond to the lock release event of the final locked interactive object, filter out the candidate locked interactive object that is closest in spatial distance to the final locked interactive object among the candidate locked interactive objects, and select the candidate locked interactive object as the latest final locked interactive object.

[0128] Another embodiment of this application also provides a target locking device. For example... Figure 4 The diagram shows the internal structure of a target locking device. This device includes a processor, a computer-readable storage medium, a memory, and a network interface connected via a system bus. The computer-readable, non-volatile storage medium stores an operating system, a database, and computer-readable instructions. The database stores information sequences, and when executed by the processor, these computer-readable instructions enable the processor to implement a target locking method.

[0129] The processor of the target locking device provides computing and control capabilities to support the operation of the entire target locking device. The memory of the target locking device can store computer-readable instructions, which, when executed by the processor, cause the processor to perform the target locking method of this application. The network interface of the target locking device is used for communication with a terminal.

[0130] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the target locking device to which the present application is applied. A specific target locking device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0131] In this embodiment, the processor is used to execute... Figure 3 The specific functions of each module are described, and the memory stores the program code and various data required to execute the aforementioned modules or sub-modules. A network interface is used to enable data transmission between user terminals or servers. In this embodiment, the non-volatile readable storage medium stores the program code and data required to execute all modules in the target locking device of this application. The server can call the server's program code and data to execute the functions of all modules.

[0132] This application also provides a non-volatile readable storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the target locking method of any embodiment of this application.

[0133] This application also provides a computer program product, including a computer program / instructions that, when executed by one or more processors, implement the steps of the method described in any embodiment of this application.

[0134] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a computer-readable storage medium such as a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM).

Claims

1. A target locking method, characterized in that, include: Generate a three-dimensional locking region for the player character in the game scene, wherein the three-dimensional locking region is determined by geometric parameters representing the spatial shape and extent information of the locking region; Obtain pointing operation information corresponding to the player's pointing operation event, wherein the pointing operation information includes one of the following: controller direction information, player character orientation information, camera orientation information, and player skill aiming direction information; The locking orientation of the three-dimensional locking area is updated according to the pointing operation information, and the spatial angle and spatial distance between one or more interactive objects in the three-dimensional locking area and the center of the three-dimensional locking area are calculated, wherein the one or more interactive objects are determined by a preset locking priority and the aggro status of the player character; Candidate locking interaction objects are selected from each of the interactive objects whose spatial angle is within a preset generalization angle, and then the candidate locking interaction objects with smaller spatial distances are selected as the final locking interaction objects. Based on the enhanced locking configuration information of the interactive object, a corresponding enhanced locking columnar region is generated at the final locked interactive object; Real-time monitoring of one or more interactive objects existing in the enhanced locking column area; each interactive object with a locking priority greater than or equal to the final locked interactive object is selected as a candidate locked interactive object. In response to the lock release event of the final locked interactive object, the candidate locked interactive object that is spatially closest to the final locked interactive object is selected from among the candidate locked interactive objects, and this candidate locked interactive object is taken as the latest final locked interactive object.

2. The target locking method according to claim 1, characterized in that, The steps for generating the 3D locked region of the player character in the game scene also include: A circular locking region is generated based on the circular radius in the locking region configuration information, and a sector locking region is generated based on the sector radius and sector angle in the locking region configuration information. The circular locking region and the sector-shaped locking region are combined into a two-dimensional locking region, wherein the included angle of the sector-shaped locking region in the two-dimensional locking region is located at the center of the circular locking region; Based on the vertical height information of the locked area in the configuration information, the two-dimensional locked area is converted into a three-dimensional locked area; Determine the center point and orientation of the player character in the game scene, and move the center of the three-dimensional locking area away from the center point and behind the orientation of the character. The center of the area is located at the center of the circular locking area in the three-dimensional locking area.

3. The target locking method according to claim 1, characterized in that, The steps for obtaining pointer operation information corresponding to a player's pointer operation event include one of the following steps: Respond to the controller control event corresponding to the skill release event, and generate corresponding controller direction information as pointing operation information based on the controller control direction of the controller control event. In response to a skill release event, determine the player character's current orientation to generate corresponding player character orientation information, and use this player character orientation information as directional operation information; In response to skill release events, generate corresponding camera orientation information based on the current orientation of the camera in the game scene, and use this camera orientation information as pointing operation information; In response to a skill release event, generate corresponding player skill aiming direction information based on the skill aiming direction of the skill release event, and use the player skill aiming direction information as the pointing operation information.

4. The target locking method according to claim 1, characterized in that, The steps of updating the locking orientation of the three-dimensional locking region based on the pointing operation information, and calculating the spatial angle and spatial distance between one or more interactive objects in the three-dimensional locking region and the center of the three-dimensional locking region, include: Update the locking orientation of the 3D locking area based on the controller direction information, player character orientation information, camera orientation information, or player skill aiming direction information. Identify the interactive objects in the game scene that are located in the three-dimensional locking area, and filter out one or more first interactive objects with the highest locking priority among the interactive objects; From each of the first interactive objects, a second interactive object with a higher hate priority is selected, and the hate priority applies to the player character; Calculate the spatial angle and spatial distance between each of the second interactive objects and the center of the three-dimensional locked area.

5. The target locking method according to any one of claims 1 to 4, characterized in that, The step of selecting the candidate lockable interaction object with the smaller spatial distance as the final lockable interaction object includes at least one of the following steps: In response to the object removal event of the finally locked interactive object, cancel the object lock on the finally locked interactive object; In response to the player character's character control operation, the object lock on the final locked interactive object is cancelled. The character control operation includes the player character's jump operation, the player character's dodge operation, or the player character's movement operation. In response to an obstacle lock event triggered by an obstacle between the player character and the final locked interactive object, if the continuous response duration of the obstacle lock event exceeds a preset duration, the object lock on the final locked interactive object is cancelled. Monitor the camera's orientation change angle in the game scene. When the orientation change angle exceeds a preset angle, cancel the object lock on the finally locked interactive object.

6. The target locking method according to any one of claims 1 to 4, characterized in that, Following the step of selecting the candidate lock interaction object with the smaller spatial distance as the final lock interaction object, the method further includes: In response to the forced lock object command, the currently locked interactive object is used as the forced lock interactive object, and the camera in the game scene is controlled to face and follow the forced lock interactive object; In response to the command to quickly switch the locked object, determine the interaction object that is closest to the player character in space and has a lock priority greater than or equal to the current locked interaction object, and update that interaction object to the latest locked interaction object; Get the forced lock switching direction, and start from the current forced lock interaction object to detect the forced lock switching direction. If an interaction object is detected that is spatially close to the current forced lock interaction object and has a lock priority greater than or equal to the current forced lock interaction object, update the interaction object to the latest forced lock interaction object. In response to the object removal event of the currently forcibly locked interactive object, determine the interactive object that is closest to the player character in space and has a locking priority greater than or equal to the currently forcibly locked interactive object, and update that interactive object to the latest forcibly locked interactive object.

7. The target locking method according to any one of claims 1 to 4, characterized in that, Following the step of selecting the candidate lock interaction object with the smaller spatial distance as the final lock interaction object, the method further includes: Obtain the enhanced locking configuration information of the interactive object, which includes the radius of the enhanced locking area and the vertical height information of the enhanced locking area.

8. A target locking device, characterized in that, Implementing the target locking method according to any one of claims 1 to 7, comprising: The locked region generation module is configured to generate a three-dimensional locked region for the player character in the game scene, wherein the three-dimensional locked region is determined by geometric parameters representing the spatial shape and extent information of the locked region; The pointing operation acquisition module is configured to acquire pointing operation information corresponding to the player's pointing operation event, wherein the pointing operation information includes one of the following: controller direction information, player character orientation information, camera orientation information, and player skill pre-aiming direction information; The angle distance calculation module is configured to: update the locking orientation of the three-dimensional locking area according to the pointing operation information, and calculate the spatial angle and spatial distance between one or more interactive objects in the three-dimensional locking area and the center of the three-dimensional locking area, wherein the one or more interactive objects are determined by a preset locking priority and the aggro status of the player character; The interactive object locking module is configured to: filter out candidate locked interactive objects from each of the interactive objects whose spatial angle is within a preset generalization angle, and then select the candidate locked interactive objects with smaller spatial distances as the final locked interactive objects; Based on the enhanced locking configuration information of the interactive object, a corresponding enhanced locking columnar region is generated at the final locked interactive object; Real-time monitoring of one or more interactive objects existing in the enhanced locking column area; each interactive object with a locking priority greater than or equal to the final locked interactive object is selected as a candidate locked interactive object. In response to the lock release event of the final locked interactive object, the candidate locked interactive object that is spatially closest to the final locked interactive object is selected from among the candidate locked interactive objects, and this candidate locked interactive object is taken as the latest final locked interactive object.

9. A target locking device, comprising a central processing unit and a memory, characterized in that, The central processing unit is used to invoke and run a computer program stored in the memory to perform the steps of the method as described in any one of claims 1 to 7.

10. A non-volatile readable storage medium, characterized in that, It stores, in the form of computer-readable instructions, a computer program implemented according to any one of claims 1 to 7, which, when invoked by a computer, executes the steps included in the corresponding method.

Images