Boids flocking behavior method and device, storage medium and computer device

Abstract

This application discloses a method, apparatus, storage medium, and computer device for representing a Boids cluster. The method includes: obtaining a set of valid Boid indexes created by a server, and creating a skeletal mesh corresponding to each Boid in the set of valid Boid indexes; selecting a preset number of Boids with animation instances as master Boids, and the remaining Boids as child Boids, and determining the target Boid that each child Boid follows in each master Boid; generating skeletal pose data for each master Boid by creating real animation instances with different animation playback rhythms, and reusing the skeletal pose data of the master Boids that the child Boids follow; updating the motion data of each Boid in the local tick, without synchronizing the motion data to the server; and driving the skeletal mesh corresponding to each Boid to play animations according to the skeletal pose data and motion data of each Boid.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, storage medium, and computer device for representing Boids clusters. Background Technology

[0002] With the rapid development of digital simulation, game engines, and real-time rendering technologies, the dynamic performance of large-scale swarm intelligence agents has become one of the core requirements in virtual scene construction. In many application scenarios such as film and animation, open-world games, and virtual simulation exercises, it is often necessary to simultaneously present dozens or even hundreds of virtual character clusters with collaborative movement characteristics. These clusters typically achieve natural group movement effects such as gathering, dispersing, and following based on the Boids swarm behavior model, significantly enhancing the immersion and realism of virtual scenes. Currently, this type of large-scale Boids cluster rendering technology is widely used in various client-side rendering scenarios, becoming a key technical support for enriching the content layers of virtual worlds and creating grand scene atmospheres. However, its performance remains a core bottleneck affecting scene smoothness.

[0003] Currently, the mainstream implementation of Boids clusters in the industry generally adopts a technical approach of independently driving each character: after receiving all valid Boid indexes from the server, the client creates a corresponding independent skeletal mesh and a dedicated animation instance for each Boid character. Each frame, skeletal pose data is calculated individually for all Boids, while simultaneously updating all motion data such as position, velocity, and rotation. Finally, the animation rendering is driven by the independently generated pose and motion data of each Boid. Some existing solutions also synchronize the motion data of all Boids to the server frame by frame to ensure the consistency of the cluster's motion state across multiple scenarios, thereby achieving a complete dynamic representation of the Boids group.

[0004] However, existing technologies still have significant technical shortcomings in real-world large-scale cluster rendering scenarios: On the one hand, when the number of Boid clusters is large, creating all independent animation instances and generating skeletal pose data for all characters frame by frame will consume a large amount of CPU and GPU computing resources on the client, easily causing problems such as decreased scene frame rate and rendering stuttering, seriously affecting the user's real-time interactive experience; on the other hand, the mechanism of synchronizing the motion data of all Boids to the server frame by frame will greatly increase the network transmission bandwidth pressure between the client and the server, which will not only easily cause network data congestion, but also further aggravate the server's computing load, ultimately making it difficult for large-scale Boid clusters to run smoothly and stably on ordinary terminal devices, and failing to balance the cluster performance with the system's operating performance. Summary of the Invention

[0005] In view of this, embodiments of this application provide a Boids cluster representation method, apparatus, storage medium, and computer device.

[0006] According to one aspect of this application, a Boids cluster behavior method is provided, applied to a client, the method comprising: Obtain the set of valid Boid indices created by the server, and create the bone mesh corresponding to each Boid in the set of valid Boid indices; In the set of valid Boid indices, select a Boid with a preset number of animation instances as the main Boid, and use the remaining Boids as child Boids. In each main Boid, determine the target Boid that each child Boid follows; wherein, the preset number of animation instances is less than the number of Boids in the set of valid Boid indices. Create realistic animation instances with different animation playback rhythms for each main Boid, generate skeletal pose data for each frame from the realistic animation instances of the main Boid, and reuse the skeletal pose data of the following main Boid for the sub-Boid. The motion data of each Boid is updated in the local Tick without synchronizing the motion data to the server. The motion data includes position, speed and rotation data. Based on the skeletal pose and motion data of each Boid, the corresponding skeletal mesh of each Boid is driven to play animation.

[0007] According to another aspect of this application, a Boids cluster representation apparatus is provided, the apparatus comprising: The skeleton mesh creation module is used to obtain the set of valid Boid indices created by the server and create a skeleton mesh corresponding to each Boid in the set of valid Boid indices. The master-slave Boid determination module is used to select a preset number of Boids as master Boids from the set of valid Boid indexes, and the remaining Boids as child Boids, and to determine the target Boid that each child Boid follows in each master Boid; wherein, the preset number of animation instances is less than the number of Boids in the set of valid Boid indexes. The skeletal pose determination module is used to create realistic animation instances with different animation playback rhythms for each main Boid. Skeletal pose data is generated for each frame of the realistic animation instance of the main Boid, and the sub-Boid reuses the skeletal pose data of the following main Boid. The motion data update module is used to update the motion data of each Boid in the local Tick without synchronizing the motion data to the server. The motion data includes position, speed and rotation data. The animation playback module is used to drive the corresponding skeletal mesh of each Boid to play animations based on the skeletal pose data and motion data of each Boid.

[0008] According to another aspect of this application, a storage medium is provided that stores a computer program thereon, which, when executed by a processor, implements the above-described Boids cluster representation method.

[0009] According to another aspect of this application, a computer device is provided, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the program to implement the above-described Boids cluster representation method.

[0010] Using the above technical solutions, this application provides a method, apparatus, storage medium, and computer device for representing a Boids cluster. The client obtains a set of valid Boid indexes maintained by the server and creates a skeletal mesh for all Boids accordingly. A preset number of Boids (less than the total number of Boids) are selected from the set as the main Boids, and realistic animation instances are created for them to generate skeletal pose data. The remaining child Boids reuse the skeletal pose data of the main Boids they follow. All Boids independently update their position, velocity, rotation, and other motion data in their local ticks without synchronizing with the server. Finally, the skeletal pose data and motion data are combined to drive the skeletal meshes of each Boid to complete the animation playback. Through the embodiments of this application, the number of client-side animation instances is no longer equivalent to the number of Boid representations, thus decoupling the animation computation load from the cluster size and reducing client-side animation overhead; motion data is maintained entirely locally without reporting to the server, reducing the amount of network synchronization data; each Boid has an independent local computation position, giving the cluster a reasonable spatial distribution; and the differentiated playback rhythms between the main Boids give the cluster a rich visual presentation, achieving smooth performance of a large-scale Boid cluster and effective state management consistent across multiple terminals with extremely low server load and client computing power.

[0011] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0012] 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 A flowchart illustrating a Boids cluster representation method provided in an embodiment of this application is shown. Figure 2 A flowchart illustrating another Boids cluster representation method provided in an embodiment of this application is shown. Figure 3 This illustration shows a schematic diagram of a Boids cluster representation device provided in an embodiment of this application; Figure 4 A schematic diagram of the device structure of a computer device provided in an embodiment of this application is shown. Detailed Implementation

[0013] The present application will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of the present application can be combined with each other.

[0014] This embodiment provides a method for representing Boids clusters, such as... Figure 1 As shown, the method includes: Step 101: Obtain the set of valid Boid indices created by the server, and create the bone mesh corresponding to each Boid in the set of valid Boid indices.

[0015] The valid Boid index set refers to a list of integer values ​​maintained by the server. Each value in this list uniquely identifies a Boid individual that is currently in a valid state. The server uses this list to record which Boids can still participate in hit detection and behavior, but does not store kinematic data such as Boid position, velocity, and rotation. The skeletal mesh refers to a 3D model asset containing a skeletal hierarchy and a skinned mesh. Its skeletal hierarchy consists of a root bone and several levels of sub-bones. Each bone can rotate and translate around its local coordinate axis. Each vertex in the skinned mesh is bound to one or more bones through a weight value. When a bone changes, the vertex moves with the bone and undergoes corresponding deformation.

[0016] Specifically, the client obtains a list of valid Boid indexes maintained by the server, and for each Boid index in the list, creates a corresponding skeletal mesh in the local scene. Through index acquisition and skeletal mesh creation, the client can build a visual representation that corresponds one-to-one with the valid Boids locally based on the server's authoritative data, while keeping the server's storage and computing burden at a very low level, only maintaining the index list, thus avoiding the resource consumption caused by the server creating a complete object for each Boid.

[0017] Step 102: Select a Boid with a preset number of animation instances as the main Boid from the set of valid Boid indices, and use the remaining Boids as child Boids. Determine the target Boid that each child Boid follows in each main Boid. The preset number of animation instances is less than the number of Boids in the set of valid Boid indices.

[0018] In this context, the primary Boid refers to the individual Boid selected from the valid Boid index set that possesses an independent animation instance, responsible for calculating and generating skeletal pose data. The secondary Boid refers to the remaining Boid individuals in the valid Boid index set besides the primary Boid; these do not possess independent animation instances but reuse the skeletal pose data of the primary Boid to complete their own animation. The preset number of animation instances is an integer value configured by the system, which is less than the total number of Boids in the valid Boid index set. This value determines the number of primary Boids, thereby controlling the upper limit of the number of animation instances actually running on the client.

[0019] For example, selecting a Boid with a preset number of animation instances as the main Boid from the set of valid Boid indices, and using the remaining Boids as child Boids, and determining the target Boid that each child Boid follows from the main Boid, includes: selecting a Boid with an index less than the preset number of animation instances as the main Boid from the set of valid Boid indices, selecting a Boid with an index greater than or equal to the preset number of animation instances as the child Boid, and determining the main Boid corresponding to each child Boid as the target Boid that each child Boid follows based on the result of taking the modulo of the index of each child Boid with the preset number of animation instances.

[0020] Specifically, the client iterates through the set of valid Boid indices based on the preset number of animation instances, judging them in ascending order of index: if the index value of the current Boid is less than the preset number of animation instances, the Boid is marked as the main Boid; if the index value of the current Boid is greater than or equal to the preset number of animation instances, the Boid is marked as a child Boid. After completing the division of main and child Boids, the client further determines the target main Boid that each child Boid follows, specifically using a modulo mapping method: the index value of the child Boid is modulo the preset number of animation instances, and the remainder is used as the index of the main Boid that the child Boid follows. Through the master-slave division and mapping, a large number of Boid individuals only need a small number of main Boids to handle the animation calculation tasks, and the remaining child Boids find their corresponding pose sources through mapping relationships. From the architectural level, the animation calculation workload is compressed from the total number of Boids to the preset number of animation instances, achieving decoupling between the number of individual representations and animation calculation resources.

[0021] Step 103: Create realistic animation instances with different animation playback rhythms for each main Boid. Generate skeletal pose data for each frame from the realistic animation instances of the main Boid. The sub-Boid reuses the skeletal pose data of the main Boid it follows.

[0022] In this context, a "real animation instance" refers to an animation calculation unit created by the client for the skeletal mesh. This unit can include components such as animation blueprints, state machines, and animation sequence players, responsible for executing animation logic calculations and outputting skeletal pose data for each frame. Skeletal pose data refers to the transformation data set of each bone in its local coordinate system, specifically including the rotation, displacement, and scaling values ​​of each bone relative to its parent bone. This data set is output by the animation instance and written to the bone buffer of the skeletal mesh component after each frame's animation calculation is completed. The animation playback rhythm refers to the playback speed multiplier of the animation sequence. Adjusting this multiplier allows the same animation sequence to play at different speeds, creating a visually varied effect.

[0023] Specifically, the client creates realistic animation instances only for skeletal meshes marked as primary Boids. Furthermore, a randomized PlayRate is set for the realistic animation instances of each primary Boid to ensure different animation playback rhythms for different primary Boids, preventing all primary Boids from exhibiting completely synchronized mechanical movement. For skeletal meshes marked as child Boids, the client does not create realistic animation instances for them. The child Boid's skeletal pose is obtained as follows: during the animation update phase of each rendered frame, the child Boid finds its following primary Boid based on the mapping relationship determined in step 102, and then calls the skeletal pose copy interface to completely copy the calculated skeletal pose data of the primary Boid for the current frame into its own skeletal buffer. This copying process only involves copying memory data and does not trigger any animation logic operations. The randomization of the playback rhythm of each primary Boid enables the cluster to exhibit rich motion diversity, avoiding the visual unnaturalness caused by a large number of individual movements being completely synchronized.

[0024] Step 104: Update the motion data of each Boid in the local Tick without synchronizing the motion data to the server, wherein the motion data includes position, speed and rotation data.

[0025] In this context, the local tick refers to the update loop executed by the client every frame. This loop is triggered periodically with a fixed or variable step size, responsible for driving the state refresh of all components in the scene that require updates every frame. Motion data refers to the position coordinates, velocity vector (including magnitude and direction), and orientation / rotation value of each Boid in three-dimensional space. These three factors together determine the position and motion state of each Boid in space. For example, updating the motion data of each Boid in the local tick includes: the position of each Boid is calculated by a clustering algorithm, which includes separation rules, alignment rules, and aggregation rules; the position of each child Boid is independent of the position of its corresponding parent Boid, and the motion data of each child Boid is independent of the motion data of its corresponding parent Boid. The clustering algorithm refers to the calculation rules based on simulating the clustering behavior in nature, which may specifically include separation rules (to prevent individuals from spatially overlapping with neighboring individuals), alignment rules (to make the motion direction of an individual tend to the average direction of neighboring individuals), and aggregation rules (to make individuals move closer to the center position of neighboring individuals).

[0026] Specifically, the client iterates through all Boids (including the main Boid and child Boids) within each local tick cycle, independently calculating new motion data for each Boid. For example, the calculation process is based on a clustering algorithm: for each Boid, the client first detects neighboring Boids within a predetermined range around it, and collects the position and velocity information of these neighboring Boids; then, it calculates the separation force (applying a repulsive component in a distancing direction when neighboring Boids are too close), the alignment force (pushing the current Boid's velocity direction towards the average velocity direction of neighboring Boids), and the cohesion force (pulling the current Boid's position towards the average position of neighboring Boids); finally, it superimposes these three components according to configured weights to obtain the current Boid's acceleration, thereby updating its velocity and position. The position of each child Boid is independent of the position of the main Boid it follows. Although the child Boid reuses the main Boid's skeletal pose data to determine its own skeletal deformation, its spatial position and motion direction are independently calculated by the aforementioned clustering algorithm. Therefore, child Boids can be scattered in different positions around the main Boid, forming a spatially distributed cluster pattern, rather than all overlapping the main Boid. For each Boid, the client only stores the motion data calculated in local memory for rendering the current frame and iterative calculation of the next frame, without sending any motion data synchronization messages to the server.

[0027] By using a local tick motion update and non-reporting mechanism, all Boid motion calculations are completely offloaded to the client's local machine. The server does not need to process any network data related to Boid position, speed, or rotation, thus eliminating the network bandwidth consumption and serialization overhead caused by the server synchronizing massive amounts of motion data in large-scale cluster scenarios.

[0028] Step 105: Based on the skeletal pose data and motion data of each Boid, drive the corresponding skeletal mesh of each Boid to play the animation.

[0029] Among them, "driving" refers to the process of superimposing bone posture data and motion data onto the bone mesh component. This process enables the bone mesh to present a complete visual effect in three-dimensional space, which has both correct bone deformation and is in the correct spatial position.

[0030] Specifically, in each rendering frame, the client jointly applies the bone pose data obtained in step 103 with the motion data obtained in step 104. The process is as follows: First, the client sets the position coordinates and orientation rotation values ​​of each Boid into the root transform of the bone mesh component. This root transform determines the placement and overall orientation of the entire bone mesh in 3D space. Second, the client writes the bone pose data (the local rotation, displacement, and scaling values ​​of each bone relative to its parent bone) into the bone buffer of the bone mesh, overwriting the transformation values ​​of the corresponding bones in the buffer. After these two steps, when the bone mesh component performs rendering, the rendering pipeline reads the root transform to determine the overall spatial position of the model, reads the bone buffer to determine the local pose of each bone, and then performs skinning calculations, transforming each vertex of the skinned mesh according to its bound bones and their weights, ultimately generating a rendered image with the correct pose and spatial position. For the main Boid, its bone pose data comes from the calculation output of the real animation instance in step 103, and its motion data comes from the calculation results of the cluster algorithm in step 104. For a child Boid, its skeletal pose data comes from a copy of the skeletal pose data of the parent Boid it follows in step 103, while its motion data comes from the results of independent calculations by the cluster algorithm in step 104. The motion data of the child Boid is independent of the motion data of the parent Boid it follows. Therefore, the child Boid may be located at different coordinates from the parent Boid in spatial position, but it will exhibit the same pose as the parent Boid in terms of skeletal deformation.

[0031] By jointly driving the skeletal pose and motion data, each Boid in the final image simultaneously possesses the correct skeletal deformation and the correct spatial position. The main Boid presents a dynamic pose driven by the animation instance, while the child Boids present dynamic poses that are consistent with the main Boid but spatially independent, achieved by pose copying. This enables smooth animation performance of large-scale clusters with extremely low animation computation cost.

[0032] By applying the technical solution of this embodiment, the client obtains a set of valid Boid indexes maintained by the server and creates a skeletal mesh for all Boids accordingly. A preset number of Boids (less than the total number of Boids) are selected from the set as the main Boids, and real animation instances are created for them to generate skeletal pose data. The remaining child Boids reuse the skeletal pose data of the main Boids they follow. All Boids independently update their position, velocity, rotation, and other motion data in their local ticks without synchronizing with the server. Finally, the skeletal pose data and motion data are combined to drive the skeletal meshes of each Boid to complete the animation playback. Through this embodiment, the number of client-side animation instances is no longer equivalent to the number of Boids, decoupling the animation computation load from the cluster size and reducing client-side animation overhead. Motion data is maintained entirely locally without reporting to the server, reducing the amount of network synchronization data. The independent local calculation of the position of each Boid gives the cluster a reasonable spatial distribution, and the differentiated playback rhythms between the main Boids give the cluster a rich visual presentation. This achieves smooth performance of a large-scale Boid cluster and effective state management consistent across multiple terminals with extremely low server load and client computing power.

[0033] Furthermore, as a refinement and extension of the specific implementation of the above embodiments, and to fully illustrate the specific implementation process of this embodiment, another method for representing Boids clusters is provided, such as... Figure 2 As shown, after driving the skeletal mesh corresponding to each Boid to play the animation, the method includes: Step 201: When a hit event occurs, perform hit prediction locally. Based on the predicted hit Boid, filter candidate Boid indices from the set of valid Boid indices. Mark the valid state of the candidate Boid indices in the set of valid Boid indices as invalid, disable collision for the corresponding candidate Boid, play the hit animation of the candidate Boid, or hide the candidate Boid.

[0034] In this context, "hit event" refers to an attack detection trigger signal detected locally by the client. This signal can be generated by ray detection, range detection, or projectile collision initiated by the attacker, and includes information such as hit location, hit direction, and attack force. "Hit prediction" refers to the process by which the client, without waiting for server confirmation, immediately determines which Boids have been hit based on its existing set of valid Boid indices and collision detection results. "Candidate Boid index" refers to the index value of one or more Boids identified as hits in the hit prediction within the set of valid Boid indices. "Valid state" refers to whether a Boid is marked as eligible for subsequent hit detection within the set of valid Boid indices; this flag is a Boolean value, taking the values ​​of "valid" or "invalid." "Hit animation" refers to a specific animation sequence played when a Boid is hit, used to represent the Boid's immediate reaction to the attack, such as body trembling, flipping, or collapsing. "Hidden" refers to setting the visibility attribute of the Boid's skeletal mesh to invisible, causing the Boid to disappear from the rendered screen.

[0035] Specifically, when the attack detection system in the client-side scene issues a hit event, the client first determines the hit location and direction in 3D space. Then, the client performs spatial intersection detection between this hit location and the colliders of all active Boids in the scene. These colliders are collision capsules generated synchronously when creating the skeletal mesh for each Boid, and their positions are updated in sync with the Boid's current position. Based on the intersection detection results, the client determines which Boids' colliders are penetrated or contained by the hit location, and adds the indices of all Boids that are determined to be hit to a candidate Boid index set.

[0036] After selecting candidate Boid indices, the client switches the valid status flag of the Boid corresponding to the candidate Boid index in the set of valid Boid indices from valid to invalid, so that the Boid no longer participates in any hit detection in subsequent frames; the client disables the collider of the Boid so that it no longer blocks bullets or participates in subsequent intersection detection, thus preventing the same Boid from being hit repeatedly; at the same time, the client triggers the Boid to play the hit animation, so that the Boid's skeleton mesh shows the dynamic feedback after being attacked; or, the client directly sets the visibility of the Boid's skeleton mesh component to a hidden state, so that the Boid disappears visually immediately, which is suitable for showing the effect of instant kill.

[0037] In one optional embodiment, a hit prediction is performed locally, and candidate Boid indices are filtered from the set of valid Boid indices based on the predicted hit Boid. This includes: determining whether the number of Boids in the set of valid Boid indices is greater than a preset minimum remaining number; if it is greater, a hit prediction is performed locally, and candidate Boid indices are filtered from the set of valid Boid indices based on the predicted hit Boid, with the preset minimum remaining number as a constraint, to ensure that the number of remaining Boids in the set of valid Boid indices is not less than the preset minimum remaining number; if it is less than or equal to, the local hit prediction is stopped.

[0038] In this embodiment, before performing local hit prediction, the client first checks whether the current remaining number of Boid indices in the effective Boid index set is greater than the system's preset minimum remaining number threshold. If the current remaining number is greater than the threshold, the client performs hit prediction and truncates the candidate Boid indices with the minimum remaining number as the lower limit. That is, it selects a portion of the indices from the predicted hit Boids as candidates, ensuring that the remaining number in the effective set after this removal is not lower than the preset threshold, thereby preventing the cluster from being eliminated all at once or cumulatively to below the lower limit. If the current remaining number is equal to or less than the threshold, the client directly stops performing local hit prediction and does not perform any further removal operations on the cluster. Through this embodiment, the cluster retains at least the minimum remaining number of Boids in a valid state under any circumstances, fundamentally preventing the complete elimination of the cluster due to continuous attacks, and ensuring that the AI ​​entity always has a basic visual presence and functional availability.

[0039] Step 202: Send the AI ​​entity identifier corresponding to the set of valid Boid indices, the candidate Boid index, the hit position, and the hit point rotation to the server, so that the server generates hit synchronization information and sends it to all clients.

[0040] For example, the server generates hit synchronization information and sends it to all clients, including: the server filters the received candidate Boid indices one by one, removes the indices that are invalid or duplicated in the set of valid Boid indices, and rotates the filtered valid indices, the corresponding hit positions and the hit points to generate hit synchronization information and sends it to all clients; wherein, after receiving the hit synchronization information, each client performs invalidation processing on the corresponding indexes that are still valid locally.

[0041] Here, AI entity identifier refers to a globally unique identifier assigned by the server to each independent AI entity. This identifier is used to distinguish multiple AI entities existing simultaneously in a scene. Each AI entity maintains an independent set of valid Boid indices on the server. Hit location refers to the coordinates of the hit event in three-dimensional space. These coordinates are calculated by ray detection or range detection from the attack determination system and are precise position values ​​in the world coordinate system. Hit point rotation refers to the orientation information at the hit location. This rotation value represents the normal direction of the hit surface or the incident direction of the attack, enabling the receiving end to generate hit effects with consistent orientation at the hit location. Hit synchronization information refers to the network data packet generated by the server based on the hit data reported by the client, used for multicasting to all clients. This data packet contains the AI ​​entity identifier, valid candidate Boid indices confirmed by the server after filtering, and their corresponding hit locations and hit point rotations.

[0042] Specifically, after local hit prediction and invalidation processing, the client assembles the relevant information of this hit into a reporting data packet. This reporting data packet contains four fields: the first field is the AI ​​entity identifier, which the client retrieves from locally stored AI entity association information to ensure the server can locate the correct set of valid Boid indices; the second field is the candidate Boid index list, i.e., one or more Boid indices selected in step 201 that have been marked as invalid locally; the third field is the hit location, i.e., the world coordinates of the hit event in 3D space; and the fourth field is the hit point rotation, i.e., the orientation or incident direction of the hit event at the hit location. The client sends this reporting data packet to the server via a network protocol. After receiving the client's reporting data packet, the server first parses out the AI ​​entity identifier and locates the corresponding set of valid Boid indices based on the identifier. Subsequently, the server performs item-by-item filtering on the candidate Boid index list in the reported data packet: the server checks each candidate Boid index to see if it still exists in its maintained set of valid Boid indexes. If an index is no longer in the set (e.g., because it has been removed from all client hit reports), it is removed from the candidate list; if an index is still in the set, it is retained and removed from the set of valid Boid indexes. After filtering and removal, the server packages the filtered list of still valid candidate Boid indexes, along with the hit position and hit point rotation from the reported data packet, into a hit synchronization message. This hit synchronization message is sent to all clients in the current game session via multicast.

[0043] After receiving the hit synchronization information multicast by the server, each client parses out the AI ​​entity identifier, candidate Boid index, hit position, and hit point rotation. Each receiving client locates its local set of valid Boid indices based on the AI ​​entity identifier and checks whether the candidate Boid index is still valid locally. If the index is still valid locally, it is marked as invalid, and a hit effect is played at the local hit position. The spray direction of this effect is controlled by the hit point rotation, ensuring that all clients exhibit the same effect direction. If the index is already invalid locally (e.g., the client has already completed local hit prediction before synchronizing with the server), the processing of that index is skipped, and the invalidation marking and effect playback are not repeated. After receiving the hit synchronization information from the server multicast, the client that initiated this hit report also parses out the candidate Boid indexes. Since these indexes have been marked as invalid by the client locally in step 201, the client finds that the indexes no longer exist in the valid set when checking the local valid status. Therefore, it skips all processing steps to avoid performing the invalidation operation and playing the special effects twice for the same hit event.

[0044] Through reporting, filtering, and multicast mechanisms, the server, acting as the authoritative arbitrator, uniformly filters and confirms hit requests from all clients, ensuring the consistency of the valid Boid state across all clients. The multicast mechanism allows all clients to synchronously obtain hit results, while the skip-repeating execution mechanism of the initiating client avoids conflicts between local prediction results and server-synchronized results, achieving seamless collaboration between client prediction and server arbitration. Simultaneously, multicast of hit position and hit point rotation enables all clients to generate consistent directional effects at the same location, further enhancing the uniformity of the multi-device visual experience.

[0045] In an optional embodiment, when a hit event occurs, before performing hit prediction locally, the method further includes: if the current period is a time stop phase, caching the hit event, and then uniformly processing the cached hit event after the time stop ends.

[0046] The time-stop phase refers to the period during which the game timeline is paused or slowed down to near standstill. During this period, the update frequency of the game logic is suspended or significantly reduced, and the movement and animation updates of dynamic objects in the scene (including Boid clusters) are temporarily frozen. However, user input and system events can still be received and recorded. Hit event caching refers to the process where, when hit events cannot be processed immediately during the time-stop phase, the client stores relevant data (including hit location, hit direction, attack source identifier, timestamp, etc.) as event objects in a cache queue. This cache queue exists in memory independently of the regular game update cycle and is unaffected by the time-stop state. Unified processing refers to the process where, after the time-stop phase ends and the game timeline returns to normal, the client retrieves all cached hit events sequentially from the cache queue and performs complete hit prediction, candidate index filtering, and local invalidation processing on each event. This ensures that the hit events accumulated during the time-stop phase are responded to one by one after recovery, without losing any hit information.

[0047] Specifically, when the attack detection system in the client-side scene issues a hit event, the client first checks whether the current game is in a time-stop phase before performing hit prediction. For example, this detection is achieved by reading the game's global time scaling value: if the time scaling value is zero or close to zero (e.g., less than a preset minimum threshold), it is determined that the game is currently in a time-stop phase; if the time scaling value is a normal value (usually one), it is determined that the game is currently in a normal operating state. If the detection result indicates that the game is currently in a time-stop phase, the client does not immediately perform hit prediction and local invalidation processing, but instead creates a hit event object. This event object contains complete data for this hit event: hit location (3D world coordinates), hit direction (or incident rotation value), entity identifier of the attack source, timestamp of the event occurrence (used for sorting in subsequent processing), and attack type identifier (used to determine the hit behavior). The client appends this event object to the tail of the hit event cache queue, while keeping the current state of all bots in the scene unchanged, without performing any valid state modifications, collision disabling, or visibility changes. If the detection result indicates that the current state is not in the time-stop phase (i.e., normal operation state), the client skips the caching operation and directly executes the hit prediction, candidate index filtering, and local invalidation process to ensure an immediate response to the hit event.

[0048] When the pause phase ends, the client triggers a unified processing flow for cached events. This flow retrieves cached event objects one by one in a first-in-first-out queue, and performs hit prediction, candidate index filtering, and local invalidation processing on each event object in sequence. During the unified processing, if the target corresponding to a cached hit event has been marked as invalid in the processing of a previous event, the current event is skipped in the hit prediction phase because the target no longer exists, thus avoiding the repeated invalidation operation on an already invalidated Boid.

[0049] In an optional embodiment, after filtering candidate Boids, the method further includes: if the candidate Boids include the main Boid, then the candidate Boids belonging to the main Boid are taken as the old main Boids, a new main Boid is selected from the child Boids corresponding to the old main Boids, and the new main Boids and the old main Boids are swapped in state so that the child Boids corresponding to the new Boids continue to reuse the skeletal pose data of the new Boids; wherein the swapped data includes the motion data.

[0050] In this embodiment, when the selected candidate Boid index includes the main Boid, the client does not directly mark the main Boid as invalid and remove it. Instead, it records the hit main Boid as the old main Boid, and then selects a still valid sub-Boid from its set of sub-Boids as the new main Boid. Subsequently, all the running data of the new main Boid and the old main Boid are exchanged. The exchanged content includes motion data such as position, velocity, and rotation, as well as running attributes such as valid status flags, collision enabled status, hidden timers, and temporary effects. After the exchange is completed, the old main Boid (currently holding the data of the atomic Boid) is marked as invalid and removed from the valid set, while the new main Boid (currently holding the data of the original main Boid) continues to remain valid. All sub-Boids that originally belonged to the old main Boid continue to reuse the skeletal pose data of the new main Boid, and the entire reuse chain remains intact and uninterrupted. This mechanism allows the main Boid to survive even when hit, through a "substitute swap," ensuring that animation sample slots are always occupied by a valid Boid. This avoids the problem of all its child Boids losing their skeletal pose data source when the main Boid is removed. Simultaneously, the exchange of position data during the swap ensures the new main Boid appears at the location where the old main Boid was hit. From the player's perspective, it still appears as if "the fish at the aiming position has been hit," with visual feedback perfectly aligned with the expected actions. What is actually removed is the atomic Boid that has swapped positions from elsewhere, thus preserving the sample data at a level imperceptible to the player. Furthermore, this swapping mechanism is entirely completed locally on the client side, without server communication, resulting in zero response latency. The exchange of all runtime data ensures that the new main Boid inherits the complete motion state of the old main Boid, with smooth, seamless pose switching, effectively guaranteeing the continuity and stability of the overall cluster motion.

[0051] Furthermore, as Figure 1 To specifically implement the method, this application provides a Boids cluster representation device, such as... Figure 3 As shown, the device includes: The skeleton mesh creation module is used to obtain the set of valid Boid indices created by the server and create a skeleton mesh corresponding to each Boid in the set of valid Boid indices. The master-slave Boid determination module is used to select a preset number of Boids as master Boids from the set of valid Boid indexes, and the remaining Boids as child Boids, and to determine the target Boid that each child Boid follows in each master Boid; wherein, the preset number of animation instances is less than the number of Boids in the set of valid Boid indexes. The skeletal pose determination module is used to create realistic animation instances with different animation playback rhythms for each main Boid. Skeletal pose data is generated for each frame of the realistic animation instance of the main Boid, and the sub-Boid reuses the skeletal pose data of the following main Boid. The motion data update module is used to update the motion data of each Boid in the local Tick without synchronizing the motion data to the server. The motion data includes position, speed and rotation data. The animation playback module is used to drive the corresponding skeletal mesh of each Boid to play animations based on the skeletal pose data and motion data of each Boid.

[0052] In an optional embodiment, the master-slave Boid determination module is specifically used for: In the set of valid Boid indices, select Boids with indices less than the preset number of animation instances as main Boids, and select Boids with indices greater than or equal to the preset number of animation instances as child Boids. Based on the result of taking the modulo of the index of each child Boid with the preset number of animation instances, determine the main Boid corresponding to each child Boid as the target Boid that each child Boid follows.

[0053] In an optional embodiment, the apparatus further includes: The hit handling module is used to perform hit prediction locally when a hit event occurs, filter candidate Boid indices from the set of valid Boid indices based on the predicted hit Boid, mark the valid status of the candidate Boid indices as invalid in the set of valid Boid indices, disable the collision of the corresponding candidate Boid, play the hit animation of the candidate Boid, or hide the candidate Boid. The AI ​​entity identifier corresponding to the set of valid Boid indices, the candidate Boid index, the hit position, and the hit point rotation are sent to the server so that the server generates hit synchronization information and sends it to each client.

[0054] In an optional embodiment, the server generates hit synchronization information and sends it to each client, including: the server filters the received candidate Boid indices one by one, removes invalid or duplicate indices that are already in the set of valid Boid indices, and rotates the filtered valid indices, their corresponding hit positions, and the hit points to generate hit synchronization information and sends it to each client; wherein, after receiving the hit synchronization information, each client performs invalidation processing on the corresponding indexes that are still valid locally.

[0055] In an optional embodiment, the impact processing module is further configured to: When a hit event occurs, if the current time stop phase is in progress before performing hit prediction locally, the hit event is cached, and the cached hit event is processed uniformly after the time stop ends.

[0056] In an optional embodiment, the impact processing module is further configured to: Determine whether the number of Boids in the valid Boid index set is greater than the preset minimum remaining number; If the number is greater than the target number, a hit prediction is performed locally. Based on the predicted hit Boid, candidate Boid indices are filtered from the set of valid Boid indices with a preset minimum remaining number as a limit, so as to ensure that the number of remaining Boids in the set of valid Boid indices is not less than the preset minimum remaining number. If the result is less than or equal to the expected result, local hit prediction will be stopped.

[0057] In an optional embodiment, the impact processing module is further configured to: If the candidate Boid includes the main Boid, then the candidate Boid belonging to the main Boid is taken as the old main Boid, a new main Boid is selected from the child Boids corresponding to the old main Boid, and the new main Boid and the old main Boid are swapped in state so that the child Boids corresponding to the new Boid can continue to reuse the skeletal pose data of the new Boid; wherein, the swapped data includes the motion data.

[0058] It should be noted that other corresponding descriptions of the functional units involved in the Boids cluster representation device provided in this application embodiment can be found in the following references. Figures 1 to 2 The corresponding descriptions in the method will not be repeated here.

[0059] This application also provides a computer device, which may specifically be a personal computer, a server, a network device, etc. Figure 4As shown, the computer device includes a bus, a processor, memory, and a communication interface, and may also include an input / output interface and a display device. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores location information. The network interface allows communication with external terminals via a network connection. When the computer program is executed by the processor, it implements the steps in the various method embodiments.

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

[0061] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, having stored thereon a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0062] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0063] It should be noted that the user personal information involved in the embodiments of this application is all authorized (with the knowledge and consent) by the relevant parties or fully authorized by all parties, and the executing entity can obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with the relevant laws and regulations of the relevant countries and regions, and do not violate public order and good morals. It should be noted that if any software tools or components other than those of this company appear in the embodiments of this application, they are merely illustrative examples and do not represent actual use.

[0064] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, graphics processors, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

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

[0066] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. 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 application should be determined by the appended claims.

Claims

1. A method for representing Boids clusters, characterized in that, Applied to a client, the method includes: Obtain the set of valid Boid indices created by the server, and create the bone mesh corresponding to each Boid in the set of valid Boid indices; In the set of valid Boid indices, select a Boid with a preset number of animation instances as the main Boid, and use the remaining Boids as child Boids. In each main Boid, determine the target Boid that each child Boid follows; wherein, the preset number of animation instances is less than the number of Boids in the set of valid Boid indices. Create realistic animation instances with different animation playback rhythms for each main Boid, generate skeletal pose data for each frame from the realistic animation instances of the main Boid, and reuse the skeletal pose data of the following main Boid for the sub-Boid. The motion data of each Boid is updated in the local Tick without synchronizing the motion data to the server. The motion data includes position, speed and rotation data. Based on the skeletal pose and motion data of each Boid, the corresponding skeletal mesh of each Boid is driven to play animation.

2. The method according to claim 1, characterized in that, In the set of valid Boid indices, a preset number of Boids with animated instances are selected as the main Boid, and the remaining Boids are selected as child Boids. Within the main Boid, the target Boid that each child Boid follows is determined, including: In the set of valid Boid indices, select Boids with indices less than the preset number of animation instances as main Boids, and select Boids with indices greater than or equal to the preset number of animation instances as child Boids. Based on the result of taking the modulo of the index of each child Boid with the preset number of animation instances, determine the main Boid corresponding to each child Boid as the target Boid that each child Boid follows.

3. The method according to claim 1, characterized in that, After driving the skeletal mesh corresponding to each Boid to play the animation, the method further includes: When a hit event occurs, a hit prediction is performed locally. Based on the predicted hit Boid, candidate Boid indices are filtered from the set of valid Boid indices. The valid status of the candidate Boid indices in the set of valid Boid indices is marked as invalid, the collision of the corresponding candidate Boid is turned off, the hit animation of the candidate Boid is played, or the candidate Boid is hidden. The AI ​​entity identifier corresponding to the set of valid Boid indices, the candidate Boid index, the hit position, and the hit point rotation are sent to the server so that the server generates hit synchronization information and sends it to each client.

4. The method according to claim 3, characterized in that, The server generates hit synchronization information and sends it to each client, including: The server filters the received candidate Boid indices one by one, removing invalid or duplicate indices that are already in the set of valid Boid indices. The server then sends the filtered valid indices, their corresponding hit positions, and the hit points to generate hit synchronization information and sends it to each client. After receiving the hit synchronization information, each client performs invalidation processing on the corresponding indices that are still valid locally.

5. The method according to claim 3, characterized in that, When a hit event occurs, before performing hit prediction locally, the method further includes: If the current time stop phase is in progress, the hit events are cached, and the cached hit events are processed uniformly after the time stop ends.

6. The method according to claim 3, characterized in that, Perform hit prediction locally, and based on the predicted hit Boid, filter candidate Boid indices from the set of valid Boid indices, including: Determine whether the number of Boids in the valid Boid index set is greater than the preset minimum remaining number; If the number is greater than the target number, a hit prediction is performed locally. Based on the predicted hit Boid, candidate Boid indices are filtered from the set of valid Boid indices with a preset minimum remaining number as a limit, so as to ensure that the number of remaining Boids in the set of valid Boid indices is not less than the preset minimum remaining number. If the result is less than or equal to the expected result, local hit prediction will be stopped.

7. The method according to claim 6, characterized in that, After filtering candidate Boids, the method further includes: If the candidate Boid includes the main Boid, then the candidate Boid belonging to the main Boid is taken as the old main Boid, a new main Boid is selected from the child Boids corresponding to the old main Boid, and the new main Boid and the old main Boid are swapped in state so that the child Boids corresponding to the new Boid can continue to reuse the skeletal pose data of the new Boid; wherein, the swapped data includes the motion data.

8. A Boids cluster representation device, characterized in that, The device includes: The skeleton mesh creation module is used to obtain the set of valid Boid indices created by the server and create a skeleton mesh corresponding to each Boid in the set of valid Boid indices. The master-slave Boid determination module is used to select a preset number of Boids as master Boids from the set of valid Boid indexes, and the remaining Boids as child Boids, and to determine the target Boid that each child Boid follows in each master Boid; wherein, the preset number of animation instances is less than the number of Boids in the set of valid Boid indexes. The skeletal pose determination module is used to create realistic animation instances with different animation playback rhythms for each main Boid. Skeletal pose data is generated for each frame of the realistic animation instance of the main Boid, and the sub-Boid reuses the skeletal pose data of the following main Boid. The motion data update module is used to update the motion data of each Boid in the local Tick without synchronizing the motion data to the server. The motion data includes position, speed and rotation data. The animation playback module is used to drive the corresponding skeletal mesh of each Boid to play animations based on the skeletal pose data and motion data of each Boid.

9. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

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

Images