Bullet behavior scheduling method and device, equipment and medium

Abstract

The application relates to a bullet behavior scheduling method and device, equipment and a medium. Behavior configuration information of a bullet is acquired; a bullet entity instance is acquired from a multiplexing resource pool according to the behavior configuration information, a bullet entity is constructed, a behavior scheduling queue is established for the bullet entity, each behavior module is added to the behavior scheduling queue in a preset order; each behavior module in the behavior scheduling queue is executed, and a behavior module that needs to be continuously executed every frame is determined, so that after the behavior module is executed once, the behavior module is moved into a continuous behavior list for frame traversal; an asynchronous parallel collision detection system is called to execute collision detection; a behavior module that hits a collision is executed according to a collision result, and subsequent behavior modules are continuously executed until the behavior modules are destroyed, and the bullet entity instance is recycled to the multiplexing resource pool when the behavior modules are destroyed. The application solves the problems of bullet behavior logic coupling and collision detection performance bottleneck, realizes modular scheduling and asynchronous parallel collision detection, and thus improves development efficiency, running performance and scalability.

Description

Technical Field

[0001] This application relates to the field of game interaction technology, and in particular to a bullet behavior scheduling method, apparatus, device, and medium thereof. Background Technology

[0002] In game development, the runtime behavior of bullets in a bullet hell system (including trajectory, collision detection, and hit response) directly impacts the smoothness and playability of combat. Currently, most mainstream solutions employ traditional hard-coding, directly embedding bullet initialization, movement, collision, hit, and destruction logic into the program code. Under this approach, each new bullet behavior (such as tracking, ricocheting, or splitting) requires programmers to write a large amount of repetitive code, resulting in bullet logic scattered across various modules, leading to high code coupling and poor maintainability. Furthermore, game designers cannot independently adjust bullet behavior parameters or combine new behaviors; each modification relies on programmer intervention for code refactoring, compilation, and testing, resulting in lengthy iteration cycles and high trial-and-error costs.

[0003] Furthermore, existing solutions rely on the game engine's general physics system for collision detection, creating independent physics components for each bullet. This results in high memory consumption, high CPU load, and a significant drop in frame rate when a large number of bullets are on screen simultaneously. Collision callbacks from the physics engine are generated in asynchronous threads, making their timing uncontrollable. Hit detection is often delayed or out of order, making precise frame synchronization difficult. Simultaneously, frequent creation and destruction of bullet entities and effects resources, coupled with a lack of object pooling and other reuse mechanisms, leads to memory fragmentation and garbage collection stutters, making it unsuitable for large-scale bullet hell scenarios. The logic for bullet initialization, movement, collision, and destruction is intertwined, with collision detection tightly coupled to other behaviors, making independent optimization or replacement impossible and resulting in poor scalability.

[0004] In summary, existing bullet behavior scheduling schemes suffer from problems such as coupled behavior logic, poor scalability, chaotic resource management, collision detection performance bottlenecks, and uncontrollable timing, making it difficult to meet the requirements of smoothness, accuracy, and scalability in large-scale bullet hell scenarios. Summary of the Invention

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

[0006] According to one aspect of this application, a bullet behavior scheduling method is provided, comprising:

[0007] Obtain bullet behavior configuration information, wherein the behavior configuration information includes at least one behavior module, and each behavior module corresponds to an independent behavior stage in the bullet's life cycle;

[0008] Based on the behavior configuration information, a bullet entity instance is obtained from the reuse resource pool, a bullet entity is constructed, and a behavior scheduling queue is established for the bullet entity. Each behavior module is added to the behavior scheduling queue in a preset order.

[0009] Each behavior module in the behavior scheduling queue is executed, and the behavior module that needs to be continuously executed every frame is determined. After it is executed once, it is moved into the continuous behavior list for frame traversal, thereby driving the state update of the bullet entity.

[0010] When the collision detection behavior module is executed, the asynchronous parallel collision detection system is called to perform collision detection, and a collision snapshot is collected from the game thread. In the asynchronous thread pool, wide-stage filtering and narrow-stage precise detection are performed in sequence, and the collision results are written back to the game thread.

[0011] The collision-hitting behavior module is executed based on the collision result, and subsequent behavior modules are executed until the object is destroyed. Upon destruction, the bullet entity instance is recycled back to the reuse resource pool.

[0012] According to another aspect of this application, a bullet behavior control device is provided, comprising:

[0013] A bullet configuration acquisition module is used to acquire bullet behavior configuration information, wherein the behavior configuration information includes at least one behavior module, and each behavior module corresponds to an independent behavior stage in the bullet's life cycle.

[0014] The bullet entity construction module is used to obtain bullet entity instances from the reused resource pool according to the behavior configuration information, construct bullet entities, establish a behavior scheduling queue for the bullet entity, and add each behavior module to the behavior scheduling queue in a preset order.

[0015] The bullet behavior scheduling module is used to execute each behavior module in the behavior scheduling queue, determine the behavior modules that need to be continuously executed every frame, and move them into the continuous behavior list for frame traversal after they are executed once, thereby driving the state update of the bullet entity.

[0016] The asynchronous collision detection module is used to call the asynchronous parallel collision detection system to perform collision detection when the collision detection behavior module is executed. It collects collision snapshots from the game thread, performs wide-stage filtering and narrow-stage precise detection in the asynchronous thread pool in turn, and writes the collision results back to the game thread.

[0017] The bullet hit collision module is used to execute the hit collision behavior module according to the collision result, and continue to execute the subsequent behavior modules until destruction, and when destroyed, the bullet entity instance is recycled to the reuse resource pool.

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

[0019] As can be seen from the above embodiments, the beneficial effects of this application are mainly reflected in the following aspects:

[0020] First, this application achieves complete separation of bullet behavior logic from program code by acquiring bullet behavior configuration information and decomposing the bullet lifecycle into independent behavior modules. Each behavior module corresponds to an independent behavior stage, and there is no logical coupling between modules. Developers or planners only need to configure the sequence and parameters of the behavior modules, and can freely combine or add bullet behaviors without modifying the underlying code. Thus, the problems of behavior logic coupling, poor scalability, and planner reliance on programmer intervention caused by hard-coding in traditional solutions are fundamentally solved, significantly improving the development efficiency and flexibility of bullet behavior scheduling.

[0021] Secondly, this application establishes a behavior scheduling queue for bullet entities and identifies behavior modules that need to be continuously executed every frame, moving them into a persistent behavior list. During each frame cycle, frame update logic and post-frame processing logic are executed by traversing this list. This scheduling method, which distinguishes between one-time and persistent behaviors and employs a two-stage traversal, ensures that update operations such as movement and timing are completed strictly before collision detection, avoiding logical order errors. Simultaneously, bullet entities are obtained from a reuse resource pool and reclaimed into the pool upon destruction, achieving efficient reuse of bullet instances and eliminating frequent memory allocation and release. This significantly reduces garbage collection pressure and memory fragmentation, reliably guaranteeing performance in large-scale bullet hell scenarios.

[0022] Furthermore, when the collision detection behavior module is executed, this application invokes an asynchronous parallel collision detection system. Only collision snapshots are collected in the game thread, while wide-stage filtering and narrow-stage precise detection are handled in parallel by an asynchronous thread pool. Finally, the collision results are synchronously written back to the game thread. This mechanism completely departs from the synchronous blocking mode of traditional physics engines, eliminating not only the huge overhead of physics components but also solving the problem of uncontrollable asynchronous callback timing. Simultaneously, through adaptive mesh partitioning for wide stages and a dedicated analytical geometry algorithm for narrow stages, it can accurately determine the intersection of thousands of colliders within milliseconds and incorporates continuous collision detection to prevent high-speed bullet penetration. Therefore, while ensuring collision detection accuracy, this application completely solves the performance bottlenecks and uncontrollable timing defects of existing solutions, enabling bullet hell games to maintain a smooth and stable frame rate even in scenes with massive numbers of bullets. Attached Figure Description

[0023] Figure 1 This application provides an exemplary network architecture;

[0024] Figure 2 This is a flowchart illustrating one embodiment of the bullet behavior scheduling method of this application.

[0025] Figure 3 This is a schematic diagram of the bullet behavior control device of this application;

[0026] Figure 4 This is a schematic diagram of the structure of a bullet behavior scheduling device used in this application. Detailed Implementation

[0027] The technical solution of this application can be widely applied to various network architectures to adapt to different types and scales of game applications. In a network architecture such as... Figure 1 In the typical network architecture shown, the player's terminal device accesses the game service cluster via the network. This cluster consists of multiple game servers 81. A microservice architecture manages and maintains the operational resources of these game servers 81, providing multiple service instances. Each service instance is responsible for a different service; for example, some service instances can maintain the front-end service for the terminal device 80 to access the game, while others can handle the game's dungeon combat gameplay, providing players with corresponding game combat dungeons to play. The player's terminal device 80 has a computer program product implemented according to the bullet behavior scheduling method of this application installed and running, or the terminal device can be connected to a cloud server container, where the computer program product runs. After the computer program product runs, it accesses the game service cluster, allowing the player to control their in-game character through the terminal device and interact with various service instances of the game, such as engaging in combat with hostile entities.

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

[0029] This application is not only applicable to the gaming experience of single players, but can also be extended to multiplayer online game environments. In multiplayer games, multiple players' (users') terminal devices connect to the game service cluster simultaneously, and each service instance needs to handle interaction requests from multiple players and update the game status in real time.

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

[0031] The bullet behavior scheduling method provided in this application can be widely deployed in various virtual environment systems with combat interaction gameplay, especially suitable for application scenarios such as video games, virtual reality experiences, and simulation training platforms. In a typical technical architecture, the execution entity of this application is usually a terminal device running a client application, such as a personal computer, game console, or mobile device. The game engine or application framework running on the terminal device integrates combat gameplay processing middleware and logic processing units, responsible for real-time rendering of virtual scenes, handling user interactions, and managing the playback of combat performance resources. Combat performance resources and related strategy configuration data can be stored locally on the terminal device or dynamically obtained from a remote server as needed. Real-time monitoring, strategy matching, and bullet behavior scheduling processes can be completed locally on the client to ensure low-latency response and a smooth experience.

[0032] In an exemplary bullet behavior scheduling process, the game developer first defines behavior configuration information for the "tracking fireball" bullet, including a sequence of behavior modules: initialization module, tracking movement module, collision detection module, hit response module, and destruction module. Specifically, the tracking movement module is configured to track the player character at a speed of 800 cm / s; the collision detection module is configured to enable an asynchronous parallel collision detection system; the hit response module is configured to deduct 100 health points from the player and play an explosion effect; and the destruction module is configured to have a bullet lifespan of 5 seconds. At runtime, the system retrieves a bullet entity instance from the reused resource pool based on this behavior configuration information, establishes a behavior scheduling queue for it, and adds the aforementioned behavior modules to the queue in sequence. Once the bullet is fired, during each frame cycle, the system iterates through the persistent behavior list (the tracking movement module and collision detection module are moved into this list because they need to be executed every frame) during the frame update phase. It calls the update logic of the tracking movement module to calculate the fireball's new position and renders it synchronously. During the frame post-processing phase, the persistent behavior list is iterated again, and the frame post-processing logic of the collision detection module is called. At this time, the system calls the asynchronous parallel collision detection system: it takes a collision snapshot of the fireball and the player in the game thread (including shape type, collision channel, collision intention mask, current position, and previous frame position), then performs wide-stage filtering based on the collision snapshot in the asynchronous thread pool (quickly filtering candidate collision pairs through adaptive mesh partitioning), then performs narrow-stage precise detection on the candidate pairs (determining intersection based on the sphere-sphere shape combination using analytical geometry formulas), and finally writes the collision result back to the game thread and notifies the bullet entity. If a hit is detected, the system continues to execute the hit response module during the frame post-processing phase, deducting the player's health and playing an explosion effect, then marking the bullet as to be destroyed. In the next frame post-processing phase, the destruction module is triggered, and the bullet entity instance is recycled to the reuse resource pool. Throughout the process, collision detection does not block the game's main thread, and the bullet behavior module can be flexibly combined and replaced without modifying the underlying framework code.

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

[0034] After providing a general overview of the exemplary network architecture and application scenarios of this application, as well as some basic concepts, the following will continue to describe several specific embodiments of this application.

[0035] Please see Figure 2 The bullet behavior scheduling method of this application, in some embodiments, includes the following steps:

[0036] Step S11: Obtain bullet behavior configuration information, wherein the behavior configuration information includes at least one behavior module, and each behavior module corresponds to an independent behavior stage in the bullet's lifecycle.

[0037] The behavior configuration information is an abstract definition of the various behaviors and related operational parameters that a bullet should perform throughout its entire lifecycle. This information is not executable program code, but rather a descriptive configuration existing in data form, such as a set of parameters stored in a data table, data asset, or structured file. The core components of the behavior configuration information include at least one behavior module, as well as other optional operational data.

[0038] The behavioral module refers to a logical unit capable of independently completing a specific processing task of the bullet. Each behavioral module corresponds to an independent behavioral stage in the bullet's lifecycle. The bullet's lifecycle is typically divided into several logically independent behavioral stages in chronological order, including but not limited to the initialization stage, motion stage, collision detection stage, hit response stage, destruction stage, and derivative bullet generation stage. Accordingly, behavioral modules may include initialization behavioral modules, motion behavioral modules, collision detection behavioral modules, hit response behavioral modules, destruction behavioral modules, and derivative bullet generation behavioral modules.

[0039] The initialization behavior module performs a one-time setup task upon bullet creation. This module executes immediately after bullet creation, retrieving the bullet's visual effect entity from the object pool, setting the bullet's initial position and orientation, configuring its base velocity and lifespan, and creating the data structures needed for collision detection. For example, for a "tracking fireball" bullet, the initialization behavior module assigns it a visual instance of a fireball effect, sets the bullet's starting coordinates to the launcher's exit position, sets its initial velocity to 0 centimeters per second (because the tracking movement module takes over velocity control), and sets its lifespan to 5 seconds.

[0040] The motion behavior module is responsible for updating the bullet's position and orientation during flight. This module is executed during the frame update phase of each frame, calculating the bullet's new position based on the preset motion trajectory type (e.g., linear motion, target-tracking motion, center-orbiting motion) and synchronously updating the position data required for its rendering. For example, the tracking motion behavior module for tracking fireball bullets calculates the direction vector from the bullet towards the player character each frame and moves the bullet in that direction at a speed of 800 centimeters per second, while smoothly adjusting the bullet's orientation to point at the player.

[0041] The collision detection behavior module is responsible for determining whether a bullet overlaps with other objects. This module is executed during the post-frame processing of each frame, invoking the asynchronous parallel collision detection system. The collision detection behavior module itself does not perform specific geometric calculations; instead, it triggers the collision detection process: a snapshot of the bullet's collisions with surrounding objects is captured in the game thread (including shape, position, collision channel, and collision intention mask information); wide-stage filtering and narrow-stage precise detection are performed in the asynchronous thread pool; and finally, the collision results are written back to the game thread and the bullet entity is notified. The collision detection behavior module for tracking fireball bullets is configured to enable the asynchronous parallel collision detection system and checks for collisions with the player character during the post-frame processing phase.

[0042] The hit response behavior module is responsible for executing specific game logic after the collision detection behavior module confirms a hit. This module performs operations such as damage calculation, status application, and effect playback based on the collision result. The hit response behavior module can be designed to support various hit effects, including but not limited to reducing health, applying damage over time effects, knocking back targets, triggering explosion effects, and generating derivative bullets. The hit response behavior module for homing fireball bullets is configured to deduct 100 health points from the player and play an explosion effect at the hit location.

[0043] The destruction behavior module is responsible for resource recycling at the end of the bullet's lifecycle. This module executes when the bullet's lifecycle reaches a preset duration or when the hit response behavior module requests destruction. The destruction behavior module marks the bullet's visual effect instance as hidden or destroyed, and recycles the bullet entity instance into the reuse resource pool for later reuse. The destruction behavior module for tracking fireball bullets is configured to destroy the fireball effect instance and recycle the bullet entity into the reuse resource pool after the bullet's lifecycle reaches 5 seconds or after hitting the player.

[0044] The Derivative Bullet Generation module is responsible for creating new bullet entities when specific conditions are met. This module can execute immediately after bullet creation, periodically during bullet flight, at the end of the bullet's lifecycle, or when the bullet hits a target. The Derivative Bullet Generation module reads parameters from the configuration information, such as generation conditions, derivative bullet configuration identifier, generation quantity, delay time, and generation interval, and then calls the bullet creation interface to generate new bullet entities. For example, when a tracking fireball hits a player, the Derivative Bullet Generation module can be configured to generate 8 scattered small fireballs, each flying in a different direction.

[0045] There is no logical coupling between the aforementioned behavior modules; each module focuses only on processing within its own scope of responsibility. Behavior configuration information can select one or more of these behavior modules as needed, and the order in which these modules are listed determines the processing order during bullet execution. For example, a standard bullet behavior configuration sequence might be: initialization behavior module, motion behavior module, collision detection behavior module, hit response behavior module, and destruction behavior module. If a splitting effect is required, a derivative bullet generation behavior module can be inserted before or after the hit response behavior module.

[0046] In addition to the behavior modules, the behavior configuration information may also include other types of data required for bullet execution. This additional data serves as parameters or constraints for the behavior modules and is used by subsequent scheduling steps and specific behavior modules. Specifically, the behavior configuration information may include, but is not limited to, the following: basic bullet attribute parameters, such as bullet lifespan, activation delay time, collision detection duration, and whether continuous collision detection is enabled; derived bullet generation rules, which include generation conditions, configuration identifiers for derived bullets, generation quantity, delay time, and generation interval; collision detection configuration parameters, such as the shape type of the collider, collision channel number, collision intention mask, and collision detection stage interval; motion-related parameters, such as the type of target being tracked, movement speed, velocity curve resources, turning angular velocity, orbital radius, and angular velocity; and hit response parameters, such as damage value, hit effect resource identifier, and applied status effect. Furthermore, the behavior configuration information may also include the execution order identifier of the behavior modules, which clarifies the order of each behavior module in the behavior scheduling queue.

[0047] For example, the behavior configuration information for tracking fireball bullets can include the following additional data: lifecycle duration is 5 seconds; continuous collision detection is enabled; the derived bullet generation rule is configured to generate 8 scattered small fireballs upon bullet impact, each with an independent bullet configuration identifier; collision detection is configured with sphere shape, collision channel 1, and collision intention mask set to only collide with the player's channel; motion parameters are configured with the tracking target being the player character, movement speed of 800 cm / s, and turning angular velocity of 360 degrees / s; and hit response parameters are configured with damage value of 100 points and hit effect of explosive sparks. This data, together with the behavior module, constitutes the complete bullet behavior configuration information.

[0048] There is a correspondence between various data types in the behavior configuration information and the behavior modules. For example, the derived bullet generation rule data is only used by the derived bullet generation behavior module; motion-related parameters are only read by the motion behavior module; and collision detection configuration parameters are only parsed by the collision detection behavior module. This binding relationship between data and behavior modules is achieved through field naming or reference identifiers in the configuration information. At runtime, each behavior module retrieves the corresponding configuration data from its associated bullet entity and executes specific processing logic based on this data.

[0049] The behavior configuration information can be stored in various data formats, including but not limited to data tables, data assets, structured markup language files (such as JSON, XML), or binary serialized data. Regardless of the storage format, the behavior configuration information is independent of the program code and can be adjusted using editing tools without modifying the code. The behavior configuration information can contain only one behavior module or a combination of multiple behavior modules. When it contains only one behavior module, such as only a destruction behavior module, the bullet will directly enter the destruction process after firing. When it contains multiple behavior modules, these modules are executed sequentially according to a preset order to form a complete behavior sequence.

[0050] By decomposing bullet behavior into independent, configurable behavior modules and separating behavior configuration information from program logic, while incorporating all parameter data required for bullet operation into the configuration information, planners can define, adjust, and combine bullet behavior without writing any code. This significantly improves the flexibility and development efficiency of bullet behavior scheduling and lays a data foundation for subsequent modular scheduling and resource reuse.

[0051] Step S12: Obtain bullet entity instances from the reused resource pool according to the behavior configuration information, construct bullet entities, establish a behavior scheduling queue for the bullet entities, and add each behavior module to the behavior scheduling queue in a preset order:

[0052] After obtaining the bullet's behavior configuration information, a runnable bullet object needs to be created based on this configuration information. Specifically, a bullet entity instance is obtained from the reuse resource pool, a complete bullet entity is constructed based on this instance, a behavior scheduling queue is established for it, and finally, the behavior modules specified in the configuration information are added to the queue in a preset order.

[0053] The reused resource pool is a storage structure that pre-allocates and manages bullet entity instances to avoid frequent memory allocation and deallocation. The pool stores pre-created, idle bullet entity instances. When a new bullet needs to be generated, an idle instance is retrieved directly from the pool. After use, it is returned to the pool for subsequent reuse. Specific implementations of the reused resource pool include, but are not limited to, object pooling, circular buffers, or fixed-size pre-allocated arrays.

[0054] The process of obtaining a bullet entity instance from the reused resource pool refers to: calling the pool manager's acquisition interface, which returns an available bullet entity instance. If there is an idle instance in the pool, it is directly retrieved and marked as used; if there is no idle instance in the pool and the pool capacity has not reached the upper limit, a new bullet entity instance is created and returned; if the pool is full and all instances are in use, it can be processed according to a preset strategy (e.g., blocking and waiting, expanding the pool capacity, or returning a null pointer).

[0055] After obtaining the bullet entity instance, it needs to be initialized to construct a complete bullet entity. The construction process includes setting various runtime attributes of the bullet entity, such as writing basic attributes from the behavior configuration information (lifetime duration, activation delay, etc.) into the bullet entity, establishing the association between the bullet entity and the collision detection system, and allocating internal data structures for managing behavior scheduling. It is worth noting that the bullet entity instance itself is a lightweight data container and does not contain specific execution logic; the actual logic is handled by the behavior modules added to the queue later.

[0056] The behavior scheduling queue is a data structure within the bullet entity used to manage the execution order of behavior modules. This queue typically employs a first-in, first-out (FIFO) structure to ensure that behavior modules are executed sequentially according to the order specified in the configuration information. The behavior scheduling queue can be implemented using a linked list, array, or circular buffer.

[0057] The operation of adding the behavior modules to the behavior scheduling queue in a preset order refers to: traversing the list of behavior modules recorded in the behavior configuration information, and adding a reference or pointer to each behavior module to the bullet entity's behavior scheduling queue in the order listed. The behavior module itself can be a type identifier, class reference, or factory object. It is not immediately instantiated in the queue, but a specific instance is obtained from the behavior module pool during execution. The preset order is determined by the execution order identifier in the behavior configuration information; for example, the initialization behavior module comes first, followed by the motion behavior module, then the collision detection behavior module, and finally the hit response behavior module and the destruction behavior module, arranged in that order.

[0058] For example, taking the "tracking fireball" bullet as an example, the behavior modules specified in its behavior configuration information are in the following order: initialization behavior module, tracking motion behavior module, collision detection behavior module, hit response behavior module, and destruction behavior module. After obtaining an idle bullet entity instance from the reuse resource pool, a behavior scheduling queue is established for this instance, and then the five behavior modules are added to the queue in the above order. In this way, during subsequent scheduling, initialization will be executed first, followed by tracking motion, then collision detection, then hit response, and finally destruction.

[0059] By retrieving instances from the reused resource pool, frequent creation and destruction operations are avoided, significantly reducing memory allocation overhead and garbage collection pressure. Constructing bullet entities and establishing a behavior scheduling queue provides a runtime platform for modular bullet scheduling. Adding behavior modules in a preset order ensures the determinism of bullet behavior execution, allowing for flexible configuration of behavior sequences for different bullet types.

[0060] By combining the reused resource pool with the behavior scheduling queue, a closed loop is formed between bullet entity creation, behavior scheduling, and resource recycling. This achieves high-performance instance reuse and lays the structural foundation for modular execution of bullet behaviors, thereby improving the overall operational efficiency and maintainability of the bullet screen system.

[0061] Step S13: Execute each behavior module in the behavior scheduling queue, determine the behavior modules that need to be continuously executed every frame, and move them into the continuous behavior list for frame traversal after each execution, thereby driving the state update of the bullet entity:

[0062] When executing each behavior module in the behavior scheduling queue, it is first necessary to clarify whether the behavior scheduling queue stores behavior module references or identifiers arranged in a preset order. Each behavior module, when executed, carries an internal flag indicating whether continuous updates are required every frame. The value of this flag determines the behavior module's fate after its first execution: if the flag indicates no continuous updates are needed, the behavior module is discarded after one execution; if the flag indicates continuous updates are required every frame, the behavior module is moved to a dedicated list of continuous behaviors after one execution.

[0063] The persistent behavior list is a collection within the bullet entity used to store behavior modules that need to be executed repeatedly every frame. Unlike the one-time execution of the behavior scheduling queue, the modules in the persistent behavior list are repeatedly invoked within each frame cycle. Specifically, each frame cycle is divided into two sub-phases: a frame update phase and a frame post-processing phase. In the frame update phase, the persistent behavior list is traversed, and the frame update logic of each behavior module is invoked sequentially. In the frame post-processing phase, the same persistent behavior list is traversed again, and the frame post-processing logic of each behavior module is invoked sequentially. This two-phase traversal ensures that bullet movement, timing, and other update operations are completed before collision detection, thereby avoiding logical order errors.

[0064] Taking a fireball-tracking bullet as an example, its behavior configuration sequence includes an initialization behavior module, a motion tracking behavior module, a collision detection behavior module, a hit response behavior module, and a destruction behavior module. The initialization, hit response, and destruction behavior modules are one-time execution modules; they are executed only once and do not need to be moved to the persistent behavior list. The motion tracking and collision detection behavior modules, however, need to be executed continuously every frame; therefore, they are moved to the persistent behavior list after their first execution. In each subsequent frame cycle, the frame update phase iterates through the persistent behavior list, calling the frame update logic of the motion tracking behavior module to update the fireball's position, and simultaneously calling the frame update logic of the collision detection behavior module to prepare collision data. The subsequent post-frame processing phase again iterates through the persistent behavior list, calling the post-frame processing logic of the collision detection behavior module to trigger asynchronous parallel collision detection. In this way, the bullet's movement and collision detection each perform their respective functions, with movement always executing before collision detection.

[0065] By moving the behavior modules that need to be executed continuously every frame into a persistent behavior list and adopting a two-stage frame traversal scheduling method, efficient and orderly driving of bullet behavior is achieved. This design naturally separates one-time behaviors from persistent behaviors, avoids the repeated execution of unnecessary initialization or destruction logic every frame, and ensures the strict timing of frame update logic and frame post-processing logic, providing a reliable scheduling foundation for the stable operation of bullets.

[0066] By distinguishing between one-time behavior modules and continuous behavior modules, and by adopting a two-stage traversal of the continuous behavior list through frame update and frame post-processing, the execution efficiency and logical accuracy of bullet behavior scheduling are significantly improved. This enables core behaviors such as bullet movement and collision to be executed efficiently in a defined order, thereby ensuring the smoothness and reliability of the bullet screen system.

[0067] Step S14: When the collision detection behavior module is executed, the asynchronous parallel collision detection system is called to perform collision detection, and a collision snapshot is collected from the game thread. Wide-stage filtering and narrow-stage precise detection are then performed sequentially in the asynchronous thread pool, and the collision results are written back to the game thread.

[0068] When the collision detection behavior module is executed, the bullet entity no longer performs geometric intersection determination on its own. Instead, it triggers an independent asynchronous parallel collision detection system to complete the task. This collision detection system is completely independent of the game engine's physics components, adopts a pure logic calculation method, and is specifically designed for large-scale bullet hell scenes.

[0069] The execution process of the asynchronous parallel collision detection system begins with the game thread. In the game thread of the current frame, the system traverses all objects in the scene that need to participate in collisions (e.g., bullets, players, monsters, obstacles), collecting the current attribute information of each object, including shape type (sphere, box, or capsule), center position, center position of the previous frame, collision channel number, and collision intention mask. This information is assembled into a lightweight data structure called a collision snapshot. The collision snapshot is much smaller than the collision components of the physics engine and does not contain any virtual functions or engine dependencies, thus it can be safely copied and passed between different threads. Attribute information includes dynamic and static attributes. Static attributes (such as shape type, collision channel, and collision intention mask) are cached once when the object is registered, while dynamic attributes (position, previous frame position) are updated every frame, thereby reducing the data acquisition overhead per frame.

[0070] Taking the tracking of fireball bullets as an example, after the collision detection behavior module is triggered, the asynchronous parallel collision detection system generates collision snapshots in the game thread for the fireball bullet (sphere, radius 30 cm, collision channel 1, collision intention mask is to only collide with the player channel) and the player character (sphere, radius 30 cm, collision channel 2, collision intention mask is to only collide with the bullet channel), respectively, and records their center positions in the current frame (fireball center (100,0,0), player center (120,0,0)) and the center positions in the previous frame (fireball previous frame (50,0,0), player previous frame (120,0,0)).

[0071] After collecting all collision snapshots, the system submits this snapshot data to an asynchronous thread pool. Multiple threads in the thread pool execute subsequent collision detection calculations in parallel, while the game thread continues to process other logic (such as rendering and input response) without being blocked.

[0072] In one embodiment, after all collision snapshots have been collected and before wide-stage filtering is performed, the asynchronous parallel collision detection system also performs a collision filtering. This collision filtering, based on the collision channels and collision intention masks carried in each collision snapshot, quickly eliminates object pairs that should not collide according to the game rules, thereby preventing them from entering subsequent wide-stage and narrow-stage calculations.

[0073] Specifically, each collider is assigned a collision channel number upon registration (e.g., bullet channel 1, player channel 2, monster channel 3, wall channel 4) and a collision intention mask (an integer whose binary bits indicate which channels the object is willing to collide with). For any two objects A and B to be detected, the system calculates two conditions: whether the result of a bitwise AND operation between the collision intention mask of A and the bit identifier corresponding to the collision channel of B is non-zero, and whether the result of a bitwise AND operation between the collision intention mask of B and the bit identifier corresponding to the collision channel of A is non-zero. Only when both conditions are met is A and B considered to have a potential collision, allowing them to enter the wide-stage screening; otherwise, this pair of objects is skipped directly without any further detection.

[0074] Taking the tracking of fireball bullets as an example, the bullet's collision channel is 1, and its collision intention mask is set to only collide with the player's channel (i.e., the second bit of the mask is 1); the player's collision channel is 2, and its collision intention mask is set to only collide with the bullet's channel (i.e., the first bit of the mask is 1). When the bullet and player are considered as a pair of objects, the result of the bitwise AND operation between the bullet's collision intention mask and the bit identifier (1<<2) corresponding to the player's channel is non-zero, and the result of the bitwise AND operation between the player's collision intention mask and the bit identifier (1<<1) corresponding to the bullet's channel is also non-zero. Therefore, this pair of objects passes the collision filtering and is allowed to enter the wide-stage screening. Conversely, if neither of the two bullets (both with channel 1) has a collision intention mask set to collide with the bullet's channel, the bitwise AND result in either direction is zero, and the pair of bullets is skipped directly without entering any collision detection stage. Through this bitwise filtering, the system can eliminate a large number of object pairs that do not need to be detected in a very short time, significantly reducing the computational burden of the wide-stage and narrow-stage processes.

[0075] Collision filtering is implemented entirely based on bitwise operations, without involving any branch predictions or complex judgments, thus achieving extremely high execution efficiency. This step occurs after snapshot acquisition and before wide-stage filtering, fully utilizing the static attributes cached in the snapshot without requiring additional data acquisition overhead. In this way, the asynchronous parallel collision detection system further improves overall performance, ensuring that in large-scale bullet hell scenes, subsequent mesh generation and accurate geometric detection are performed only on truly likely collision pairs.

[0076] In the asynchronous thread pool, the system first performs a wide-stage filtering. The task of the wide stage is to quickly filter out candidate pairs that may intersect from a large number of objects. Specifically, this involves: dynamically dividing all colliders into a spatial grid based on their circumscribed radius, with the grid edge length determined by a preset multiple of the sampled typical radius (e.g., the 75th percentile); establishing a mapping relationship between the grid and objects through a three-pass grid construction method (first counting the number of objects in each grid, then allocating storage space for grids with a quantity greater than 1, and finally filling the index); then, for each grid, adaptively selecting a candidate pair generation algorithm based on the number of objects in the grid—direct pairwise comparison when the quantity is small, coordinate-based scanning filtering when the quantity is moderate, and spatial recursive subdivision when the quantity is large. The wide stage outputs a set of candidate collision pairs, i.e., pairs of objects that may intersect.

[0077] For the example of tracking a fireball bullet and a player, the wide stage calculates the grid side length to be approximately 60 centimeters based on the outer radii of both (both 30 centimeters). The distance between the fireball and the player's positions is only 20 centimeters, so they fall within the same grid. The wide stage outputs them as a candidate pair.

[0078] Next, the system performs narrow-stage precise detection on each candidate pair within the same asynchronous thread pool. The narrow-stage method calculates intersection based on the shape combination of the two colliders using the corresponding analytical geometry method. Supported shape combinations include, but are not limited to, sphere-sphere, sphere-box, sphere-capsule, box-box, box-capsule, and capsule-capsule combinations. For sphere-sphere combinations, the system directly compares the square of the distance between the centers of the two spheres with the square of the sum of their radii; for sphere-box combinations, it calculates the distance from the center of the sphere to the nearest point in the box; other combinations also have corresponding dedicated analytical formulas.

[0079] In the example of tracking the fireball bullet, both the fireball and the player are spheres. The narrow phase uses the sphere-to-sphere analytical formula: the distance between the fireball's center (100,0,0) and the player's center (120,0,0) is calculated to be 20 cm, and the sum of their radii is 60 cm. Since 20 is less than 60, they are considered to intersect. Furthermore, because the fireball bullet uses Continuous Collision Detection (CCD), the narrow phase also performs inter-frame continuous collision detection: based on the relative displacement between the fireball's center in the previous frame (50,0,0) and the current frame's center (100,0,0), and the player's stationary center in the previous and current frames, the motion trajectory equation is solved, revealing a collision at time t=0.4, further confirming a hit.

[0080] After the narrow phase completes the detection of all candidate pairs, the collision results (e.g., bullet 1001 intersects with player 2005) are written to a temporary result set. Subsequently, the system writes these results back to the game thread from the asynchronous thread pool and notifies the corresponding bullet entity via a callback interface. Upon receiving the collision results, the bullet entity can execute the hit response behavior module in the subsequent post-frame processing phase.

[0081] By offloading collision detection from the game thread to an asynchronous thread pool and employing a two-stage parallel processing approach, this method achieves efficient and non-blocking collision detection, maintaining a stable frame rate even when a large number of bullets are on screen simultaneously, while ensuring that high-speed bullets do not penetrate targets due to excessive inter-frame movement.

[0082] By integrating the asynchronous parallel collision detection system with the behavior pipeline, the collision detection and game logic are decoupled and parallelized, significantly improving the collision detection performance in large-scale bullet hell scenes, while ensuring the collision accuracy of high-speed bullets, providing a reliable technical guarantee for the smooth operation of bullet hell games.

[0083] Step S15: Execute the collision-hitting behavior module based on the collision result, and continue executing subsequent behavior modules until destruction. Upon destruction, the bullet entity instance is recycled back to the reused resource pool.

[0084] Once the asynchronous parallel collision detection system writes the collision result back to the game thread, the bullet entity receives the result and triggers the collision hit behavior module. The collision hit behavior module is a pre-configured independent behavior unit within the bullet's behavior sequence, specifically responsible for handling the logic after a bullet hits a target. This module can perform various operations, including but not limited to deducting the target's health, applying a damage over time effect, knocking back the target, playing a hit effect, and generating derivative bullets. For example, for a homing fireball bullet, the collision hit behavior module is configured to deduct 100 health points from the player and play an explosion spark effect at the hit location.

[0085] After executing the collision-hitting behavior module, the bullet entity is not immediately destroyed. Instead, it continues to execute subsequent behavior modules that have not yet been processed in the behavior scheduling queue. The behavior scheduling queue may also contain other behavior modules, such as derivative bullet generation and destruction modules. This design of continuing to execute subsequent behavior modules allows the bullet to complete other necessary logic after a hit, such as generating scattered derivative bullets upon impact or delaying destruction after a period of time. The bullet entity executes these modules sequentially according to a preset order in the queue until there are no more behavior modules to be executed in the queue.

[0086] Once all required behavior modules have been executed, the bullet enters the destruction phase. The destruction behavior module is responsible for releasing all resources occupied by the bullet entity and reclaiming the bullet entity instance into the reuse resource pool. Specific operations performed by the destruction behavior module include, but are not limited to: marking the bullet's visual effect instance as hidden or destroyed, disconnecting the bullet entity from the collision detection system, clearing the bullet entity's internal behavior queue and persistent behavior list, and resetting various runtime attributes of the bullet entity.

[0087] The reuse resource pool is a storage structure that pre-allocates and manages bullet entity instances. Returning a bullet entity instance to the reuse resource pool involves calling the pool manager's recycling interface to return the destroyed bullet entity instance to the pool and mark it as idle. This way, when a new bullet needs to be generated later, the instance can be directly retrieved from the pool for reuse without reallocating memory. The recycling strategies for the reuse resource pool include, but are not limited to, immediate recycling, delayed recycling, or batch recycling.

[0088] Taking the tracking fireball bullet as an example, after the collision detection module confirms that the fireball has hit the player, the collision behavior module is triggered, deducting 100 health points from the player and playing an explosion effect. Subsequently, the bullet entity continues to execute subsequent modules in the behavior scheduling queue. For example, the derivative bullet generation behavior module can generate 8 scattered small fireballs at this moment, each flying in a different direction. Finally, the destruction behavior module destroys the fireball effect instance, clears all runtime data of the fireball bullet, and reclaims the bullet entity instance into the reuse resource pool for use the next time a fireball is launched. Throughout this process, the bullet entity completes a complete closed loop from hit response to resource reclamation, ensuring the integrity of bullet behavior and efficient resource reuse.

[0089] By executing the collision behavior module, continuing the processing of subsequent behavior modules, and reclaiming resources during destruction, this method decouples the bullet hit logic from resource management, allowing the bullet to flexibly perform various subsequent operations after hitting the target. At the same time, by reusing the resource pool, frequent memory allocation and release are avoided, thereby improving the overall performance and scalability of the system.

[0090] By combining the hit-collision behavior module with the destruction and recycling mechanism, bullets can perform subsequent behaviors in an orderly manner and efficiently recycle resources after completing the hit response. This ensures the integrity and flexibility of bullet behavior while significantly reducing memory overhead, thus providing a guarantee for stable operation in large-scale bullet hell scenarios.

[0091] Based on any embodiment of the method in this application, the step of obtaining the behavior configuration information of the bullet includes:

[0092] Step S111: Set the derivative bullet generation rule in the behavior configuration information. The derivative bullet generation rule includes generation conditions, derivative bullet configuration identifier, generation quantity, delay time, and generation interval. The generation conditions are at least one of the following: generating immediately when the bullet is created, generating at the end of the bullet's life cycle, or generating when the bullet hits.

[0093] The bullet's behavior configuration information not only includes the sequence of behavior modules but can also further set rules for generating derivative bullets. These rules are a set of parameters used to control the generation of new bullets under specific conditions, specifically including generation conditions, derivative bullet configuration identifiers, generation quantity, delay time, and generation interval. The derivative bullet configuration identifier points to the behavior configuration information of another bullet, thus defining the behavior sequence and parameters that the generated derivative bullet should have; the generation quantity indicates how many derivative bullets are generated each time a trigger occurs; and the delay time and generation interval control the timing of derivative bullet generation, such as waiting a period of time after the conditions are met before generating, or generating multiple bullets one by one at certain intervals.

[0094] The generation conditions are key elements triggering the generation of derivative bullets, and include at least three types: immediate generation upon bullet creation, generation at the end of the bullet's lifecycle, or generation upon bullet hit. Immediate generation upon bullet creation is suitable for scenarios where other bullets need to be generated simultaneously with the initial bullet's creation, such as releasing a ring of surrounding bullets while firing a parent bullet. Generation at the end of the bullet's lifecycle is suitable for creating a splitting effect when a bullet naturally dies (e.g., its flight time expires), such as the parent bullet exploding into multiple small fireballs after 5 seconds of flight. Generation upon bullet hit is suitable for triggering additional attacks or effects after a bullet hits a target, such as a homing fireball scattering eight sparks in all directions after hitting a player. These three conditions can be used individually, or multiple different derivative bullet generation rules can be set in the same bullet's configuration information to achieve complex, multi-stage splitting effects.

[0095] Step S112: When the behavior module for generating derivative bullets is executed, the bullet entity of the derivative bullet is created according to the derivative bullet generation rules when the generation conditions are met.

[0096] When the derivative bullet generation module is executed, it reads the pre-configured derivative bullet generation rules and checks whether the generation conditions are met. If met, it calls the bullet creation interface according to the parameters in the rules to generate one or more derivative bullet entities. Each derivative bullet has independent behavior configuration information, and therefore can have a completely different behavior mode from the parent bullet. For example, the parent bullet flies in a straight line, while the derivative bullet flies in a homing manner; the parent bullet deals single-hit damage, while the derivative bullet deals area damage. The generation operation can generate all derivative bullets at once, or it can generate them one by one at set intervals, depending on the number of bullets to generate and the generation interval in the rules.

[0097] Taking the tracking fireball bullet as an example, its behavior configuration information sets a derivative bullet generation rule: the generation condition is that it is generated when the bullet hits, the derivative bullet configuration identifier points to the behavior configuration of a scattering small fireball, the generation quantity is 8, the delay time is 0 seconds, and the generation interval is 0 seconds. When the tracking fireball hits the player, the derivative bullet generation behavior module is triggered, and 8 scattering small fireball bullet entities are immediately created at the same hit location. Each small fireball flies outward according to its own configured straight-line trajectory, thus simulating the visual effect of an explosion and splitting.

[0098] In the above embodiments, by setting the rules for generating derivative bullets in the behavior configuration information, and having a dedicated behavior module detect the conditions and create derivative bullets at runtime, the bullets can dynamically generate new bullet entities, thereby flexibly realizing advanced bullet effects such as splitting, rapid fire, and cluster bullets, significantly enhancing the expressiveness and configurability of bullet behavior.

[0099] Based on any embodiment of the method in this application, the step of executing each behavior module in the behavior scheduling queue, determining the behavior module that needs to be continuously executed every frame, and moving it into the continuous behavior list for frame traversal after its execution once, thereby driving the state update of the bullet entity, includes:

[0100] Step S121: For behavior modules that need to be executed continuously every frame, move them to the continuous behavior list after execution once.

[0101] When the bullet entity executes the behavior modules in the behavior scheduling queue, it needs to distinguish which behavior modules only need to be executed once and which behavior modules need to run continuously in each frame period. Each behavior module carries a flag to indicate whether the module needs to be continuously updated every frame. When a behavior module is taken from the behavior scheduling queue and its one-time logic is executed, if the flag indicates that continuous updates are needed, the module is moved to a special list of continuous behaviors; if the flag indicates that continuous updates are not needed, the module is discarded after execution and is no longer retained. In this way, the bullet entity can identify the behavior modules that need to be continuously executed every frame from the behavior queue and store them separately for subsequent frame invocation.

[0102] The persistent behavior list is a collection within the bullet entity used to store behavior modules that need to be executed repeatedly every frame. Unlike a one-time queue, modules in the persistent behavior list do not disappear after execution but are repeatedly invoked in each frame cycle. Specifically, each frame cycle is divided into two sub-phases: the frame update phase and the frame post-processing phase.

[0103] Step S122: During the frame update phase of each frame period, traverse the list of continuous behaviors and execute the frame update logic of each behavior module:

[0104] During the frame update phase, the bullet entity iterates through the list of persistent behaviors, sequentially calling the frame update logic of each behavior module. This phase is typically used to perform update operations that need to be completed first in each frame, such as position movement, velocity calculation, and timer accumulation. For example, the tracking motion module for tracking a fireball bullet is called during the frame update phase to calculate the new position based on the time interval of the current frame and update the bullet's transformation data.

[0105] Step S123: In the post-frame processing stage of each frame period, traverse the list of continuous behaviors and execute the post-frame processing logic of each behavior module:

[0106] During the post-frame processing phase, the bullet entity iterates through the same list of persistent behaviors again, sequentially invoking the post-frame processing logic of each behavior module. This phase is typically used to perform subsequent processing that depends on the frame update results, such as collision detection and lifecycle termination checks. Taking a fireball-tracking bullet as an example, its collision detection module is invoked during the post-frame processing phase. By this time, the bullet's position has been updated, and the collision detection module can perform accurate intersection determination based on the latest position. After the post-frame processing phase is complete, the bullet entity also checks if any new one-time behavior modules have been added to the queue and continues execution.

[0107] The aforementioned two-stage traversal mechanism guarantees a deterministic order of bullet behavior execution: all frame update logic (such as movement) is completed before frame post-processing logic (such as collision detection). If movement and collision detection are placed in the same stage, a logical error may occur where collision detection is performed before movement is completed. By separating frame update from frame post-processing, this application ensures the correctness and reliability of bullet behavior scheduling.

[0108] Taking a fireball-tracking bullet as an example, its behavior configuration sequence includes an initialization behavior module, a motion tracking behavior module, a collision detection behavior module, a hit response behavior module, and a destruction behavior module. The initialization, hit response, and destruction modules are one-time execution modules; they are executed only once and then terminate, not moved to the persistent behavior list. The motion tracking and collision detection modules, however, need to be executed continuously every frame, so they are moved to the persistent behavior list after their first execution. In each subsequent frame cycle, the frame update phase first calls the frame update phase method of the motion tracking module to update the fireball's position, and then calls the frame update phase method of the collision detection module to prepare collision data (e.g., updating the collider's position). The post-frame processing phase then calls the post-frame processing phase method of the collision detection module to trigger asynchronous parallel collision detection. In this way, the fireball's movement is always completed before collision detection, ensuring the accuracy of the hit determination.

[0109] In the above embodiments, by distinguishing between one-time behavior modules and continuous behavior modules, and dividing the execution of each frame into a frame update stage and a frame post-processing stage, efficient and orderly scheduling of bullet behavior is achieved. This avoids the repeated execution of unnecessary initialization or destruction logic in each frame, and ensures that update operations such as movement and timing are completed strictly before collision detection. This significantly improves the execution efficiency and logical accuracy of bullet behavior scheduling, and provides a reliable scheduling foundation for the stable operation of the bullet screen system.

[0110] Based on any embodiment of the method in this application, the step of calling an asynchronous parallel collision detection system to perform collision detection includes:

[0111] Step S141: In the game thread of the current frame, a collision snapshot is assigned to each object involved in the collision. The collision snapshot includes static and dynamic attributes. The static attributes include shape type, collision channel, and collision intention mask, and are cached. The dynamic attributes include the current position and the position of the previous frame, and are updated frame by frame, thereby generating a collision snapshot.

[0112] The process of calling the asynchronous parallel collision detection system to perform collision detection is divided into four sequentially executed steps, corresponding to the generation of collision snapshots, wide-stage filtering, narrow-stage accurate detection, and writing back and notification of collision results.

[0113] By collecting collision-related information from all objects in the scene that need to participate in collisions (such as bullets, players, monsters, and obstacles) and organizing it into a lightweight, thread-safe data structure called a collision snapshot, collision snapshots are created. These snapshots are designed to contain both static and dynamic attributes. Static attributes include shape type (sphere, box, or capsule), collision channel number, and collision intention mask. These attributes are determined when the object is registered and do not change over a period of time, so they can be cached and do not need to be re-acquired each frame. Dynamic attributes include the object's current position and position from the previous frame. These data change every frame, so they need to be re-acquired and updated in the snapshot each frame. By using a strategy of caching static attributes and updating dynamic attributes frame-by-frame, this step significantly reduces the data acquisition overhead per frame. Simultaneously, the collision snapshot itself does not contain any virtual functions or engine dependencies, allowing it to be safely copied from the game thread to an asynchronous thread pool for use. For example, when tracking fireball bullets, this step generates collision snapshots in the game thread for the fireball (sphere, radius 30 cm, collision channel 1, collision intention mask is to only collide with the player channel) and the player (sphere, radius 30 cm, collision channel 2, collision intention mask is to only collide with the bullet channel), recording their center positions in the current frame (fireball center (100,0,0), player center (120,0,0)) and the center positions in the previous frame (fireball previous frame (50,0,0), player previous frame (120,0,0)).

[0114] Step S142: In the asynchronous thread pool, perform wide-stage filtering based on the collision snapshot to generate candidate collision pairs:

[0115] After all collision snapshots are collected, this snapshot data is submitted to the asynchronous thread pool. The game thread no longer participates in subsequent collision calculations but continues to execute other logic (such as rendering and input response), thus avoiding being blocked. In the asynchronous thread pool, the task of wide-stage filtering is to quickly eliminate obviously impossible object pairs from a large number of objects, retaining only candidate pairs that may intersect, to avoid sending all object pairs to the subsequent, more time-consuming precise detection stage. Wide-stage filtering typically employs spatial partitioning techniques, such as dividing the game space into adaptively sized grids, dynamically determining the grid size based on the outer radius of each object, and then establishing the index relationship between the grid and objects through multiple grid construction passes. For objects within each grid, a candidate pair generation algorithm is adaptively selected based on the number of objects: direct pairwise comparison is used when the number is small, a coordinate-based sorting scan is used when the number is moderate, and spatial recursive subdivision is used when the number is large. The output of wide-stage filtering is a set of candidate collision pairs. Taking the tracking fireball bullet as an example, the wide phase calculates the grid side length to be about 60 centimeters based on the outer radius of the fireball and the player (both are 30 centimeters). The two positions are only 20 centimeters apart, so they fall into the same grid. The wide phase outputs the two as a candidate pair.

[0116] Step S143: In the asynchronous thread pool, perform narrow-stage precise detection on the candidate collision pairs to determine the collision result.

[0117] In the asynchronous thread pool, for each candidate collision pair generated in the wide phase, the narrow phase precise detection calculates whether they truly intersect based on the shape combination of the two colliders using the corresponding analytical geometry method. Supported shape combinations include, but are not limited to, sphere-to-sphere, sphere-to-box, sphere-to-capsule, box-to-box, box-to-capsule, and capsule-to-capsule. Each combination has a dedicated analytical geometry formula. For example, for sphere-to-sphere, the square of the distance between the two sphere centers is directly compared to the square of the sum of their radii; for sphere-to-box, the distance from the sphere's center to the nearest point in the box is calculated; and for capsule-to-capsule, the shortest distance between their two midlines is calculated. For objects with Continuous Collision Detection (CCD) enabled (such as high-speed bullets), the narrow phase also performs inter-frame continuous collision detection: when the shape combination has an analytical motion trajectory solution (such as sphere-to-sphere or sphere-to-box), the motion trajectory equation is solved to determine whether a collision occurs between frames; for other combinations, discrete detection points are sampled on the time axis using adaptive sub-step iterations. The output of the narrow phase is a precise collision result, such as bullet A intersecting player B. In the example of tracking a fireball bullet, both the fireball and the player are spheres. The narrow phase calls the sphere-to-sphere analytical formula to calculate the distance between the centers of the two spheres as 20 cm, which is less than the radius and 60 cm, thus determining an intersection. At the same time, since the fireball uses CCD, the motion trajectory equation is also solved based on the positions of the previous and current frames, resulting in a collision at t=0.4, further confirming a hit.

[0118] Step S144: Write the collision result back to the game thread and notify the corresponding bullet entity.

[0119] After all candidate pairs are detected in the narrow phase, the collision result (e.g., bullet 1001 intersects with player 2005) is written to a temporary result set. This result set is then written back to the game thread from the asynchronous thread pool. In the game thread, the system updates the overlap list for each bullet entity based on the collision result and notifies the corresponding bullet entity via a callback interface. Upon receiving the collision result, the bullet entity can execute the collision-hitting behavior module in the subsequent post-frame processing phase. In this way, the time-consuming calculation of collision detection is entirely performed in parallel in a background thread, while the game thread is only responsible for data acquisition and receiving the final result, thus ensuring that collision detection does not block the main thread, and that the timing of the collision results is completely controllable.

[0120] In the above embodiments, by collecting lightweight collision snapshots in the game thread, performing wide-stage filtering and narrow-stage precise detection in parallel in an asynchronous thread pool, and then writing the results back to the game thread, the decoupling and parallelization of collision detection and the main game thread are achieved. This not only eliminates the performance overhead and uncontrollable timing issues caused by the physics engine, but also ensures the collision accuracy of high-speed bullets, significantly improving the running efficiency in large-area bullet hell scenes.

[0121] Based on any embodiment of the method in this application, before the step of generating candidate collision pairs by performing wide-stage filtering based on the collision snapshot in the asynchronous thread pool, the method further includes:

[0122] Step S1411: Obtain the collision intention mask and collision channel for the first and second objects to be detected for collision filtering:

[0123] Before performing wide-stage filtering and generating candidate collision pairs based on collision snapshots in the asynchronous thread pool, a collision filtering and detection step is required. This step utilizes the collision intention mask and collision channel cached in the collision snapshot to quickly eliminate object pairs that should not collide according to the game rules, thereby preventing them from entering the subsequent wide-stage filtering and narrow-stage precise detection, thus improving overall performance.

[0124] For each object to be detected, two key attributes are first read from its respective collision snapshot: a collision intention mask and a collision channel. The collision channel is an integer number used to identify the object's category; for example, bullet channel is 1, player channel is 2, and monster channel is 3. The collision intention mask is an integer whose binary bits indicate which channels the object is willing to collide with. For example, the bullet's collision intention mask can be set to collide only with player channels (i.e., the second bit of the mask is 1), and the player's collision intention mask can be set to collide only with bullet channels (i.e., the first bit of the mask is 1). This step prepares data for subsequent bitwise operations.

[0125] Step S1412: When the result of the bitwise AND operation between the collision intention mask of the first object to be collided and the bit identifier corresponding to the collision channel of the second object to be collided is not zero, and the result of the bitwise AND operation between the collision intention mask of the second object to be collided and the bit identifier corresponding to the collision channel of the first object to be collided is also not zero, then it is determined that the object to be collided has passed the collision filtering detection and is allowed to enter the subsequent collision detection:

[0126] After obtaining the masks and channels of both objects, two bitwise AND operations are performed. First operation: The collision intention mask of the first object is ANDed with the bit identifier corresponding to the collision channel of the second object (i.e., 1 left-shifted by the second object's channel value), and the result is checked for non-zero. Second operation: The collision intention mask of the second object is ANDed with the bit identifier corresponding to the collision channel of the first object, and the result is also checked for non-zero. Only when both results are non-zero is the collision considered logically permissible, and the objects to be collided are passed through collision filtering, allowing them to enter subsequent wide-stage filtering and narrow-stage precise detection. If either result is zero, the object pair is skipped, and no further collision detection is performed. This bitwise operation-based filtering method is highly efficient, eliminating a large number of unnecessary object pairs before wide-stage filtering, such as between bullets and teammate bullets, or between players.

[0127] Taking a fireball-tracking bullet as an example, the bullet's collision channel is 1, and its collision intention mask is set to only collide with the player's channel (i.e., the second bit of the mask is 1). The player's collision channel is 2, and its collision intention mask is set to only collide with the bullet's channel (i.e., the first bit of the mask is 1). When collision filtering is performed on the bullet and player, the result of the bitwise AND operation between the bullet's collision intention mask and the bit identifier (1<<2) corresponding to the player's channel is non-zero, and the result of the bitwise AND operation between the player's collision intention mask and the bit identifier (1<<1) corresponding to the bullet's channel is also non-zero. Therefore, the objects to be collided pass the collision filtering detection and are allowed to enter the wide-stage filtering. Conversely, if neither bullet (both channels are 1) has a collision intention mask set to collide with the bullet's channel, the bitwise AND result in either direction is zero, and the pair of bullets is skipped directly without entering any collision detection stage. Through this collision filtering detection, the system can eliminate a large number of object pairs that do not need to be detected in a very short time, significantly reducing the computational burden of the subsequent wide and narrow stages.

[0128] In the above embodiments, by performing bitwise-based collision filtering detection before wide-stage filtering, and utilizing the static attributes cached in the collision snapshot to quickly eliminate object pairs that should not collide, the computational load of the wide and narrow stages is significantly reduced, thereby further improving the overall performance of the asynchronous parallel collision detection system.

[0129] Based on any embodiment of the method in this application, the asynchronous parallel collision detection system performs a wide-stage screening step including:

[0130] Step S1421: Sample the circumscribed radius of the objects involved in the collision and calculate its statistical quantile as the typical radius:

[0131] The asynchronous parallel collision detection system performs a wide-stage screening process, which is divided into four sequentially executed steps, corresponding to adaptive calculation of grid size, spatial grid partitioning, establishment of index relationships, and adaptive selection of candidate pair generation algorithms.

[0132] The first step in wide-stage filtering is determining the size of the spatial grid. This requires sampling the circumscribed radii of all objects involved in the collision. The circumscribed radius is the radius of the smallest sphere that can completely enclose the collision shape of the object: for a spherical collider, the circumscribed radius is the radius of the sphere itself; for a box collider, the circumscribed radius is half the length of the box's diagonal; for a capsule collider, the circumscribed radius is the sum of half the capsule's length and its radius. To avoid the performance overhead of traversing all objects, a limited number of objects are typically sampled (e.g., a maximum of 256), either randomly or at equal intervals.

[0133] After obtaining the set of circumscribed radii of the sampled objects, the statistical quantiles of these radii are calculated as the typical radius. A commonly used quantile is the 75th quantile (i.e., the third or fourth quantile), which represents the circumscribed radius of most objects in the scene and effectively avoids the adverse effects of extremely large or small objects on the mesh size. Specifically, the sampled circumscribed radii are sorted from smallest to largest, and the value at the 75th percentile is taken as the typical radius. For example, if the sampled circumscribed radius array is [15, 20, 22, 25, 28, 30, 32, 35, 40, 100] (in centimeters), and the value at the 75th percentile after sorting is 35 centimeters, then the typical radius is 35 centimeters. Through this statistical method, the mesh size can adaptively match the general size of objects in the current scene.

[0134] Step S1422: Set the grid side length to a preset multiple of the typical radius, thereby dividing the space into a grid.

[0135] After obtaining the typical radius, the grid edge length is set to a preset multiple of that typical radius. The preset multiple is typically 2, meaning the grid edge length equals twice the typical radius. Choosing this multiple requires balancing two factors: if the multiple is too large, each grid contains too many objects, increasing the complexity of the candidate pair generation algorithm; if the multiple is too small, each object may span multiple grids, causing redundant computation and memory overhead. Setting the grid edge length to twice the typical radius ensures that the circumscribed sphere diameter (twice the radius) of most objects is comparable to the grid edge length, thus ensuring that each object typically covers only a few grids, and the number of objects within each grid remains within a reasonable range.

[0136] Taking the tracking of a fireball bullet as an example, the outer radius of both the bullet and the player in the scene is 30 centimeters, and the typical radius calculated after sampling is also 30 centimeters. Therefore, the grid side length is set to 60 centimeters. Based on this grid size, the entire game space is divided into multiple cubic grids with a side length of 60 centimeters. Since the distance between the center of the fireball and the center of the player is only 20 centimeters, they fall within the same grid, which facilitates the generation of subsequent candidate pairs.

[0137] Step S1423: Generate the index relationship between the mesh and the object through multiple grid construction steps:

[0138] After determining the mesh size, it is necessary to establish a mapping relationship between each object and the mesh it covers, so as to quickly find objects within the same mesh later. To improve memory efficiency and calculation speed, a three-pass mesh construction method is adopted.

[0139] The first pass of the collision count involves iterating through all objects involved in the collision, calculating the axis-aligned bounding box (AABB) for each object, and then determining which grid cells the object covers (i.e., the range from the smallest to the largest grid coordinates) based on this bounding box. For each covered grid cell, the object count for that grid cell is incremented in a hash table or dictionary. This pass only counts the number of objects within each grid cell, without storing the specific object indices.

[0140] The second round of allocation: Iterate through all the meshes generated in the first round of counting. For meshes with an object count greater than 1, allocate a storage array (e.g., a dynamic array) for them, and reserve space exactly equal to that count. For meshes with a count of 1, since there is only one object, it is impossible for them to form a collision pair with other objects in the mesh, so no storage space needs to be allocated, and they are skipped directly. This avoids allocating unnecessary memory for a large number of meshes with only one object.

[0141] The third filling pass: Iterate through all objects involved in the collision again, repeatedly calculate the mesh range covered by each object, and add the object's index to the storage array of the corresponding mesh. Since the second pass has already reserved enough capacity for each mesh that needs to be stored, the third filling operation will not trigger dynamic expansion, thus ensuring efficiency.

[0142] By using this three-pass grid construction method, a mapping relationship from grid coordinates to a list of object indices is finally obtained, which only includes grids with more than 1 object, greatly saving memory and subsequent computational overhead.

[0143] Step S1424: For each object in the grid, adaptively select the corresponding candidate pair generation algorithm based on the number of objects in the grid.

[0144] For each non-empty grid (i.e., a grid with more than one object), it is necessary to generate all possible collision pairs (candidate pairs) within that grid. However, the number of objects in different grids can vary greatly. If the same algorithm is used for all grids, it will cause unnecessary algorithmic overhead when the number of objects is small, and may lead to performance degradation when the number of objects is large. Therefore, an algorithm for generating candidate pairs should be adaptively selected based on the number of objects in the grid.

[0145] When the number of objects in the grid is small (e.g., less than or equal to 32), a pairwise direct comparison method is used. The algorithm simply uses a double loop to traverse all objects in the grid, checking for overlap between the bounding boxes of each pair (as a coarse sieve in the wide stage). If they overlap, they are output as a candidate pair. Since the number of objects is small, the overhead of the double loop is perfectly acceptable, and the algorithm is simple to implement and cache-friendly.

[0146] When the number of objects in the grid is moderate (e.g., greater than 32 and less than or equal to 128), a coordinate-based sorting scanning method is used. This algorithm first selects a coordinate axis with the largest dispersion (usually the X-axis), sorts the projection intervals (minimum to maximum value) of all objects on this axis, and then uses the Sweep and Prune (SAP) method to find all overlapping interval pairs. Specifically, it sorts the interval endpoints (start and end points) of all objects in a mixed manner, iterates through the sorted sequence, adds the object to the active set when a start point is encountered, and removes it from the active set when an end point is encountered. Whenever a new object is added, it is paired with all existing objects in the active set to form a candidate pair. The complexity of this algorithm is O(M log M), which is better than the O(M) complexity of the double loop algorithm. 2 (Faster)

[0147] When the number of objects in the grid is large (e.g., greater than 128), a spatial recursive subdivision approach is used. This algorithm further divides the current grid into eight octagonal subgrids, assigning each object to a corresponding subgrid based on its center position. Then, the same wide-stage filtering (i.e., selecting the algorithm again based on the number of objects within the subgrid) is recursively performed on each subgrid. Additionally, it checks whether object pairs between different subgrids might intersect, which is done by quickly pruning by comparing whether the bounding boxes of the subgrids overlap. This octagonal subdivision can decompose high-density regions into multiple low-density subregions, thus reducing the complexity from O(M) to O(M). 2 ) decreased to near O(M 2 / 8), which significantly reduced the number of candidate pairs.

[0148] Through the aforementioned adaptive selection mechanism, wide-stage filtering maintains high efficiency in scenarios with various density distributions, providing as few candidate collision pairs as possible for subsequent narrow-stage accurate detection. Taking tracking fireballs as an example, since there are only two objects in the grid containing the fireball and the player, far fewer than 32, the system chooses to directly compare them pairwise, outputting the fireball and the player as a single candidate pair.

[0149] In the above embodiments, the grid size is adaptively determined by calculating the statistical quantile through sampling circumscribed radius, the index relationship between the grid and objects is efficiently established by three-pass grid construction, and the candidate pair generation algorithm is adaptively selected according to the number of objects in the grid. This enables wide-stage screening to maintain high performance under different scene densities, providing a fast and scalable coarse screening capability for asynchronous parallel collision detection systems.

[0150] Based on any embodiment of the method in this application, the asynchronous parallel collision detection system performs narrow-stage accurate detection by including:

[0151] Step S1431: Based on the shape combination of the two colliding bodies, call the corresponding analytical geometry determination method to calculate whether they intersect; wherein, the shape combination includes at least one of: sphere and sphere, sphere and box, sphere and capsule, box and box, box and capsule, and capsule and capsule.

[0152] The asynchronous parallel collision detection system performs narrow-stage accurate detection in two sequentially executed steps, corresponding to discrete collision detection (i.e., analytical geometric determination based on shape combination) and continuous collision detection for high-speed objects.

[0153] For each candidate collision pair generated by the wide-stage screening, the first step of the narrow-stage is to perform a precise intersection determination based on the actual shape types of the two colliders, using analytical geometric formulas specifically designed for that shape combination. Supported shape combinations include, but are not limited to, spheres and spheres, spheres and boxes, spheres and capsules, boxes and boxes, boxes and capsules, and capsules and capsules. Each combination has a corresponding analytical solution, avoiding the performance overhead of using general iterative algorithms (such as GJK).

[0154] When both colliding objects are spheres, the system directly calculates the square of the distance between the centers of the two spheres and compares it with the square of the sum of the radii of the two spheres. If the square of the distance is less than or equal to the square of the sum of the radii, the spheres are considered to intersect; otherwise, they are not. For example, the distance between a tracking fireball bullet (radius 30 cm, center (100,0,0)) and the player (radius 30 cm, center (120,0,0)) is 20 cm, and the sum of the radii is 60 cm. Since 20 is less than 60, the spheres are considered to intersect.

[0155] When the colliding objects are a sphere and a box, the system first calculates the distance from the center of the sphere to the nearest point on the box. Specifically, the sphere's center coordinates are clamped to the box's axis-aligned bounding box to obtain the point on the box closest to the sphere's center, and then the distance between that point and the sphere's center is calculated. If this distance is less than or equal to the sphere's radius, an intersection is determined. For a rotating box (OBB), the nearest point calculation is performed after transforming the sphere's center to the box's local coordinate system.

[0156] When the colliding objects are a sphere and a capsule, the system calculates the shortest distance from the center of the sphere to the central axis of the capsule. The capsule consists of a line segment (central axis) and a radius. First, the nearest point from the center of the sphere to the line segment is found, and then the distance between that point and the center of the sphere is calculated. If this distance is less than or equal to the sum of the sphere's radius and the capsule's radius, then an intersection is determined.

[0157] When the colliding bodies are box-to-box objects, for axis-aligned boxes (AABB), the system uses the Separating Axis Theorem (SAT) to sequentially check whether the projection intervals on the three coordinate axes overlap. If the projections on all axes overlap, then an intersection is determined. For rotated boxes (OBB), up to 15 separating axes need to be checked (including the cross products of the three face normals and the pairwise edge directions), and an intersection is only determined if the projections on all axes overlap.

[0158] When the colliding objects are a box and a capsule, the system first determines the relationship between the capsule's central axis and the box, calculating the shortest distance from the central axis to the box. This typically requires transforming the capsule to the box's local coordinate system, and then finding the shortest distance from the line segment to the axis aligned with the box. If this distance is less than or equal to the capsule's radius, then an intersection is determined.

[0159] When the colliding objects are two capsules, the system calculates the shortest distance between their central axes. The shortest distance between two line segments can be obtained by parameterizing the line segments and solving a quadratic optimization problem. If this shortest distance is less than or equal to the sum of the radii of the two capsules, they are considered to intersect.

[0160] All of the above analytical geometric determination methods use direct mathematical formulas and do not involve iterative or approximate calculations. Therefore, they are extremely efficient and can complete the accurate detection of a large number of candidate pairs within milliseconds.

[0161] Step S1432: For objects with continuous collision detection enabled, depending on whether the combination of collider shapes has an analytical motion trajectory solution, select either analytical solution or discrete sampling detection method to perform inter-frame continuous collision detection.

[0162] For objects with continuous collision detection (CCD) enabled (such as high-speed bullets), additional inter-frame continuous collision detection is required in the narrow phase to prevent target penetration due to excessive movement distance between two frames. Continuous collision detection selects different detection methods based on whether the shape combination of the two colliders has a resolute motion trajectory.

[0163] When the colliding objects are spheres and each other, or spheres and boxes, the system uses an analytical solution. Taking spheres and spheres as an example, the system calculates the relative motion vector and relative initial position based on the center positions of the two spheres in the previous and current frames. Then, it solves a quadratic equation with respect to time t to determine if there exists a t∈[0,1] such that the distance between the centers of the two spheres equals the sum of their radii. If so, a collision is determined to have occurred between frames. For spheres and boxes, the system expands the box by the radius of a sphere, transforming it into a ray-intersection test with the expanded box. The collision time is also obtained analytically. This analytical method can accurately determine the collision time without sampling error.

[0164] When the shapes of the colliders are combined in other ways (e.g., box-to-box, box-to-capsule, capsule-to-capsule), since these combinations do not have simple analytical motion trajectory solutions, the system adopts an adaptive sub-step iterative discrete sampling detection method. First, the number of sampling steps is calculated based on the relative displacement and the minimum feature size of the colliders (e.g., the minimum half-length of a box, the radius of a capsule, etc.). The formula for calculating the number of steps is: K = ceil(|relative displacement| / (α × minimum feature size)), where α is a preset coefficient (usually 1), and the number of steps is limited to between 1 and 32. Then, K points are uniformly sampled within the time interval [0,1] (i.e., t = 1 / K, 2 / K, ..., 1), and a discrete collision detection is performed once for each sampled point (i.e., the aforementioned analytical geometry determination method is called). If any sampled point detects an intersection, it is determined that a collision has occurred between frames. This adaptive sub-step iterative method can avoid excessive performance overhead while ensuring detection accuracy.

[0165] Taking the tracking fireball bullet as an example, continuous collision detection is enabled for the bullet. The bullet's center in the previous frame is (50,0,0), the center in the current frame is (100,0,0), and the player is stationary at (120,0,0). Since both the bullet and the player are spheres, they belong to a combination with analytical motion trajectory solutions, so the system directly solves the motion trajectory equation. The relative displacement is (50,0,0), the relative initial position is (-70,0,0), and the sum of the radii is 60. Solving the quadratic equation yields t≈0.4, which is within the interval [0,1], thus determining that a collision has occurred between frames. If the bullet collides with a rotating box, and the box has no analytical motion trajectory solution, the system will calculate the number of sampling steps (e.g., 5 steps) based on the relative displacement and the minimum half-length of the box, and then perform discrete detection at t=0.2, 0.4, 0.6, 0.8, and 1.0 respectively. Once any intersection is found, a hit is confirmed.

[0166] The aforementioned continuous collision detection mechanism effectively prevents high-speed bullets from penetrating targets due to excessive inter-frame movement, ensuring the accuracy of collision detection and the reliability of game logic.

[0167] In the above embodiments, by calling dedicated analytical geometric formulas for discrete intersection determination for six shape combinations, and by selecting analytical solution or adaptive sub-step iteration to perform continuous collision detection for high-speed objects according to shape combinations, the efficiency and accuracy of narrow-stage precise detection are achieved. This ensures the accuracy of collision determination while avoiding the performance overhead of general physics engines, providing a solid technical foundation for smooth operation in large-scale bullet screen scenes.

[0168] Please see Figure 3According to one aspect of this application, a bullet behavior scheduling device includes a bullet configuration acquisition module 11, a bullet entity construction module 12, a bullet behavior scheduling module 13, an asynchronous collision detection module 14, and a bullet hit collision module 15. The bullet configuration acquisition module 11 is used to acquire bullet behavior configuration information, which includes at least one behavior module, each behavior module corresponding to an independent behavior stage in the bullet's lifecycle. The bullet entity construction module 12 is used to acquire bullet entity instances from a reused resource pool based on the behavior configuration information, construct bullet entities, establish a behavior scheduling queue for the bullet entities, and add each behavior module to the behavior scheduling queue in a preset order. The bullet behavior scheduling module 13... The system is used to execute each behavior module in the behavior scheduling queue, determine the behavior modules that need to be continuously executed every frame, and move them into the continuous behavior list for frame traversal after each execution, thereby driving the state update of the bullet entity; the asynchronous collision detection module 14 is used to call the asynchronous parallel collision detection system to perform collision detection when the collision detection behavior module is executed, collect collision snapshots from the game thread, perform wide-stage filtering and narrow-stage precise detection in the asynchronous thread pool in sequence, and write the collision results back to the game thread; the bullet hit collision module 15 is used to execute the hit collision behavior module according to the collision result, and continue to execute subsequent behavior modules until destruction, and recycle the bullet entity instance to the reuse resource pool when it is destroyed.

[0169] Based on any embodiment of the device in this application, the bullet screen configuration acquisition module 11 includes: a derivative bullet generation rule unit, used to set derivative bullet generation rules in the behavior configuration information, wherein the derivative bullet generation rule includes generation conditions, derivative bullet configuration identifier, generation quantity, delay time, and generation interval, wherein the generation conditions are at least one of immediate generation when the bullet is created, generation at the end of the bullet's life cycle, or generation when the bullet hits; and a derivative bullet generation unit, used to create a bullet entity of a derivative bullet according to the derivative bullet generation rule when the generation conditions are met when the derivative bullet generation behavior module is executed.

[0170] Based on any embodiment of the device in this application, the bullet behavior scheduling module 13 includes: a behavior module moving unit, used to move a behavior module that needs to be continuously executed every frame into a continuous behavior list after execution once; a frame update unit, used to traverse the continuous behavior list and execute the frame update logic of each behavior module during the frame update phase of each frame period; and a frame post-processing unit, used to traverse the continuous behavior list and execute the frame post-processing logic of each behavior module during the frame post-processing phase of each frame period.

[0171] Based on any embodiment of the device in this application, the asynchronous collision detection module 14 includes: a collision snapshot allocation unit, configured to allocate a collision snapshot for each object participating in the collision in the game thread of the current frame, wherein the collision snapshot includes static attributes and dynamic attributes, the static attributes include shape type, collision channel and collision intention mask and are cached, and the dynamic attributes include current position and previous frame position and are updated frame by frame, thereby generating a collision snapshot; a candidate collision pair generation unit, configured to perform wide-stage filtering based on the collision snapshot in the asynchronous thread pool to generate candidate collision pairs; a narrow-stage detection unit, configured to perform narrow-stage precise detection on the candidate collision pairs in the asynchronous thread pool to determine the collision result; and a collision result write-back unit, configured to write the collision result back to the game thread and notify the corresponding bullet entity.

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

[0173] The processor of the bullet behavior scheduling device provides computational and control capabilities, supporting the operation of the entire device. The device's memory can store computer-readable instructions, which, when executed by the processor, cause the processor to perform the bullet behavior scheduling method of this application. The device's network interface is used for communication with a terminal.

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

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

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

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

[0178] In summary, this application solves the problems of coupled bullet behavior logic and performance bottlenecks in collision detection, and achieves modular scheduling and asynchronous parallel collision detection, thereby improving development efficiency, runtime performance and scalability.

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

Claims

1. A bullet behavior scheduling method, characterized in that, include: Obtain bullet behavior configuration information, wherein the behavior configuration information includes at least one behavior module, and each behavior module corresponds to an independent behavior stage in the bullet's life cycle; Based on the behavior configuration information, a bullet entity instance is obtained from the reuse resource pool, a bullet entity is constructed, and a behavior scheduling queue is established for the bullet entity. Each behavior module is added to the behavior scheduling queue in a preset order. Each behavior module in the behavior scheduling queue is executed, and the behavior module that needs to be continuously executed every frame is determined. After it is executed once, it is moved into the continuous behavior list for frame traversal, thereby driving the state update of the bullet entity. When the collision detection behavior module is executed, the asynchronous parallel collision detection system is invoked to perform collision detection. Collision snapshots are collected from the game thread, and wide-stage filtering and narrow-stage precise detection are performed sequentially in the asynchronous thread pool. The collision results are then written back to the game thread. The asynchronous parallel collision detection system is a pre-defined physics component independent of the game engine. The collision snapshots contain static and dynamic attributes. The static attributes include shape type, collision channel, and collision intention mask. The dynamic attributes include the current position and the position of the previous frame. The wide-stage filtering is used to determine candidate collision pairs with an intersection probability based on the collision snapshots. The narrow-stage precise detection is used to determine the collision result corresponding to the candidate collision pair based on the shape combination of the colliders in the candidate collision pair. The collision-hitting behavior module is executed based on the collision result, and subsequent behavior modules are executed until the object is destroyed. Upon destruction, the bullet entity instance is recycled back to the reuse resource pool.

2. The method according to claim 1, characterized in that, The steps for obtaining the bullet's behavior configuration information include: In the behavior configuration information, a derivative bullet generation rule is set. The derivative bullet generation rule includes generation conditions, derivative bullet configuration identifier, generation quantity, delay time, and generation interval. The generation conditions are at least one of the following: generating bullets immediately when they are created, generating bullets at the end of their life cycle, or generating bullets when they hit a target. When the behavior module for generating derivative bullets is executed, a bullet entity for the derivative bullet is created according to the derivative bullet generation rules and when the generation conditions are met.

3. The method according to claim 1, characterized in that, The step of executing each behavior module in the behavior scheduling queue, determining the behavior modules that need to be continuously executed every frame, and moving them into the continuous behavior list for frame traversal after each execution, thereby driving the state update of the bullet entity, includes: For behavior modules that need to be executed continuously every frame, move them to the list of continuous behaviors after execution. During the frame update phase of each frame cycle, the list of continuous behaviors is traversed, and the frame update logic of each behavior module is executed. During the post-frame processing phase of each frame period, the list of continuous behaviors is traversed, and the post-frame processing logic of each behavior module is executed.

4. The method according to claim 1, characterized in that, The steps involved in calling the asynchronous parallel collision detection system to perform collision detection include: In the game thread of the current frame, a collision snapshot is assigned to each object involved in the collision. The collision snapshot contains static and dynamic attributes. The static attributes include shape type, collision channel, and collision intention mask and are cached. The dynamic attributes include the current position and the position of the previous frame and are updated frame by frame, thereby generating a collision snapshot. In the asynchronous thread pool, wide-stage filtering is performed based on the collision snapshot to generate candidate collision pairs; In the asynchronous thread pool, narrow-stage precise detection is performed on the candidate collision pairs to determine the collision result; The collision result is written back to the game thread, and the corresponding bullet entity is notified.

5. The method according to claim 4, characterized in that, Before the step of performing wide-stage filtering based on the collision snapshot in the asynchronous thread pool to generate candidate collision pairs, the method further includes: Obtain the collision intention mask and collision channel of the first and second objects to be collided for collision filtering detection; If the result of the bitwise AND operation between the collision intention mask of the first object to be collided and the bit identifier corresponding to the collision channel of the second object to be collided is not zero, and the result of the bitwise AND operation between the collision intention mask of the second object to be collided and the bit identifier corresponding to the collision channel of the first object to be collided is also not zero, then it is determined that the object to be collided has passed the collision filtering detection and is allowed to enter the subsequent collision detection.

6. The method according to claim 4, characterized in that, The asynchronous parallel collision detection system performs wide-stage screening by including the following steps: Sample the circumscribed radius of the objects involved in the collision and calculate its statistical quantile as the typical radius; The space is divided into grids by setting the grid side length to a preset multiple of the typical radius; The index relationship between the mesh and the object is generated through multiple grid construction steps; For each object in a grid, the corresponding candidate pair generation algorithm is adaptively selected based on the number of objects in the grid.

7. The method according to claim 4, characterized in that, The asynchronous parallel collision detection system performs narrow-stage accurate detection by including the following steps: Based on the shape combination of the two colliding bodies, the corresponding analytical geometry determination method is called to calculate whether they intersect; wherein, the shape combination includes at least one of: sphere and sphere, sphere and box, sphere and capsule, box and box, box and capsule, and capsule and capsule; For objects with continuous collision detection enabled, inter-frame continuous collision detection is performed by selecting either analytical solution or discrete sampling detection method, depending on whether the combination of collider shapes has an analytical motion trajectory solution.

8. A bullet behavior control device, characterized in that, include: A bullet configuration acquisition module is used to acquire bullet behavior configuration information, wherein the behavior configuration information includes at least one behavior module, and each behavior module corresponds to an independent behavior stage in the bullet's life cycle. The bullet entity construction module is used to obtain bullet entity instances from the reused resource pool according to the behavior configuration information, construct bullet entities, establish a behavior scheduling queue for the bullet entity, and add each behavior module to the behavior scheduling queue in a preset order. The bullet behavior scheduling module is used to execute each behavior module in the behavior scheduling queue, determine the behavior modules that need to be continuously executed every frame, and move them into the continuous behavior list for frame traversal after they are executed once, thereby driving the state update of the bullet entity. An asynchronous collision detection module is used to invoke an asynchronous parallel collision detection system to perform collision detection when the collision detection behavior module is executed. This system collects collision snapshots from the game thread, performs wide-stage filtering and narrow-stage precise detection sequentially in an asynchronous thread pool, and writes the collision results back to the game thread. The asynchronous parallel collision detection system is a pre-defined physics component independent of the game engine. The collision snapshots contain static and dynamic attributes. The static attributes include shape type, collision channel, and collision intention mask. The dynamic attributes include the current position and the position of the previous frame. The wide-stage filtering is used to determine candidate collision pairs with an intersection probability based on the collision snapshots. The narrow-stage precise detection is used to determine the collision result corresponding to the candidate collision pair based on the shape combination of the colliders in the candidate collision pair. The bullet hit collision module is used to execute the hit collision behavior module according to the collision result, and continue to execute the subsequent behavior modules until destruction, and when destroyed, the bullet entity instance is recycled to the reuse resource pool.

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

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

Images