A game entity state synchronization method based on an interest region and a dynamic priority

Abstract

The application relates to a game entity state synchronization method and system based on an interest region and a dynamic priority, wherein a conical interest region and an extended buffer based on a player viewpoint parameter are constructed on a server side, and a multi-level region grading mechanism is established; in combination with dynamic factors such as distance attenuation, angle deviation, aiming target and new region preloading, the comprehensive priority score of effective synchronization entities is calculated in real time, and the continuity of the entity synchronization value is quantified; on this basis, the serialized data of the entities is assembled in descending order according to the comprehensive priority score, under the constraint of a network maximum transmission unit (MTU), the state data of high-value interactive entities is preferentially sent in advance, and the problem of high synchronization delay of core interactive entities and visual mutation at the edge of the field of view under the limited bandwidth is solved by cooperating with the differential rendering and interpolation transition mechanism of the client based on the priority score, efficient configuration of limited network resources in a high-density entity scene is realized, and the rendering continuity and core interaction accuracy of the client interface are improved.

Description

Technical Field

[0001] This application relates to the field of game development, and in particular to a method, apparatus, system, computer device, and computer-readable storage medium for synchronizing the states of game entities based on regions of interest and dynamic priorities. Background Technology

[0002] In massively multiplayer online games (MMORPGs, tactical shooter games, and open-world survival games), game servers need to synchronize a large amount of real-time entity state data to each client in every frame. This state data mainly includes world coordinates, rotation quaternions, animation state machine parameters, velocity vectors, and attribute values. Taking a high-density entity scenario on screen as an example, the number of entities synchronized in a single frame is enormous. The game network layer typically uses User Datagram Protocol (UDP) to carry state synchronization data because its connectionless and retransmission-free low-overhead characteristics meet the high-frequency, real-time-priority synchronization requirements. However, UDP does not provide congestion control or transmission order guarantees, and the network downlink bandwidth has a fixed upper limit. When the total number of entities to be synchronized exceeds the bandwidth capacity, packet loss or transmission delays will inevitably occur. How to prioritize the allocation of limited network bandwidth to the entities that have the most critical impact on the player's current interactive experience in a high-density entity scenario has become a pressing technical challenge in the field of game network synchronization.

[0003] Currently, no effective solutions have been proposed for the issues of bandwidth allocation and entity priority management in game network synchronization within related technologies. Existing technologies widely employ solutions primarily including distance-based circular region of interest (AOI) synchronization management and fixed-priority scheduling. The distance-based AOI solution maintains a circular region with a fixed radius centered on the player character's position for each client. Each frame, a spatial distance query is performed on synchronizeable entities in the scene, and only the state data of entities within this radius is sent. Although this type of solution is often paired with view frustum culling as supplementary filtering, its essence remains a binary synchronization decision model based on spatial distance (i.e., full synchronization or completely non-synchronous).

[0004] The aforementioned technologies suffer from the following drawbacks in practice: First, core interaction latency deteriorates significantly under bandwidth pressure. Circular regions of interest based solely on distance cannot perceive the player's visual attention direction and real-time interaction intent. When a player observes a distant target through the aiming device, the target may be located at or outside the edge of the circular region, and its state update is delayed due to the distance, resulting in noticeable visual position lag and shooting hit detection errors on the client side. Second, bandwidth utilization efficiency is low. Fixed priority scheduling mechanisms cannot dynamically adjust the synchronization priority of each entity based on the player's real-time actions such as aiming and approaching, causing entities outside the field of view or in non-interested areas to continuously occupy bandwidth resources. Third, the visual continuity of entity appearance and disappearance is poor. The hard boundary determination method based on frustum culling causes abrupt changes (pop-in) when entities enter or leave the edge of the field of view, and existing solutions lack a pre-loading mechanism for newly entering entities within the area of ​​interest, resulting in severe lag in the initial state data of entities when they first enter the field of view. Summary of the Invention

[0005] This application provides a method, system, computer device, and computer-readable storage medium for synchronizing the state of game entities based on regions of interest and dynamic priorities, in order to at least solve the problem of excessively high state synchronization delay of core interactive entities in related technologies.

[0006] In a first aspect, embodiments of this application provide a method for synchronizing the state of game entities based on regions of interest and dynamic priorities, characterized in that it is applied to a server, and the method includes: Obtain the player viewpoint parameters of the current game frame, and construct a cone-shaped region of interest containing different levels of regions based on the player viewpoint parameters; Based on the relative positions of synchronizable entities in the game scene and the cone-shaped region of interest, the synchronizable entities are classified into regions to determine the effective synchronizable entities. Based on the player's viewpoint parameters and the player's interaction intent, the overall priority score of the effective synchronization entity is dynamically calculated; The valid synchronized entities are sorted in descending order according to the comprehensive priority score, and under the constraint of the maximum transmission unit, the entity state data after the descending order is assembled into a data packet and sent to the client to instruct the client to perform differentiated rendering updates on the entity state according to the comprehensive priority score.

[0007] In some embodiments, obtaining the player's viewpoint parameters of the current game frame and constructing a cone-shaped region of interest containing different levels of regions based on the player's viewpoint parameters includes: Collect the camera's world coordinates, forward direction vector, horizontal field of view, and vertical field of view for the current game frame; Using the world coordinate position of the camera as the vertex and the forward direction vector of the camera as the central axis, a cone-shaped core region of interest is constructed based on the horizontal and vertical field of view angles. By extending the horizontal and vertical field of view by a preset extension angle outside the core area of ​​the cone-shaped region of interest, an extended buffer zone is constructed. The extended buffer and the core area of ​​the cone-shaped region of interest are taken as the cone-shaped region of interest, and the total horizontal angle and the total vertical angle of the cone-shaped region of interest are halved respectively to obtain the corresponding horizontal half angle and vertical half angle.

[0008] In some embodiments, the synchronizable entities are classified into regions based on their positions within the cone-shaped area of ​​interest in the game scene, and the effective synchronizable entities are determined to include: Calculate the distance and direction vector of the position of the synchronizeable entity relative to the world coordinate position of the camera; Determine the dot product between the direction vector and the camera's forward direction vector. If the dot product is greater than zero, calculate the horizontal and vertical offset angles of the direction vector relative to the camera's orientation. If the distance is between the preset near and far cutting surfaces, and the horizontal offset angle and the vertical offset angle are less than or equal to the horizontal half angle and the vertical half angle, respectively, the synchronizeable entity is marked as a valid synchronized entity.

[0009] In some embodiments, dynamically calculating the overall priority score of the effective synchronization entity based on the player's viewpoint parameters and the player's interaction intent includes: For each entity in the effective synchronization entity, calculate the distance attenuation factor, angle deviation factor, aiming target factor, and new entry region of interest preloading factor respectively; The distance attenuation factor, angle deviation factor, target aiming factor, and new region of interest preloading factor are multiplied by their respective preset weight coefficients and summed to obtain the comprehensive priority score of the effective synchronization entity.

[0010] In some embodiments, the distance attenuation factor and angle deviation factor are obtained in the following ways: Calculate the distance between the effective synchronization entity and the camera's world coordinate position, and based on the ratio of the distance to the preset maximum detection distance, calculate the distance attenuation factor that is negatively correlated with the distance; Calculate the ratio of the horizontal offset angle to the horizontal half-angle and the ratio of the vertical offset angle to the vertical half-angle of the effective synchronization entity, respectively. Select the larger of the two ratios as the reference deviation rate, and calculate the angle deviation factor based on the reference deviation rate.

[0011] In some embodiments, the methods for obtaining the targeting factor and the preloading factor for newly entered regions of interest include: Obtain the ray detection hit information reported by the client. If a valid synchronized entity is hit, set the target factor of the corresponding entity to the maximum set value; otherwise, set it to zero. Compare the region markers of the effective synchronization entity in the previous frame and the current frame. If the effective synchronization entity is a newly entered entity in the extended buffer in the current frame, determine its entry time. Within a preset preloading duration starting from the entry time, a preloading time factor that decays linearly with time is calculated; within an additional decay window after the preloading duration, a smooth transition factor is calculated based on an exponential decay function; and the preloading factor of the newly entered region of interest is determined according to the preloading time factor or the smooth transition factor.

[0012] In some embodiments, arranging the valid synchronization entities in descending order according to the comprehensive priority score, and assembling the serialized entity state data into a data packet and sending it to the client under the constraint of the maximum transmission unit, includes: The valid synchronization entities are sorted in descending order according to their comprehensive priority scores to generate a list of entities to be synchronized. Set the packet header metadata at the beginning of the sending buffer, and determine the highest overall priority score of the current data packet based on the overall priority score of the first entity in the list of entities to be synchronized, and write it into the packet header metadata; According to the order of the entity list to be synchronized, the status data and corresponding comprehensive priority score of each entity are serialized and appended to the sending buffer one by one, and after each entity is written, it is determined whether the data load in the sending buffer exceeds the maximum transmission unit limit. If the maximum transmission unit limit is exceeded, the most recent append operation is rolled back, the packet discard indicator flag is set to enabled, and the remaining low-priority entities that have not been loaded into the current frame data packet are either delayed or discarded. Obtain the overall priority score of the last entity successfully loaded into the current data packet, and update and write it into the packet header metadata as the lowest overall priority score; The data packet, containing complete packet header metadata and entity status data, is sent to the client.

[0013] In some embodiments, the client's differential rendering update of the entity state based on the comprehensive priority score includes: After receiving the data packet, the client parses the packet header metadata and entity status data to obtain the highest overall priority score, the lowest overall priority score, and the overall priority score of each entity. Based on the highest and lowest overall priority scores, a high-priority rendering threshold is determined, and it is then determined whether the overall priority score of each entity is greater than or equal to the high-priority threshold. If so, immediately update the rendering state of the corresponding entity in the current rendering frame; If not, obtain the previous frame state of the corresponding entity and perform linear interpolation within a preset interpolation period to smoothly transition the rendering state of the corresponding entity.

[0014] Secondly, embodiments of this application provide a game entity state synchronization system based on region of interest and dynamic priority, applied to a server. The system includes: an acquisition module, a filtering module, a priority calculation module, and a sorting and forwarding module, wherein: The acquisition module is used to acquire the player viewpoint parameters of the current game frame and construct a cone-shaped region of interest containing different levels of regions based on the player viewpoint parameters. The filtering module is used to classify the synchronizable entities into regions based on their relative positions with the cone-shaped region of interest in the game scene, so as to determine the effective synchronizable entities. The priority calculation module is used to dynamically calculate the comprehensive priority score of the effective synchronization entity based on the player's viewpoint parameters and the player's interaction intent. The sorting and forwarding module is used to sort the valid synchronized entities in descending order according to the comprehensive priority score, and under the constraint of the maximum transmission unit, assemble the entity state data after the descending order into a data packet and send it to the client, so as to instruct the client to perform differentiated rendering update of the entity state according to the comprehensive priority score.

[0015] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect above.

[0016] Compared to related technologies, the game entity state synchronization method and system based on region of interest and dynamic priority provided in this application establishes a multi-level region classification mechanism by constructing a cone-shaped region of interest and an extended buffer based on player viewpoint parameters on the server side. It combines dynamic factors such as distance attenuation, angle deviation, aiming target, and preloading of newly entered regions to calculate the comprehensive priority score of effectively synchronized entities in real time, achieving continuous quantification of entity synchronization value. Based on this, it performs descending-order assembly of entity serialization data according to the comprehensive priority score. Under the constraint of the network's maximum transmission unit (MTU), it prioritizes the pre-delivery of state data for high-value interactive entities. Combined with the client's differentiated rendering and interpolation transition mechanism based on priority scores, it solves the problems of excessively high synchronization latency of core interactive entities and visual abrupt changes at the edge of the field of view under limited bandwidth. This achieves efficient allocation of limited network resources in high-density entity scenes, improving the rendering continuity of the client interface and the accuracy of core interactions. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart of a game entity state synchronization method based on region of interest and dynamic priority according to an embodiment of this application; Figure 2 This is a structural block diagram of a game entity state synchronization system based on region of interest and dynamic priority, according to an embodiment of this application. Figure 3 This is an architecture diagram of a game entity state synchronization system based on region of interest and dynamic priority, according to an embodiment of this application. Figure 4 This is a schematic diagram of the internal structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0019] Obviously, the accompanying drawings described below are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar scenarios based on these drawings without any inventive effort. Furthermore, it is understood that although the efforts made in this development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, any changes to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

[0020] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0021] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units not listed, or may include other steps or units inherent to these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following objects are in an "or" relationship. The terms "first," "second," and "third" used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.

[0022] This embodiment provides a method for synchronizing the state of game entities based on regions of interest and dynamic priorities, applicable to client-server (C / S) architecture network systems consisting of a game logic server and multiple terminal devices. The game logic server is responsible for maintaining the state data of the game world, spatial partitioning data structures (such as octrees or uniform grids), and the connection and replication states of each client. The terminal devices can be smartphones, personal computers (PCs), or game consoles, responsible for receiving state data packets from the server and driving the local rendering engine to update the screen. High-frequency data communication between the server and terminal devices occurs via User Datagram Protocol (UDP) or a reliable transport protocol channel based on UDP encapsulation. Since UDP is prone to network congestion and out-of-order delivery under limited downlink bandwidth, the method described in this application primarily performs logic control in the network replication and packetization modules on the server side to optimize the data delivery mechanism.

[0023] This embodiment provides a method for synchronizing the state of game entities based on regions of interest and dynamic priorities. This method is primarily executed on the game logic server side, and through the following steps, it achieves the selection, priority calculation, packet scheduling, and distribution of game entities within a single frame. On the client side, it coordinates with the execution of state reorganization and differentiated rendering. Figure 1 This is a flowchart of a game entity state synchronization method based on region of interest and dynamic priority according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps: S10, obtain the player viewpoint parameters of the current game frame, and construct a cone-shaped region of interest containing different levels of regions based on the player viewpoint parameters; Specifically, it includes the following sub-steps: S101, collects player viewpoint parameters; At the beginning of each game frame (e.g., at a frequency of 30 ticks / s or 60 ticks / s), the game logic server extracts viewpoint parameters from the player state data of the current game frame. These viewpoint parameters specifically include: the camera's world coordinate position (labeled as a 3D vector P_cam), the camera's forward direction vector (labeled as a unit vector V_forward), the horizontal field of view (labeled as FOV_h), and the vertical field of view (labeled as FOV_v). In some embodiments, the horizontal field of view is between 60° and 120° (e.g., preferably 90°), and the vertical field of view is determined by the aspect ratio (e.g., approximately 58.7° in a 16:9 aspect ratio). These parameters are stored in the server's memory within a viewpoint parameter structure associated with the corresponding player entity, serving as the basis for subsequent spatial geometry determinations.

[0024] S102, construct a cone-shaped region of interest; The server uses the collected viewpoint parameters to construct a multi-level cone-shaped region of interest in a 3D world coordinate system. This step is specifically divided into the construction of a core area and an extension area: First, with the camera's world coordinate position P_cam as the vertex and the camera's forward direction vector V_forward as the central axis, half of the horizontal field of view and half of the vertical field of view are taken to construct the core area of ​​the cone-shaped region of interest (setting the horizontal half-angle θ_h_half=FOV_h / 2 and the vertical half-angle θ_v_half=FOV_v / 2). At the same time, the near clipping plane distance (e.g., 0.3 meters, for adapting to melee interaction) and the far clipping plane distance (e.g., 200.0 meters) of this core area are set to form a truncated cone space. Subsequently, an extension buffer is constructed outside the core area of ​​the cone-shaped region of interest. By extending the horizontal and vertical half-angles outward by a preset extension angle (denoted as Δθ, preferably between 5° and 30°, for example, 15°), a soft transition zone is formed. The core region and the extended buffer zone of a cone-shaped region of interest constitute a complete cone-shaped region of interest. By dividing this region into three levels—the core region, the extended buffer zone, and the remaining regions in world space—entities can obtain an initial priority benchmark based on their spatial location.

[0025] S20: Based on the relative positions of synchronizable entities and cone-shaped interest areas in the game scene, synchronizable entities are classified into regions to determine effective synchronizable entities.

[0026] The server iterates through all synchronizable entities (entity index i=1,2,…,N_total) in the game scene where the current player is located, and performs spatial location determination for each entity.

[0027] First, calculate the distance (denoted as d_i) and direction vector (denoted as D_i) of the world coordinate position of the synchronized entity relative to the world coordinate position of the camera P_cam. The server calculates the distance d_i = ||P_i - P_cam|| of the world coordinate position P_i of entity i relative to P_cam, and the direction vector D_i = (P_i - P_cam) / d_i.

[0028] First, a forward orientation determination is performed: if D_i·V_forward≤0 (i.e., the entity is behind the camera), then entity i is directly marked as region C (low-priority entity), and no further angle determination is performed. If D_i·V_forward>0 (i.e., the entity is in front of the camera), then the off-axis angle of the entity relative to the camera's orientation is calculated: the direction vector D_i and the camera's forward vector V_forward are projected onto the horizontal plane (XOZ plane) respectively, resulting in horizontal projection vectors D_i_h and V_forward_h, where θ_h_i is the angle between the two vectors.

[0029] Next, calculate the vertical offset angle θ_v_i: Take the angle between the direction vector D_i and the horizontal plane (i.e., the elevation angle of entity i relative to the camera position) and subtract the angle between the camera's forward vector V_forward and the horizontal plane (i.e., the camera's pitch angle), and take the absolute value, i.e., θ_v_i = |pitch(D_i). pitch(V_forward)|.

[0030] This method is simple to calculate and has a clear geometric and physical meaning—that is, "the angle between the entity's direction and the camera's orientation in the vertical direction"—and avoids the geometric ambiguity caused by the tilted projection plane due to the existence of a pitch angle in V_forward.

[0031] Furthermore, if d_i is between the near clipping plane and the far clipping plane, and the horizontal offset angle θ_h_i ≤ θ_h_half + Δθ and the vertical offset angle θ_v_i ≤ θ_v_half + Δθ (i.e., the entity is located within region A or region B), then entity i is marked as a valid synchronization entity; otherwise, entity i is marked as a low-priority entity in region C. For entities within the extended half-angle range, it is further determined whether they simultaneously satisfy θ_h_i ≤ θ_h_half and θ_v_i ≤ θ_v_half. If so, they are marked as region A (high-priority basic candidate); otherwise, they are marked as region B (medium-priority basic candidate). The determination result is written to the entity priority marking table T_zone (hash table structure, key is entity_id (uint32), value is the region enumeration A / B / C).

[0032] The above steps S10 and S20 work together to replace the traditional circular AOI with a cone-shaped region of interest based on the player's camera direction and field of view (FOV). This allows for a more accurate perception of the player's real-time visual attention distribution. It avoids the problem in traditional solutions where numerous entities located outside or behind the player's field of vision blindly compete for synchronization bandwidth, initially focusing limited network resources on the visible range and laying an efficient spatial geometric foundation for subsequent on-demand state synchronization.

[0033] Optionally, as an alternative to the region classification based on the cone-shaped region of interest in steps S10 to S20 above, a priority-based approach based on cone depth layering can be used instead of cone-shaped region of interest determination: The server divides the cone along the depth direction (camera forward axis) into three depth zones, such as the near-field zone (0 to 15 meters), the mid-field zone (15 to 60 meters), and the far-field zone (60 to 200 meters). Entities within the near-field zone are directly labeled as region A, entities within the mid-field zone as region B, and entities within the far-field zone as region C, without further determination of the off-axis angle. This alternative eliminates complex calculations such as inverse trigonometric functions, resulting in lower computational complexity and significantly saving server CPU resources. It is particularly suitable for edge computing or mobile game server nodes with extremely high performance budget requirements.

[0034] S30 dynamically calculates the overall priority score of valid synchronized entities based on player viewpoint parameters and player interaction intent.

[0035] For all valid synchronization entities selected in the above steps, the server calculates their comprehensive priority score (denoted as P(i)), which is obtained by weighted summation of four dynamic factors: distance decay factor, angle deviation factor, target aiming factor, and new region of interest preloading factor. Specifically, this includes the following steps: S301, detect newly entered entities in the ROI; The server maintains a table of entity region labels T_zone_prev from the previous frame. After completing step S20, the server compares the current frame's T_zone with T_zone_prev entity by entity. For entity i that satisfies the condition "T_zone[i]∈{A,B} and T_zone_prev[i]=C" (i.e., entities newly entering the extended ROI range in this frame), the server marks it as a newly entered ROI entity, sets its preload flag F_preload to 1, and records the timestamp t_entry (in milliseconds, taken from the server's game logic clock) of the entry time.

[0036] S302, Calculate the preloaded weights of newly added ROI entities; For an entity with F_preload=1, the server calculates its preload duration factor f_newROI(i)=max(0,1-(t_now-t_entry) / T_boost), where T_boost is the preload duration and t_now is the game logic time of the current frame.

[0037] In a preferred embodiment, T_boost is set to 500 milliseconds (T_boost should be longer than the time required for a single quick turn, typically within the range of 200 to 1000 milliseconds, to ensure that the entity has been initialized while the player is turning their view). The preloading time factor linearly decays from 1.0 to 0 within this time window. Beyond the T_boost window, the entity is no longer affected by preloading weighting. However, to avoid a sudden shift in the sorting list due to a step drop in priority score the moment the entity leaves the preloading window (which could trigger a sudden change in client rendering state), the server applies an additional smooth decay transition after the preloading weighting is revoked: within an additional decay window T_fade (150 milliseconds in a preferred embodiment, but selectable within the range of 100 to 200 milliseconds) from the revocation time, the preloading factor is exponentially decayed by f_smooth(t) = ×exp( (t t_entry T_boost) / τ), where The preloading factor is the actual value in the frame before unloading, τ = T_fade / 3, which smoothly returns the weighted contribution to zero. This design ensures that entities that have just entered the edge of the player's field of view receive a priority boost for a short period of time, avoiding the pop-in phenomenon, and also preventing abrupt changes in visual state when the weighting is unloaded.

[0038] The preloading mechanism for newly entered regions of interest in steps S301 to S302 significantly improves the visual continuity of entity appearance and disappearance, greatly reducing pop-in phenomena. Because a short-term priority weighting is applied to entities just entering the edge region, it ensures that the initial state of the entity (such as complete position, animation frame configuration, etc.) is received and initialized by the client before entering the player's core field of view, thus solving the visual abruptness problem at hard boundaries in traditional frustum culling schemes.

[0039] S303, Performs aiming ray detection; The server performs a raycast on the current player, starting from the camera position P_cam and extending in the forward direction V_forward. The maximum ray detection distance is 200.0 meters, and the collision mask is set to the interactive entity layer. If the ray hits an entity i_aim, the server sets the aiming flag F_aim of that entity to 1; for all other entities, F_aim is set to 0. If the ray does not hit any entity, the F_aim of all entities is 0.

[0040] In a preferred embodiment, to eliminate misjudgment of the target due to network latency (i.e., the player's position and orientation used by the server are the state of the client at a certain point in the past, and the ray detection result calculated independently by the server may be inconsistent with the player's actual target), the server does not perform independent ray detection, but instead receives the aiming hit information reported by the client.

[0041] Specifically, each frame, the client performs ray detection from the center of the camera along its direction. If an interactive entity is hit, the client sends the entity's unique identifier (entity_id) and the client's local timestamp at the time of the hit to the server via a UDP channel. When executing step S303, the server directly uses the latest entity_id reported by the client to mark the corresponding entity as F_aim=1, and all other entities as F_aim=0. Even if there is network latency in this uplink information, since the game frame rate (usually 30-60 frames / second) is much higher than human reaction speed (usually 200-300 milliseconds), this short-term lag in target switching is still within an acceptable range, and prioritizes the client's realistic interactive experience, avoiding target misjudgment caused by server-side independent ray detection due to state lag.

[0042] This aiming ray detection and priority-boosting mechanism significantly reduces the loss rate of critical combat interaction data packets, improving combat fairness. It can also capture the player's most purposeful interaction intentions in real time, assigning the highest weight to entities the player is aiming at or engaging in close combat. For distant targets locked by high-magnification scopes, the update latency is drastically reduced from hundreds of milliseconds in traditional solutions to tens of milliseconds, effectively improving the accuracy and responsiveness of hit detection in shooting games.

[0043] S304, Calculate the entity's overall priority score; For all entities (denoted as N_candidate) marked as region A and region B in step S20, the server calculates the comprehensive priority score P(i) for each entity, as follows: P(i)=α×P_proximity(i)+β×P_angular(i)+γ×P_aim(i)+δ×P_newROI(i) The definitions and weights of each component are shown in the table below: P_proximity(i) is the distance attenuation factor, which is calculated as follows: P_proximity(i)=max(0,1-d_i / D_max), optionally, D_max=200.0 meters, α=0.30.

[0044] P_angular(i) is the angular deviation factor, calculated as: P_angular(i) = max(0, 1 - max(θ_h_i / θ_h_half, θ_v_i / θ_v_half)). It takes the larger of the ratios of the horizontal and vertical offset angles to their respective half-angles, with higher values ​​closer to the center of vision. It's worth noting that the max operator is used in this embodiment because an entity may deviate significantly from the center of vision only in one direction (horizontal or vertical). In this case, the direction with the greater deviation is used as the representation of the overall angular deviation, and a corresponding weight is applied. Using min or the mean would underestimate the actual impact of a large deviation in a single direction on the interactive experience—for example, an entity may be horizontally off-center (θ_h_i / θ_h_half ≈ 1.0) but vertically centered (θ_v_i / θ_v_half ≈ 0). The entity's visual recognizability and interactive usability for the player are already very low. Using min would result in P_angular ≈ 0, severely underestimating its deviation, β = 0.25.

[0045] P_aim(i) is the target factor, which is 1.0 if F_aim=1 and 0 otherwise, and γ=0.35.

[0046] P_newROI(i) is the preloading factor for the newly entered region of interest, δ=0.10.

[0047] It can be understood that the above weighting coefficients satisfy α+β+γ+δ=1. Among them, aiming interaction intent (γ) is the most direct player behavior signal and is given the highest weight; distance (α) and angle (β) reflect the spatial attention distribution of entities and are given secondary weights; new ROI preloading (δ) serves as a temporary compensation mechanism and has the lowest weight. In actual configuration, the value of γ is usually not less than 0.3 to highlight the priority of interaction intent, and the value of δ is usually not greater than 0.15 to avoid excessive disturbance to the priority of entities in stable scenes. In this embodiment, the selection of weighting coefficients reflects the relative importance ranking of priority factors, and each weighting coefficient can be adjusted according to the game type (e.g., FPS emphasizes aiming, MMORPG emphasizes distance) under the premise of satisfying normalization constraints.

[0048] The overall priority score P(i) is a normalized value, ranging from [0,1]. For entities in region C, since they are completely outside the player's field of view, these entities do not participate in the synchronization of this frame, and their state changes have no impact on the player's experience, making the synchronization meaning extremely low; therefore, P(i) is directly assigned the value 0. After calculating P(i) for each entity, it is stored in the priority score table T_priority. Optionally, this score table adopts a key-value pair structure, with the key being entity_id and the value being P(i)).

[0049] As an alternative to the real-time calculation of the comprehensive priority score in step S30 above, a static priority evaluation scheme based on historical interaction frequency can be adopted. The server maintains an entity interaction frequency table for each player, recording the number of interactions with each entity within a specific time window (such as aiming duration, attack judgment, etc.). Priority is directly assigned based on this interaction frequency when assembling the game. This scheme avoids the huge geometric calculation overhead per frame and is suitable for large-scale game scenarios such as MMORPGs with slow interaction pace and a large number of players on screen at the same time.

[0050] As an alternative implementation of the priority calculation in step S30 above, a priority evaluation scheme based on a machine learning prediction model can also be introduced. Using a pre-trained lightweight neural network model, inputting feature vectors such as the entity's relative distance, off-axis angle, relative velocity, and historical priority state, the scheme directly outputs the entity's predicted priority score in the current frame. This scheme can keenly capture the player's complex behavioral habits and differences in attention distribution under different weapon conditions, making bandwidth allocation more human-like.

[0051] S40: Arrange the valid synchronization entities in descending order according to the comprehensive priority score, and assemble the data packets under the constraint of the maximum transmission unit.

[0052] Valid synchronization entities with calculated scores greater than zero are sorted in descending order of their overall priority scores to generate a list of entities to be synchronized. In this list, entities ranked higher have a more significant impact on the player's current visual and interactive experience due to their state data. The specific steps include: S401, sort entities in descending order of priority score; The server retrieves all entities with P(i) > 0 from the priority score table T_priority, forming a list L_sync of entities to be synchronized. L_sync is then sorted in descending order of P(i). If P(i) are equal, the distance d_i is used as the secondary sorting key in ascending order. The sorted list is denoted as L_sorted = [e_1, e_2, ..., e_M], where P(e_1) ≥ P(e_2) ≥ ... ≥ P(e_M), and M is the number of entities to be synchronized.

[0053] S402, Write packet header metadata and serialized entity status to UDP payload; The server first writes a packet header metadata structure at the beginning of the send buffer B_send. This packet header contains the following fields: (i) The highest overall priority score P_max (uint8, 1 byte, the P_quant value of the first entity in L_sorted) and the lowest overall priority score P_min (uint8, 1 byte, the P_quant value of the last entity in L_sorted) of the entities contained in the current data packet. (ii) Drop flag F_drop(uint8, 1 byte, set to 1 if there are lower priority entities dropped due to MTU overflow, otherwise set to 0); (iii) Packet sequence number seq_id (uint16, 2 bytes, monotonically increasing counter, incrementing by 1 for each data packet sent, used by the client to detect packet loss). The packet header is 5 bytes long, and the initial value of S_payload is the packet header length of 5 bytes.

[0054] Step S40, through absolute priority sorting within packets and MTU truncation, can significantly reduce the latency of core interactive entities and significantly improve overall bandwidth utilization efficiency. High-value entity data is always sent with absolute priority right next to the packet header, resulting in an order-of-magnitude improvement in its resilience to packet loss when facing network fluctuations. At the same time, low-value data is actively delayed or decisively discarded when bandwidth is maxed out, avoiding unnecessary preemption of invalid entities under traditional fixed priority. The saved bandwidth can support a higher density of simultaneous interactive players in the game.

[0055] As an alternative implementation to packet serialization in step S40, a priority-based differentiated data granularity scheme can be used instead of a uniform fixed-length format. Based on priority scores, high-priority entities are serialized in "full synchronization mode" (including all data such as coordinates, rotations, animations, equipment configurations, and health points); medium-priority entities are serialized in "simplified synchronization mode"; and low-priority entities are serialized in "location-only synchronization mode" (only IDs and coordinates are retained, with the rest calculated by the client cache). Under the same MTU constraint, this scheme can increase the number of entity entries per packet by 40% to 60%, further alleviating bandwidth anxiety in weak network environments.

[0056] As an alternative to the single UDP transmission mechanism in step S40, a server-based downlink multi-channel distribution mechanism can also be adopted. The server establishes three independent UDP port channels for each client, corresponding to high, medium, and low priorities respectively, and configures different physical bandwidth quotas and transmission frame rates for each channel at the transport layer. This scheme achieves complete priority flow isolation at the network layer, ensuring that core combat commands are never congested by state updates from massive edge entities.

[0057] S50: The client performs differentiated rendering updates on the entity status based on the overall priority score.

[0058] S501, the client receives UDP packets; Client terminal devices (mobile phones / PCs / game consoles) receive data packets from the server via UDP sockets and store them in the receive buffer B_recv.

[0059] S502, parsing packet header marks and entity data; The client first reads 5 bytes of packet header metadata from the first 5 bytes of the receiving buffer B_recv, and obtains P_max, P_min, F_drop and the packet division sequence number seq_id. The client determines whether a packet loss occurs by checking the continuity of seq_id: if the currently received seq_id is not equal to the previous packet's seq_id + 1, it is marked as a packet loss event, and extrapolation compensation is enabled for the affected low-priority entities. Subsequently, the client sequentially parses the entity state data after the packet header in B_recv in units of 24 bytes. For each parsed entity, the client reads its comprehensive priority score P_quant (a uint8 field), restores it to P(i)=P_quant / 255.0, and makes a determination at decision node D401: if P(i)≥P_high (that is, the entity belongs to a high-priority entity, and P_high is 0.60 in a preferred embodiment), step S503 is performed; if P(i)<P_high (that is, the entity belongs to a medium / low-priority entity), step S504 is performed.

[0060] S503, immediately updating the entity rendering state; For high-priority entities, the client directly writes the parsed position, rotation and animation state into the entity's TransformComponent and AnimationController, which takes effect immediately in the current rendering frame, ensuring zero-latency response of core interactive objects.

[0061] S504, acquiring the old state of the previous frame to perform linear interpolation; For medium / low-priority entities, the client acquires the old state S_old={P_old,R_old,A_old} of the entity in the previous frame from the local entity state history cache, takes the parsed new state S_new={P_new,R_new,A_new} as the interpolation target, and performs linear interpolation within the interpolation period T_interp (in a preferred embodiment, T_interp is 100 milliseconds, and this value can be adjusted within the range of 50 to 200 milliseconds according to the server frame rate, and its selection principle is to make the interpolation period cover 2 to 3 server frame periods to balance smoothness and responsiveness): S_current(t)=lerp(S_old,S_new,clamp((t-t_recv) / T_interp,0,1)). If an entity has no new state data arriving because it was discarded by the server in step S40, the client uses the old state of the previous frame combined with the last known velocity vector for extrapolation estimation. This mechanism ensures that non-core entities can still maintain visually smooth movement without abrupt teleportation or freezing when data update is not timely.

[0062] The client's tiered rendering and interpolation reassembly mechanism, combined with the server's proactive truncation strategy, forms a perfect visual closed-loop compensation. Even if non-core entities encounter "delayed transmission" or "direct discarding" on the server side, the smooth transition of the client's local state history cache and the known speed extrapolation mechanism still ensure that these peripheral entities maintain a visually smooth movement trajectory. While maximizing network throughput, the perceptual continuity of the player's panoramic view is not sacrificed.

[0063] Through the above steps S10 to S50, the coordinated efforts of server-side multi-dimensional geometric region division, dynamic priority precise quantification and packet sorting truncation strategy, and client-side hierarchical rendering compensation mechanism enable this game entity state synchronization method based on region of interest and dynamic priority to efficiently tilt network throughput resources toward high interactive value data within a strictly limited UDP bandwidth pipeline, thus mitigating the latency impact of massive entity data on the core control experience.

[0064] This application also provides a game entity state synchronization system based on regions of interest and dynamic priorities. Figure 2 This is a structural block diagram of a game entity state synchronization system based on region of interest and dynamic priority, according to an embodiment of this application. Figure 2 As shown, the system includes: an acquisition module 20, a filtering module 21, a priority calculation module 22, and a sorting and forwarding module 23, wherein: The acquisition module 20 is used to acquire the player viewpoint parameters of the current game frame and construct a cone-shaped region of interest containing different levels of areas based on the player viewpoint parameters; The filtering module 21 is used to classify synchronizeable entities into regions based on their relative positions with the cone-shaped interest region in the game scene, so as to determine the effective synchronizeable entities. The priority calculation module 22 is used to dynamically calculate the comprehensive priority score of effective synchronized entities based on the player's viewpoint parameters and the player's interaction intent. The sorting and forwarding module 23 is used to sort the valid synchronized entities in descending order according to the comprehensive priority score, and under the constraint of the maximum transmission unit, assemble the entity state data after the descending order into a data packet and send it to the client, so as to instruct the client to perform differentiated rendering updates of the entity state according to the comprehensive priority score.

[0065] also, Figure 3 This is an architecture diagram of a game entity state synchronization system based on region of interest and dynamic priority, according to an embodiment of this application.

[0066] Through the aforementioned system, a cone-shaped region of interest and an extended buffer based on player viewpoint parameters are constructed on the server side, establishing a multi-level region classification mechanism. Combining dynamic factors such as distance attenuation, angle deviation, aiming target, and preloading of newly entered regions, the comprehensive priority score of effective synchronized entities is calculated in real time, realizing the continuous quantification of entity synchronization value. On this basis, the entity serialization data is assembled in descending order according to the comprehensive priority score. Under the constraint of the network maximum transmission unit (MTU), the state data of high-value interactive entities is prioritized for pre-delivery. Combined with the client's differentiated rendering and interpolation transition mechanism based on priority scores, the problems of excessive synchronization latency of core interactive entities and visual abrupt changes at the edge of the field of view under limited bandwidth are solved. This achieves efficient allocation of limited network resources in high-density entity scenes, improving the rendering continuity of the client interface and the accuracy of core interactions.

[0067] In one embodiment, Figure 4 This is a schematic diagram of the internal structure of an electronic device according to an embodiment of this application, such as... Figure 4 As shown, an electronic device is provided, which can be a server, and its internal structure diagram can be as follows. Figure 4 As shown, the electronic device includes a processor, a network interface, internal memory, and non-volatile memory connected via an internal bus. The non-volatile memory stores the operating system, computer programs, and a database. The processor provides computing and control capabilities, the network interface communicates with external terminals via a network connection, the internal memory provides the environment for the operating system, the computer programs are executed by the processor to implement a method for synchronizing the states of game entities based on regions of interest and dynamic priorities, and the database stores data.

[0068] 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 electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0069] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0070] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for synchronizing the state of game entities based on regions of interest and dynamic priorities, characterized in that, Applied to a server, the method includes: Obtain the player viewpoint parameters of the current game frame, and construct a cone-shaped region of interest containing different levels of regions based on the player viewpoint parameters; Based on the relative positions of synchronizable entities in the game scene and the cone-shaped region of interest, the synchronizable entities are classified into regions to determine the effective synchronizable entities. Based on the player's viewpoint parameters and the player's interaction intent, the overall priority score of the effective synchronization entity is dynamically calculated; The valid synchronized entities are sorted in descending order according to the comprehensive priority score, and under the constraint of the maximum transmission unit, the entity state data after the descending order is assembled into a data packet and sent to the client to instruct the client to perform differentiated rendering updates on the entity state according to the comprehensive priority score.

2. The game entity state synchronization method according to claim 1, characterized in that, Obtaining the player's viewpoint parameters for the current game frame, and constructing a cone-shaped region of interest containing different levels of areas based on the player's viewpoint parameters, includes: Collect the camera's world coordinates, forward direction vector, horizontal field of view, and vertical field of view for the current game frame; Using the world coordinate position of the camera as the vertex and the forward direction vector of the camera as the central axis, a cone-shaped core region of interest is constructed based on the horizontal and vertical field of view angles; By extending the horizontal and vertical field of view by a preset extension angle outside the core area of ​​the cone-shaped region of interest, an extended buffer zone is constructed. The extended buffer and the core area of ​​the cone-shaped region of interest are taken as the cone-shaped region of interest, and the total horizontal angle and the total vertical angle of the cone-shaped region of interest are halved respectively to obtain the corresponding horizontal half angle and vertical half angle.

3. The game entity state synchronization method according to claim 2, characterized in that, Based on the location of synchronizable entities within the cone-shaped area of ​​interest in the game scene, the synchronizable entities are classified into regions to determine the effective synchronizable entities, including: Calculate the distance and direction vector of the position of the synchronizeable entity relative to the world coordinate position of the camera; Determine the dot product between the direction vector and the camera's forward direction vector. If the dot product is greater than zero, calculate the horizontal and vertical offset angles of the direction vector relative to the camera's orientation. If the distance is between the preset near and far cutting surfaces, and the horizontal offset angle and the vertical offset angle are less than or equal to the horizontal half angle and the vertical half angle, respectively, the synchronizeable entity is marked as a valid synchronized entity.

4. The game entity state synchronization method according to claim 2, characterized in that, The dynamic calculation of the comprehensive priority score of the effective synchronized entity based on the player's viewpoint parameters and the player's interaction intent includes: For each entity in the effective synchronization entity, calculate the distance attenuation factor, angle deviation factor, aiming target factor, and new entry region of interest preloading factor respectively; The distance attenuation factor, angle deviation factor, target aiming factor, and new region of interest preloading factor are multiplied by their respective preset weight coefficients and summed to obtain the comprehensive priority score of the effective synchronization entity.

5. The game entity state synchronization method according to claim 4, characterized in that, The methods for obtaining the distance attenuation factor and the angle deviation factor include: Calculate the distance between the effective synchronization entity and the camera's world coordinate position, and based on the ratio of the distance to the preset maximum detection distance, calculate the distance attenuation factor that is negatively correlated with the distance; Calculate the ratio of the horizontal offset angle to the horizontal half-angle and the ratio of the vertical offset angle to the vertical half-angle of the effective synchronization entity, respectively. Select the larger of the two ratios as the reference deviation rate, and calculate the angle deviation factor based on the reference deviation rate.

6. The game entity state synchronization method according to claim 4, characterized in that, The methods for obtaining the target factor and the preloaded factor for the newly entered region of interest include: Obtain the ray detection hit information reported by the client. If a valid synchronized entity is hit, set the target factor of the corresponding entity to the maximum set value; otherwise, set it to zero. Compare the region markers of the effective synchronization entity in the previous frame and the current frame. If the effective synchronization entity is a newly entered entity in the extended buffer in the current frame, determine its entry time. Within a preset preloading duration starting from the entry time, a preloading time factor that decays linearly with time is calculated; within an additional decay window after the preloading duration, a smooth transition factor is calculated based on an exponential decay function; and the preloading factor of the newly entered region of interest is determined according to the preloading time factor or the smooth transition factor.

7. The game entity state synchronization method according to claim 1, characterized in that, The effective synchronization entities are sorted in descending order according to the comprehensive priority score, and the serialized entity state data is assembled into a data packet and sent to the client under the constraint of the maximum transmission unit, including: The valid synchronization entities are sorted in descending order according to their comprehensive priority scores to generate a list of entities to be synchronized. Set the packet header metadata at the beginning of the sending buffer, and determine the highest overall priority score of the current data packet based on the overall priority score of the first entity in the list of entities to be synchronized, and write it into the packet header metadata; According to the order of the entity list to be synchronized, the status data and corresponding comprehensive priority score of each entity are serialized and appended to the sending buffer one by one, and after each entity is written, it is determined whether the data load in the sending buffer exceeds the maximum transmission unit limit. If the maximum transmission unit limit is exceeded, the most recent append operation is rolled back, the packet discard indicator flag is set to enabled, and the remaining low-priority entities that have not been loaded into the current frame data packet are either delayed or discarded. Obtain the overall priority score of the last entity successfully loaded into the current data packet, and update and write it into the packet header metadata as the lowest overall priority score; The data packet, containing complete packet header metadata and entity status data, is sent to the client.

8. The game entity state synchronization method according to claim 7, characterized in that, The client performs differentiated rendering updates on the entity state based on the comprehensive priority score, including: After receiving the data packet, the client parses the packet header metadata and entity status data to obtain the highest overall priority score, the lowest overall priority score, and the overall priority score of each entity. Based on the highest and lowest overall priority scores, a high-priority rendering threshold is determined, and it is then determined whether the overall priority score of each entity is greater than or equal to the high-priority threshold. If so, immediately update the rendering state of the corresponding entity in the current rendering frame; If not, obtain the previous frame state of the corresponding entity and perform linear interpolation within a preset interpolation period to smoothly transition the rendering state of the corresponding entity.

9. A game entity state synchronization system based on region of interest and dynamic priority, characterized in that, Applied to a server, the system includes: an acquisition module, a filtering module, a priority calculation module, and a sorting and forwarding module, wherein: The acquisition module is used to acquire the player viewpoint parameters of the current game frame and construct a cone-shaped region of interest containing different levels of regions based on the player viewpoint parameters. The filtering module is used to classify the synchronizable entities into regions based on their relative positions with the cone-shaped region of interest in the game scene, so as to determine the effective synchronizable entities. The priority calculation module is used to dynamically calculate the comprehensive priority score of the effective synchronization entity based on the player's viewpoint parameters and the player's interaction intent. The sorting and forwarding module is used to sort the valid synchronized entities in descending order according to the comprehensive priority score, and under the constraint of the maximum transmission unit, assemble the entity state data after the descending order into a data packet and send it to the client, so as to instruct the client to perform differentiated rendering update of the entity state according to the comprehensive priority score.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 8.

Images