Semantic tag driven game entity collision filtering method, electronic device and medium

By establishing a tag registry during game engine loading, dynamically mapping semantic tags to bit indexes, and using bidirectional forced propagation, the high error rate and poor performance of existing entity collision filtering methods are solved, achieving zero-overhead collision filtering and semantic differentiation, and improving the simplicity and consistency of configuration.

CN122377136APending Publication Date: 2026-07-14BEIJING WAZIDA TECH CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
BEIJING WAZIDA TECH CO LTD
Filing Date
2026-05-22
Publication Date
2026-07-14

AI Technical Summary

Technical Problem

Existing entity collision filtering methods in game engines suffer from issues such as global coupling of bit protocols, redundancy of bilateral declarations, poor whitelist and blacklist representation capabilities, region volume syntax confusion, lack of automation capabilities in current technologies, semantic problems, error post-processing, and performance issues. Furthermore, they cannot automatically convert semantic tags to bit operations during loading, resulting in semantic tags being converted to bit operations, and they cannot distinguish between physical objects and region volume semantics.

Method used

By establishing a tag registry during game loading, dynamically mapping semantic tags to their indexes, automatically calculating collision layers and collision masks, and ensuring bidirectional propagation through bidirectional forced propagation, the semantics of physical objects and region objects are distinguished, and collision filtering is performed with zero overhead.

Benefits of technology

It achieves zero-overhead collision filtering during game runtime, reducing error rate and improving performance. The semantic tag-driven approach makes configuration simpler and more consistent, supports whitelist and blacklist declarations, and distinguishes between physical objects and region objects semantics.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122377136A_ABST
    Figure CN122377136A_ABST
Patent Text Reader

Abstract

The application provides a semantic label driven game entity collision filtering method, an electronic device and a medium. The semantic label driven game entity collision filtering method comprises: establishing and maintaining a label bit registry in a game loading period; obtaining a configuration declaration of a game entity and a label of the game entity; in the game loading period, automatically calculating a collision layer and a collision mask of the game entity by querying the label bit registry according to a body type, the label and a filtering declaration of the game entity; in the game loading period, performing bidirectional forced propagation processing to obtain a modified collision layer and a modified collision mask of the game entity; and submitting the modified collision layer and the modified collision mask of the game entity to a physical engine, so that zero-cost collision filtering is realized in a game running period. The purpose of reducing errors and improving performance in game collision simulation is achieved.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] Cross-reference to related applications This invention patent application claims priority to Chinese invention patent application filed on May 14, 2026, with application number 2026106668137 and title "Semantic Tag-Driven Game Entity Collision Filtering Method, Electronic Device and Medium", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This invention belongs to the field of game engine technology, and in particular relates to a semantic tag-driven game entity collision filtering method, electronic device and medium. Background Technology

[0003] In game physics engines, "entity collision filtering" is a common scenario. Existing technologies include: I. Unity Layer Collision Matrix: Unity provides a visual layer collision matrix panel (32×32 checkboxes). Developers first manually register 32 layer names in the Labels & Layers window (manually assigning positions); then check or uncheck the collision relationship for each pair of layers; and finally specify the layer to which each game object belongs.

[0004] II. Godot Collision Layers and Collision Masks: Godot exposes two bit field attributes for collision objects: the collision layer and the collision mask. Developers can manually name the first 20 layers in the layer name window of the project settings; check the layer options in the inspector of each collider node; or use a script to set the truth value of the layer by bit index.

[0005] Third, Unreal Engine provides a "preset collision preset" mechanism (all block, all overlap, custom). In essence, it still involves filling in a three-value table of block, overlap, and ignore for each pair of object types and channels, requiring developers to maintain global channel naming and preset inheritance relationships.

[0006] Fourth, some engines use runtime string comparison—checking whether the other party's tag is an enemy in the collision callback. Although this approach does not rely on bits, it postpones filtering until after the physics engine has completed wide-phase filtering, wasting the physics engine's performance; and it cannot utilize wide-phase filtering to reduce the callback frequency.

[0007] The existing technology has the following problems: 1. Global coupling of bit protocols: Adding a bit to a new entity may require modifying all related collision masks; AI or player-generated UGC scenes cannot self-coordinate.

[0008] 2. Redundant and error-prone bilateral declarations: If entity A is to pass through entity B, it must be declared in both entity A and entity B. Omission on either side will result in undefined physical behavior.

[0009] 3. Poor whitelist and blacklist expression capabilities: If an entity wants to "collide only with friendly forces and walls" (whitelist) or "collide with all others except walls" (blacklist), bit operations would require writing inverse bitmasks, which is an anti-human expression.

[0010] 4. Confusion between region volume semantics and physical volume: Triggers and collision volumes have no distinguishing symbols under bit protocols, resulting in high costs for documentation and code review.

[0011] 5. Error post-processing: Inconsistent declarations on both sides, masks pointing to non-existent layers. These errors are only exposed at runtime.

[0012] The existing collision simulation technology has the following problems: collision filtering relies on manual bit protocols, which have high performance but are prone to errors and have bilateral redundancy; or it relies on runtime string comparison, which is simple but has poor performance. Summary of the Invention

[0013] To address the problems existing in the prior art, this invention provides a semantic tag-driven game entity collision filtering method, electronic device, and medium, which at least partially solves the problems existing in the prior art, such as the inability to automatically convert semantic tags to bits during loading, the lack of bidirectional propagation of one-sided declarations, and the inability to distinguish between the semantics of physical objects and region objects.

[0014] In a first aspect, embodiments of this disclosure provide a semantic tag-driven game entity collision filtering method, including: During game loading, a tag bit registry is established and maintained. The tag bit registry is used to dynamically map the first occurrence of a semantic tag string to a unique bit index in sequence and generate the corresponding bit value. Obtain the configuration declaration and tags of the game entity, wherein the configuration declaration includes the entity's body type and filtering declaration; During game loading, based on the body type, tag, and filter declaration of the game entity, the collision layer and collision mask of the game entity are automatically calculated by querying the tag registry. During game loading, a bidirectional forced propagation process is performed. This process includes automatically modifying the collision mask of the second entity when the first entity filter declaration contains a tag of the second entity. This is done to eliminate the broadcast bit in the collision layer of the first entity, ensuring that the bitwise AND operation between the collision layer of the first entity and the mask of the second entity, and the bitwise AND operation between the collision layer of the second entity and the collision mask of the first entity, are both zero. This ensures that collision detection between the first entity and the second entity is bidirectionally disabled, thereby obtaining the modified collision layer and collision mask of the game entity. The modified collision layers and collision masks of game entities are submitted to the physics engine, thereby achieving zero-overhead collision filtering during game runtime.

[0015] Optionally, the filtering declaration is described using semantic tags and does not directly manipulate the entity mask; wherein, the filtering declaration includes: A whitelist declaration for physical objects indicates that physical collisions will only occur with entities whose tags are listed. A blacklist declaration for physical objects indicates that physical collisions will not occur with entities listed in the tagged list; A whitelist declaration used for regions indicates that only entities with the listed tags will be detected; A blacklist declaration used for regional entities indicates that entities with the listed tags will not be detected.

[0016] Optionally, for entities that have declared a whitelist, the collision mask is the bitwise OR of the corresponding bit values ​​of all tags listed in the whitelist; for entities that have declared a blacklist, the collision mask is the bitwise AND NOT of the all-1 mask and the corresponding bit values ​​of all tags listed in the blacklist. The whitelist includes a whitelist for physical entities and / or a whitelist for regional entities, and the blacklist includes a blacklist for physical entities and / or a blacklist for regional entities.

[0017] Optionally, the bidirectional forced propagation process further includes: when, after the loading period, the label of a dynamically generated new entity is referenced by the blacklist declaration of an already loaded entity, during the loading process of the new entity, querying the declaration of the already loaded entity and automatically modifying the corresponding collision mask, wherein the blacklist declaration includes blacklist declarations for physical entities and / or blacklist declarations for region entities.

[0018] Optionally, when the number of semantic tags exceeds a preset number of bits, the tag bit registry, collision layer, and collision mask use a bit set data structure.

[0019] Optionally, before the step of obtaining the configuration declaration and tags of the game entity, the method further includes: During game loading, the configuration declarations of all entities are checked for integrity. The integrity check includes at least one of the following: tag existence, event handling component pairing, layer broadcasting, and listener closure. If the check fails, the entity's operation is blocked.

[0020] Optionally, the integrity check includes at least one of the following rules: Collision mask reference target rules: the semantic tags referenced in the declaration must have been defined; Isolated collision layer rules: Check if there are tags that are only broadcast by the collision layer but not listened to by any entity collision mask; The rule that a region body cannot detect other regions body states prevents a region body from declaring that it can detect other regions body states.

[0021] Optionally, the tag bit registry stores the mapping between tag strings and bit indices through a hash table, and assigns auto-incrementing bit indices according to the order in which the tags first appear.

[0022] Secondly, embodiments of this disclosure also provide an electronic device, the electronic device comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the semantic tag-driven game entity collision filtering method described in any of the first aspects.

[0023] Thirdly, embodiments of this disclosure also provide a computer-readable storage medium storing computer instructions for causing a computer to perform the semantic tag-driven game entity collision filtering method described in any of the first aspects.

[0024] The semantic tag-driven game entity collision filtering method provided by this invention generates corresponding bit values ​​for semantic tags through a tag bit registry, thereby automatically converting semantic tags into bits. The collision layer and collision mask of game entities are calculated by configuring declarations and the tag bit registry, and entities with overlapping tags in the declaration are processed through bidirectional forced propagation. This achieves bidirectional propagation through unilateral declarations, thereby reducing errors and improving performance in game collision simulation.

[0025] The filtering statement distinguishes between physical objects and region objects, further improving performance. Attached Figure Description

[0026] The above and other objects, features and advantages of this disclosure will become more apparent from the accompanying drawings, in which like reference numerals generally denote like parts.

[0027] Figure 1 A flowchart of a semantic tag-driven game entity collision filtering method provided in an embodiment of this disclosure; Figure 2 A flowchart of the mask solving algorithm provided in this embodiment of the disclosure; Figure 3 This is a schematic block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0028] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0029] It should be understood that the following specific examples illustrate the implementation of this disclosure, and those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific implementation methods, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0030] It should be noted that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice method. Furthermore, this device and / or practice method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0031] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The illustrations only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0032] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0033] Bitwise operations refer to comparing the binary representations of two integers bit by bit. In collision filtering scenarios, the two integers involved in the operation are the collision layer and the collision mask, with each bit representing a semantic label layer (e.g., bit 1 = "player" layer, bit 2 = "enemy" layer). The rule for bitwise AND operations is: the result is 1 only if both numbers are 1 in the same binary bit; otherwise, it is 0. Bitwise OR operations are the same as binary OR and NAND operations.

[0034] Physics engines for both 3D and 2D games (such as Bullet, PhysX, and Godot Physics) uniformly use collision layers and collision masks to pre-filter collisions based on the width of the axis-aligned bounding box. Collision layer: The layer on which this entity broadcasts is located. It is a 32-bit integer, with each bit representing one layer. Collision mask: This entity listens on the layer and is another 32-bit integer; Two entities A and B come into physical contact if and only if the bitwise AND of the layer of entity A with the mask of entity B is non-zero, and the bitwise AND of the layer of entity B with the mask of entity A is also non-zero.

[0035] This embodiment proposes a purely declarative, zero-bit operation, bidirectional consistent configuration method to solve four technical problems exposed by the prior art: Question 1: Cognitive burden and error rate of manual bitmasks: In game engines (Unity, Unreal, Godot), the collision relationships between entities are represented by 16-bit or 32-bit integer collision layers and collision masks. Developers must remember semantically meaningless mappings such as "the 3rd bit is the enemy, the 5th bit is the bullet," and global bit allocation must be coordinated every time a new entity type is added. The probability of error in manual bit manipulation increases approximately quadratically with the number of entity types.

[0036] Question 2: Unilateral declarations are difficult to maintain bidirectional consistency. In Unity, Unreal Engine, and Godot, collision filtering is a two-sided setting: if you want "bullets to pass through friendly units," developers must configure both the bullet's mask to exclude friendly units and the friendly units' masks to exclude bullet units. If either side is omitted, the physics engine's behavior is undefined—the bullet may still trigger a friendly unit collision callback, or vice versa.

[0037] Question 3: Not friendly to games generated during AI or player runtime: When a new game is generated at runtime by a player or a large language model, global protocols such as "which position to assign to which tag" cannot be maintained across UGC sessions. Manual bit protocols are inherently incompatible with UGC scenarios.

[0038] Question 4: Confusion arises from the mixed use of filtering semantics between region bodies (triggers) and physical bodies: Regions aim to "detect" certain entities without creating physical obstructions, while physical objects aim to "physically collide" with certain entities. Existing engines cram both types of semantics into the same pair of layers and mask integers, causing repeated errors in engineering practice regarding issues such as "which declaration should be used for the region," "filtering direction," and "whether they can appear simultaneously."

[0039] This embodiment proposes a technical approach that addresses the limitations of existing technologies in achieving "automatic conversion of semantic tags to bits during loading, addition of one-sided declarations for bidirectional propagation, and addition of semantic differentiation between physical entities and region entities".

[0040] The method in this embodiment can achieve the following objectives: (a) Users (developers or AI) can complete all collision configurations by declaring semantic tags (such as enemies, players) without manipulating any bits; (b) The mapping of tags is completed automatically inside the engine, and is established once during the loading period. The entire mapping is completed during the loading period with zero overhead and zero errors at runtime. (c) Supports two types of declarations: whitelist (whitelist fields collides_with and detect) and blacklist (blacklist fields pass_through and ignore), which exist mutually exclusively; (d) One-sided declarations are automatically propagated bidirectionally to the other entity, ensuring that the bitwise AND result of the layers and masks on both sides is non-zero at the same time. Only one-sided declarations are required, and the engine automatically maintains bidirectional consistency. (e) Physical bodies and region bodies use different keywords. Physical bodies use collides_with and pass_through, while region bodies use detect and ignore. This distinguishes the semantics at the syntactic level. Region bodies and physical bodies use different but isomorphic declaration keywords, making them clear to each other. (f) Load-time integrity check intercepts all contradictions and dead references before runtime.

[0041] like Figure 1 As shown, this embodiment discloses a semantic tag-driven game entity collision filtering method, including: During game loading, a tag bit registry is established and maintained. The tag bit registry is used to dynamically map the first occurrence of a semantic tag string to a unique bit index in sequence and generate the corresponding bit value. Obtain the configuration declaration and tags of the game entity, wherein the configuration declaration includes the entity's body type and filtering declaration; During game loading, based on the body type, tag, and filter declaration of the game entity, the collision layer and collision mask of the game entity are automatically calculated by querying the tag registry. During game loading, a bidirectional forced propagation process is performed. This process includes automatically modifying the collision mask of the second entity when the first entity filter declaration contains a tag of the second entity. This is done to eliminate the broadcast bit in the collision layer of the first entity, ensuring that the bitwise AND operation between the collision layer of the first entity and the mask of the second entity, and the bitwise AND operation between the collision layer of the second entity and the collision mask of the first entity, are both zero. This ensures that collision detection between the first entity and the second entity is bidirectionally disabled, thereby obtaining the modified collision layer and collision mask of the game entity. The modified collision layers and collision masks of game entities are submitted to the physics engine, thereby achieving zero-overhead collision filtering during game runtime.

[0042] The tag registry internally maintains two pieces of data: a hash map of semantic tag strings to bit index integers; and a counter that records the next available bit index, initially set to 2.

[0043] Tag bit registry specification: Bit index 1 is reserved for the shared physical layer (such as the environment); Bit indices 2 to 32 are allocated in the order of their first appearance; exceeding 32 bits: a warning is recorded, and new tags return 0 (without affecting already allocated tags); the bit order does not depend on the order of the declaration files, but only on the loading order, and is stable after loading is determined.

[0044] The tag positioning function takes a semantic tag string. If the string is empty, it returns 0. Otherwise, it searches for the tag in the mapping table. If found, it returns the result of shifting 1 left (bit index minus 1) bits. This search takes constant time. If not found and the next available bit index exceeds 32, it records a warning that the collision layer bits have been exhausted (maximum 32) and returns 0. Otherwise, it takes the current available bit index, increments the counter, stores the tag to the new bit index in the mapping table, and then returns the result of shifting 1 left (new bit index minus 1) bits.

[0045] The tag set to mask function takes an array of tags, calls the tag bit-to-bit function for each tag in turn and performs bitwise OR and accumulation, and finally returns the combined 32-bit mask.

[0046] The filtering declarations are described using semantic tags and do not directly manipulate entity masks; the filtering declarations are shown in Table 1: Table 1. Filter Declaration Keyword List Filter declaration mutual exclusion constraints: collides_with and pass_through cannot appear simultaneously on the same entity; detect and ignore cannot appear simultaneously on the same entity; collides_with and pass_through and detect and ignore are also mutually exclusive across keywords (because they are bound to different entity types).

[0047] Mutual exclusion is handled by loading period rules. Collision events must have a collision component and a region body that cannot be detected, etc., as a prerequisite verification guarantee.

[0048] Optionally, for entities that have declared a whitelist, the collision mask is the bitwise OR of the corresponding bit values ​​of all tags listed in the whitelist; for entities that have declared a blacklist, the collision mask is the bitwise AND NOT of the all-1 mask and the corresponding bit values ​​of all tags listed in the blacklist. The whitelist includes a whitelist for physical entities and / or a whitelist for regional entities, and the blacklist includes a blacklist for physical entities and / or a blacklist for regional entities.

[0049] The bidirectional forced propagation process also includes: when, after the loading period, the label of a dynamically generated new entity is referenced by the blacklist declaration of an already loaded entity, during the loading process of the new entity, querying the declaration of the already loaded entity and automatically modifying the corresponding collision mask, wherein the blacklist declaration includes blacklist declarations for physical entities and / or blacklist declarations for region entities.

[0050] Specifically, the mask solving algorithm is as follows: Figure 2 As shown, for each entity E, the loading process solves for its "collision layer and collision mask" pair using the following steps: Symmetry: When pass_through is specified, the engine guarantees that the layer of entity A and the mask of entity B are bitwise ANDed, and the layer of entity B and the mask of entity A are bitwise ANDed and both result in zero.

[0051] Later entities can also trigger this: If entity B is loaded first (entity E declares a pass_through to entity B), and then entity A is loaded (without declaring any filtering), there are two implementations. In this embodiment, when entity E is loaded, the "existing entity B" is traversed and modified in reverse. If entity B is generated after entity E is loaded, then the already loaded declaration library needs to be queried and supplemented in the loading process of entity B.

[0052] The region volume mask solving branch, for entities of volume type region volume, specifically includes the following steps: Step 1: Extract the bit corresponding to its own semantic tag; Step 2: Set the initial mask value to all 1s (default is to check all); Step 3: If detect is not empty, the mask is taken from the corresponding bit or set of the whitelist tag set (whitelist); otherwise, if ignore is not empty, the corresponding bit or set of the blacklist set is taken as the exclusion bit, and the mask is bitwise with its complement (blacklist). Step 4: No bidirectional propagation (the region is passively detected and the detected entity is not modified in reverse); Step 5: Submit the layer and mask to the physical backend.

[0053] The region does not propagate bidirectionally because the trigger does not change the physical behavior of the detected entity; it only reads the mask on its own side for event filtering.

[0054] The triggering conditions for bidirectional propagation can be extended to a combination of blacklist and whitelist: if entity A declares that the whitelist field collides_with only contains entity B, the engine can also infer that entity A is decoupled from the mask bits of all non-B entities.

[0055] During game loading, the configuration declarations of all entities are checked for integrity. The integrity check includes at least one of the following: tag existence, event handling component pairing, layer broadcasting, and listener closure. If the check fails, the entity's operation is blocked.

[0056] Each rule independently queries the pre-indexed inspection context (formerly known as LintContext), and immediately blocks execution if loading fails. The specific rules are shown in Table 2. Table 2, Rule Explanation Table Blueprints refer to the visual scripting system in Unreal Engine. Configurations that fail to load are prevented from entering runtime, thus avoiding the discovery of misaligned rules during runtime.

[0057] The following are typical forms of configuration declarations in this embodiment: Player character: Only declares the body type as a character body, without declaring any filtering keywords; the effect is that it will collide with all entities by default.

[0058] Rigid body bullet: The body type is rigid body, and the whitelist field collides_with lists two tags: enemy and wall; the effect is that it only collides with these two tags and passes through all other entities (including friendly forces).

[0059] Rigid Body Cart: The body type is rigid body, and the blacklist field pass_through lists the walls; the effect is that it collides with all entities except walls.

[0060] Region trigger (whitelist): The body type is region body, and the whitelist field detect lists players; the effect is to trigger entry and exit events only for players.

[0061] Region trigger (blacklist): The body type is a region body, and the blacklist field ignore lists the items; the effect is to detect all entities except items.

[0062] Table 3 shows a comparison of the complexity of this embodiment with existing technologies. Table 3. Comparison of Declaration Complexity Correctness comparison: Unity and Godot: One-sided declarations lead to asymmetric bidirectional behavior (ambiguity in the semantics of physics blocking and detection callbacks), resulting in actual game defects.

[0063] In this embodiment: a single-sided declaration is made, and the engine simultaneously modifies the mask on the other end. The physics engine observes a perfectly symmetrical layer and mask pair with no inconsistency windows.

[0064] Runtime performance comparison: Unity and Godot: Perform two bitwise AND comparisons between the layer and the mask at runtime, with both masks being assembled at runtime.

[0065] In this embodiment, all masks are calculated and written to the physical backend during loading. The runtime is completely equivalent to the native engine (with the same two bitwise AND operations), introducing no additional overhead.

[0066] Error Pre-context Comparison: Using 100 AI-generated UGC games as a sampling unit, common error types can be intercepted by the loading period rules in this embodiment, as shown in Table 4. Table 4. Error Comparison Table The terminology used in this embodiment is explained in Table 5. Table 5. Glossary of Terms The runtime performance of this embodiment is completely equivalent to that of the native engine (there is no additional overhead during runtime after the loading period is completed). The advantages of this embodiment are mainly in terms of declaration complexity, correctness, and UGC friendliness, rather than runtime speed.

[0067] This embodiment has the following effects: 1. Declaration Level: Developers or AI only need to use semantic tags such as "player" and "enemy" for declaration, without needing to understand or manipulate the underlying bitmask. The unique mapping and allocation of tags to binary bits is automatically completed during loading through the tag bit registry.

[0068] 2. Consistency Guarantee: When entity A expresses filtering relationships through a one-sided declaration (such as using a blacklist pass_through: "friendly forces"), the engine will automatically find and modify the collision masks of all related entities B through a bidirectional forced propagation algorithm, ensuring that the "layer-mask" pairs obtained by the physics engine are completely symmetrical, thereby eliminating the inconsistency in behavior caused by omissions in the two-sided configuration from a mechanism perspective.

[0069] 3. Error Prevention and Performance: The entire mapping, calculation, and propagation process is completed during loading and undergoes strict integrity checks, thus intercepting configuration errors before runtime. Once at runtime, the physics engine directly uses the calculated integer values, achieving zero additional overhead.

[0070] 4. Precise Semantic Distinction: By designing different keyword pairs (collides_with / pass_through and detect / ignore) for physical objects (participating in physical collisions) and region objects (only triggering detection events), the semantics of "physical obstruction" and "overlap detection" are distinguished from the source of syntax, avoiding intent confusion and further improving the accuracy and maintainability of configuration.

[0071] The bit index allocation strategy in this embodiment can adopt the following scheme: Assignment is based on the remainder of the hash of the tag string. This simplifies runtime, but may cause conflicts.

[0072] The label is explicitly specified in the external configuration file. Suitable for cross-version scenarios requiring stable bit protocols.

[0073] When the number of semantic tags exceeds a preset number of bits, the tag bit registry, collision layer, and collision mask use a bit set data structure.

[0074] When the bit index exceeds 32, it is automatically upgraded to 64-bit (bit set or two 32-bit integers). Suitable for large-scale UGC scenarios.

[0075] Sparse bit sets (sparse bitmaps, such as the compressed bitmap structure commonly used in the industry). Suitable for scenarios where the number of tags is much greater than 32 and the actual usage is sparse.

[0076] The following schemes can be used to trigger bidirectional propagation: When entity A is loaded, the already loaded entities are scanned; when entity B is newly loaded, the declaration library is rescanned for completion.

[0077] After the loading period is complete, a global scan is performed to align all layers and mask pairs at once.

[0078] Separate the declaration from the application. During the loading phase, only the filtering relationship of each pair of tags is recorded, and the specific layer and mask are calculated when the entity is instantiated.

[0079] The syntax for whitelists and blacklists can be implemented using the following methods: Using a single filter object with an enumeration field of pattern whitelist or blacklist is equivalent to the two pairs of keywords in this embodiment.

[0080] A third type of keyword that allows one-way movement is introduced (entity A can collide with entity B, but entity B cannot collide with entity A), covering more asymmetric physics rules (such as ghosts passing through walls in one direction).

[0081] The following methods can be used to distinguish entity types: Static binding to the body type field (character body, rigid body, static body, region body).

[0082] By explicitly distinguishing between independent component detectors and colliders, keywords no longer have type prefixes.

[0083] For multimodal entities (with both physical contact and detection areas), two sets of keywords are allowed to be declared for the same entity.

[0084] The verification rules can adopt the following schemes: The nine independent rules were changed to global constraints based on the SMT solver.

[0085] The number of rules can be increased or decreased, but the core requirement is to ensure that there are no dead references and no self-contradictions.

[0086] In existing technologies, such as Unity, Unreal, and Godot, bilateral manual declarations are required. This embodiment eliminates the redundancy of bilateral manual declarations during the loading period by using bidirectional propagation processing of unilateral declarations.

[0087] The electronic device disclosed in this embodiment includes a memory and a processor. The memory is used to store non-transitory computer-readable instructions. Specifically, the memory may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may, for example, include random access memory (RAM) and / or cache memory. The non-volatile memory may, for example, include read-only memory (ROM), hard disk, flash memory, etc.

[0088] The processor may be a central processing unit (CPU) or other processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device to perform desired functions. In one embodiment of this disclosure, the processor is used to execute computer-readable instructions stored in the memory, causing the electronic device to perform all or part of the steps of the semantic tag-driven game entity collision filtering method of the foregoing embodiments of this disclosure.

[0089] Those skilled in the art will understand that, in order to solve the technical problem of how to achieve a good user experience, this embodiment may also include well-known structures such as communication buses and interfaces, and these well-known structures should also be included within the protection scope of this disclosure.

[0090] like Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. It illustrates a structural schematic diagram suitable for implementing the electronic device in the embodiment of the present disclosure. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0091] like Figure 3 As shown, an electronic device may include a processing unit (such as a central processing unit, graphics processing unit, etc.) that can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) or a program loaded from a storage device into random access memory (RAM). The RAM also stores various programs and data required for the operation of the electronic device. The processing unit, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0092] Typically, the following devices can be connected to the I / O interface: input devices, such as sensors or visual information acquisition devices; output devices, such as displays; storage devices, such as magnetic tapes or hard drives; and communication devices. Communication devices allow electronic devices to exchange data wirelessly or via wired communication with other devices, such as edge computing devices. Although Figure 3 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0093] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device, or installed from a ROM. When the computer program is executed by a processing device, all or part of the steps of the semantic tag-driven game entity collision filtering method of embodiments of this disclosure are performed.

[0094] For a detailed description of this embodiment, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.

[0095] A computer-readable storage medium according to embodiments of the present disclosure stores non-transitory computer-readable instructions. When these non-transitory computer-readable instructions are executed by a processor, all or part of the steps of the semantic tag-driven game entity collision filtering method of the foregoing embodiments of the present disclosure are performed.

[0096] The aforementioned computer-readable storage media include, but are not limited to: optical storage media (e.g., CD-ROM and DVD), magneto-optical storage media (e.g., MO), magnetic storage media (e.g., magnetic tape or portable hard drive), media with built-in rewritable non-volatile memory (e.g., memory card), and media with built-in ROM (e.g., ROM cartridge).

[0097] For a detailed description of this embodiment, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.

[0098] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0099] In this disclosure, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The block diagrams of devices, apparatuses, devices, and systems involved in this disclosure are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as "comprising," "including," "having," etc., are open-ended terms meaning "including but not limited to," and are used interchangeably with them. The terms "or" and "and" as used herein refer to the terms "and / or," and are used interchangeably with them unless the context clearly indicates otherwise. The term "such as" as used herein refers to the phrase "such as but not limited to," and is used interchangeably with it.

[0100] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.

[0101] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.

[0102] Various changes, substitutions, and modifications can be made to the techniques described herein without departing from the teachings defined in this embodiment. Furthermore, the scope of this embodiment is not limited to the specific aspects of the processes, machines, manufacturing processes, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufacturing processes, events, means, methods, or actions that perform substantially the same functions or achieve substantially the same results as the corresponding aspects described herein can be utilized. Therefore, this embodiment includes such processes, machines, manufacturing processes, events, means, methods, or actions within its scope.

[0103] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0104] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A semantically labeled game entity collision filtering method, characterized in that, include: During game loading, a tag bit registry is established and maintained. The tag bit registry is used to dynamically map the first occurrence of a semantic tag string to a unique bit index in sequence and generate the corresponding bit value. Obtain the configuration declaration and tags of the game entity, wherein the configuration declaration includes the entity's body type and filtering declaration; During game loading, based on the body type, tag, and filter declaration of the game entity, the collision layer and collision mask of the game entity are automatically calculated by querying the tag registry. During game loading, a bidirectional forced propagation process is performed. This process includes automatically modifying the collision mask of the second entity when the first entity filter declaration contains a tag of the second entity. This is done to eliminate the broadcast bit in the collision layer of the first entity, ensuring that the bitwise AND operation between the collision layer of the first entity and the mask of the second entity, and the bitwise AND operation between the collision layer of the second entity and the collision mask of the first entity, are both zero. This ensures that collision detection between the first entity and the second entity is bidirectionally disabled, thereby obtaining the modified collision layer and collision mask of the game entity. The modified collision layers and collision masks of game entities are submitted to the physics engine, thereby achieving zero-overhead collision filtering during game runtime.

2. The semantic tag-driven game entity collision filtering method according to claim 1, characterized in that, The filtering declaration is described using semantic tags and does not directly manipulate entity masks; wherein, the filtering declaration includes: A whitelist declaration for physical objects indicates that physical collisions will only occur with entities whose tags are listed. A blacklist declaration for physical objects indicates that physical collisions will not occur with entities listed in the tagged list; A whitelist declaration used for regions indicates that only entities with the listed tags will be detected; A blacklist declaration used for regional entities indicates that entities with the listed tags will not be detected.

3. The semantic tag-driven game entity collision filtering method according to claim 2, characterized in that, For entities that have declared a whitelist, their collision mask is the bitwise OR of the corresponding bit values ​​of all tags listed in the whitelist; for entities that have declared a blacklist, their collision mask is the bitwise AND NOT of the all-1 mask and the corresponding bit values ​​of all tags listed in the blacklist. The whitelist includes a whitelist for physical entities and / or a whitelist for regional entities, and the blacklist includes a blacklist for physical entities and / or a blacklist for regional entities.

4. The semantic tag-driven game entity collision filtering method according to claim 2, characterized in that, The bidirectional forced propagation process further includes: when, after the loading period, the label of a dynamically generated new entity is referenced by the blacklist declaration of an already loaded entity, during the loading process of the new entity, querying the declaration of the already loaded entity and automatically modifying the corresponding collision mask, wherein the blacklist declaration includes blacklist declarations for physical entities and / or blacklist declarations for region entities.

5. The semantic tag-driven game entity collision filtering method according to claim 2, characterized in that, When the number of semantic tags exceeds a preset number of bits, the tag bit registry, collision layer, and collision mask use a bit set data structure.

6. The semantic tag-driven game entity collision filtering method according to claim 1, characterized in that, Before the step of obtaining the configuration declaration and tags of the game entity, the method further includes: During game loading, the configuration declarations of all entities are checked for integrity. The integrity check includes at least one of the following: tag existence, event handling component pairing, layer broadcasting, and listener closure. If the check fails, the entity's operation is blocked.

7. The semantic tag-driven game entity collision filtering method according to claim 6, characterized in that, The integrity verification includes at least one of the following rules: Collision mask reference target rules: the semantic tags referenced in the declaration must have been defined; Isolated collision layer rules: Check if there are tags that are only broadcast by the collision layer but not listened to by any entity collision mask; The rule that a region body cannot detect other regions body states prevents a region body from declaring that it can detect other regions body states.

8. The semantic tag-driven game entity collision filtering method according to claim 1, characterized in that, The tag bit registry stores the mapping between tag strings and bit indices through a hash table, and assigns auto-incrementing bit indices according to the order in which the tags first appear.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the semantic tag-driven game entity collision filtering method according to any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to perform the semantic tag-driven game entity collision filtering method as described in any one of claims 1-8.