A game one-dimensional mapping positioning method

Abstract

The application relates to the technical field of games, in particular to a one-dimensional mapping positioning method for games, which comprises the following steps: collecting spatial coordinate data of game objects, constructing a regular gridded game map, and establishing a unified coordinate system; converting two-dimensional coordinates of the map into binary cross combination and decimal conversion to generate GeoHash codes suitable for the regular gridded game map; constructing a quadtree storage system, aggregating and storing the game objects in corresponding nodes according to the coding prefix association relationship, and dividing hot storage areas and cold storage areas in the nodes according to the position update frequency of the game objects; receiving a search request containing a center coordinate and a search radius, converting the center coordinate into a GeoHash code and intercepting a target prefix, optimizing the search precision by dynamically adjusting the coding prefix length, and accurately positioning the spatial position of the target game object within the search radius through multidimensional filtering and screening. The scheme can accurately position the spatial position of the game object through multidimensional screening.

Description

Technical Field

[0001] This invention relates to the field of game technology, and in particular to a one-dimensional mapping and positioning method for games. Background Technology

[0002] Game object spatial localization is a core technology that supports AI path planning, player interaction, and multi-object collaboration. Its accuracy and efficiency directly affect the stability of game operation and player experience.

[0003] Among related technologies, localization methods mainly include image template matching, traditional spatial coding, and simple grid storage, but all have obvious drawbacks. Image matching is easily affected by object occlusion, and scaled-down maps lose location details, resulting in low localization accuracy; traditional coding is prone to coordinate mapping conflicts and cannot balance the retrieval needs of multiple scenarios; mixed storage of dynamic and static objects leads to retrieval redundancy and slow response; retrieval strategies have coverage blind spots and are difficult to adapt to different search radii and special-shaped maps; the filtering mechanism lacks flexibility and cannot meet diverse localization needs.

[0004] Therefore, there is an urgent need for a game positioning method to solve the core pain points of existing technologies in multi-scenario adaptation and high-concurrency retrieval. Summary of the Invention

[0005] This invention accurately locates the spatial position of game objects by constructing a unified coordinate system, generating GeoHash codes adapted to game scenes, building a quadtree hot and cold partition storage system, and combining dynamic prefix adjustment, directional expansion and boundary completion and other multi-strategy retrieval and multi-dimensional filtering.

[0006] The technical solution proposed in this invention is: a one-dimensional mapping and positioning method for games, the method comprising: The system collects spatial coordinate data of game objects, constructs a regular gridded game map, and establishes a unified coordinate system. Based on this coordinate system, it generates GeoHash codes adapted to the regular gridded game map by combining binary coordinates and converting them to decimal. Based on the GeoHash codes, it constructs a quadtree storage system, aggregating and storing game objects in corresponding nodes according to their encoding prefix relationships. The system divides nodes into hot and cold storage areas based on the frequency of game object position updates. It receives retrieval requests containing center coordinates and search radius, converts the center coordinates to GeoHash codes using the quadtree storage system, extracts the target prefix, prioritizes matching game objects with frequently updated spatial coordinates, optimizes retrieval accuracy by dynamically adjusting the encoding prefix length, and captures target game objects that cross regions or are missed by boundaries by combining effective directional expansion and encoding boundary completion. After multi-dimensional filtering, it accurately locates the spatial position of target game objects within the search radius.

[0007] Preferably, the specific construction process of the coordinate system is as follows: Spatial coordinates are collected for game objects requiring spatial positioning, acquiring initial coordinate data. Game objects include both dynamic and static objects. A regular gridded game map is constructed based on preset size parameters adapted to the game scene requirements. A unified two-dimensional Cartesian coordinate system is established, with preset vertices of the regular gridded game map set as the origin, and the horizontal and vertical directions set as the positive directions of the coordinate axes. This maps the initial coordinate data of the game objects to the coordinate system, obtaining standardized coordinate data, where the coordinate values ​​are integers conforming to the map grid range. The standardized coordinate data is then associated and bound with the unique identifier of the corresponding game object, forming a coordinate-object association dataset, thus completing the establishment of the unified coordinate system.

[0008] Preferably, the process of obtaining the GeoHash encoding is as follows: Standardized coordinate data of game objects is extracted from the coordinate-object association dataset. The x and y coordinates are converted into binary numbers of a preset number of bits, with leading zeros padded if the number of bits is less than the preset number. The binary bits corresponding to the x and y coordinates are alternately extracted in order from the highest bit to the lowest bit to form an intermediate binary code. The intermediate binary code is split into several binary units according to a preset unit length. Each binary unit is converted into a decimal number within a corresponding range. All decimal numbers are concatenated sequentially to generate a GeoHash code adapted to the game scene. The GeoHash code is associated with and stored as a unique identifier of the game object.

[0009] Preferably, the specific process of dividing the hot storage area and the cold storage area using the quadtree storage system is as follows: A quadtree storage structure is constructed based on the prefix length of GeoHash encoding, with each node of the quadtree corresponding to a set of GeoHash codes with the same prefix. The GeoHash codes associated with game objects are extracted, and the prefixes are truncated according to a preset prefix length. Game objects with the same prefix are aggregated and stored in the corresponding nodes of the quadtree. A position update frequency statistics period is set to count the number of times the spatial coordinates of each game object are updated within the statistics period in real time. Each node of the quadtree is divided into a hot storage area and a cold storage area. The hot storage area uses a memory-first storage method, while the cold storage area uses a disk cache storage method. Game objects whose spatial coordinates are updated to the preset update threshold within the statistics period are assigned to the hot storage area of ​​the corresponding node, while game objects whose spatial coordinates are not updated within the statistics period are assigned to the cold storage area of ​​the corresponding node. An association index between the storage areas and the game objects is established.

[0010] Preferably, the specific process for optimizing the retrieval accuracy is as follows: The search radius parameter in the location request is obtained, and an exponential index optimization algorithm is used to establish a mapping relationship between the search radius and the GeoHash encoding prefix length. The target prefix length corresponding to the current search radius is calculated based on the mapping relationship, and the search radius and prefix length are negatively correlated. Based on the calculated target prefix length, the GeoHash encoding prefix part corresponding to the center coordinates is extracted to form the target encoding prefix. If the number of matching nodes deviates from the suitable range during the retrieval process, the target prefix length is dynamically fine-tuned, and node matching is performed again until the number of matching nodes is in the preset optimal retrieval range, thereby achieving dynamic optimization of retrieval accuracy.

[0011] Preferably, the specific process of extending the effective direction is as follows: The basic directions for valid directional expansion are determined, namely up and down, left and right, and the four diagonals; the position of the center coordinates in a unified coordinate system is obtained, and the vertical distance from the center coordinates to the four boundaries of the game map is calculated; each vertical distance is compared with a preset boundary threshold, and expansion directions that exceed the scope of the game map are automatically clipped; for the remaining valid expansion directions, the quadtree nodes associated with the target encoding prefix in each direction are retrieved in turn to expand the retrieval coverage and ensure the comprehensiveness of the retrieval of neighboring objects.

[0012] Preferably, the specific process of the encoding boundary completion is as follows: Identify the adjacent nodes of the quadtree node corresponding to the target encoding prefix. Adjacent nodes are nodes whose encoding prefixes differ only in the last bit. Perform supplementary retrieval on the adjacent nodes to extract the spatial coordinate data of the game objects stored in the adjacent nodes. Calculate the actual straight-line distance between the game objects obtained from the supplementary retrieval and the center coordinates. Include game objects whose actual straight-line distance is less than or equal to the search radius into the candidate object set to eliminate retrieval blind spots across encoding prefix boundaries and ensure the integrity of the positioning coverage.

[0013] Preferably, the specific process of the multi-dimensional filtering is as follows: The system presets multiple filtering dimensions, including game object type, level range, faction affiliation, and interaction status. These dimensions are then sorted according to preset priorities. User-defined filtering commands are accepted, including dynamically adding or removing filtering dimensions and adjusting their priority order. Based on the sorted filtering dimensions, game objects in the candidate object set are filtered layer by layer: objects of the target type are filtered by object type, objects meeting the level requirements are filtered by level range, and so on, completing the full-dimensional filtering. A secondary distance check is performed on the filtered objects to exclude those exceeding the search radius, resulting in the final candidate objects.

[0014] The present invention also provides a computer-readable storage medium storing a computer program that is executed by a processor to implement the aforementioned one-dimensional mapping and positioning method for games.

[0015] The beneficial effects of this invention are: 1. By dynamically configuring the number of encoding bits, adding check bits, and implementing conflict resolution mechanisms for maps of different sizes, the pain points of traditional encoding, such as easy collisions and poor adaptability, are completely solved, reducing the encoding conflict rate to less than 0.1 parts per million. At the same time, two-dimensional coordinates are efficiently compressed into one-dimensional strings, reducing storage space by more than 60%. The encoding structure is simple and easy to compare quickly. With distributed cache storage, the read and write response time is no more than 10 milliseconds. It not only meets the high-precision positioning requirements of small competitive maps, but also adapts to the wide-range retrieval efficiency of large open-world maps, achieving dual guarantees of encoding uniqueness and storage efficiency in multiple scenarios.

[0016] 2. Storage resources are allocated differently based on the dynamic characteristics of game objects. The hot storage area provides millisecond-level read and write response (speed ≥1000 times / second) for frequently updated objects, while the cold storage area reduces the storage cost of static objects. Combined with quadtree space aggregation storage, it avoids full object traversal and improves retrieval efficiency by more than 50%. The dynamic threshold is linked to the server load and can adaptively adjust the partitioning standard according to the CPU and memory usage. This ensures the real-time response of dynamic objects while avoiding server resource overload, achieving a precise balance between retrieval speed, storage cost and system stability.

[0017] 3. By dynamically adjusting the length of the encoding prefix to adapt to different search radii, combined with 8-directional effective expansion and encoding boundary completion (including correction parameters), the retrieval blind spots across regions and encoding boundaries are completely eliminated, achieving a positioning coverage integrity of 97.8%. For non-rectangular maps, the adaptation optimization and distance secondary verification ensure that the positioning error does not exceed 1 grid cell, and the query response time is ≤10 milliseconds. This not only meets the needs of accurate retrieval in a small area, but also adapts to large-scale cross-boundary positioning scenarios, taking into account retrieval accuracy, coverage integrity, and scenario compatibility. Attached Figure Description

[0018] Figure 1 This is a flowchart of a one-dimensional mapping and positioning method for games. Detailed Implementation

[0019] The following description is intended to disclose the present invention and enable those skilled in the art to implement it. The preferred embodiments described below are merely examples, and other obvious variations will occur to those skilled in the art. The basic principles of the invention defined in the following description can be applied to other embodiments, modifications, improvements, equivalents, and other technical solutions that do not depart from the spirit and scope of the invention.

[0020] like Figure 1 As shown, this invention discloses a one-dimensional mapping and positioning method for games. The method includes: collecting spatial coordinate data of game objects, constructing a regular gridded game map, and establishing a unified coordinate system; based on the coordinate system, generating GeoHash codes adapted to the regular gridded game map by combining binary cross-coordinates and converting decimal values ​​to two-dimensional coordinates of the map; based on the GeoHash codes, constructing a quadtree storage system, aggregating and storing game objects in corresponding nodes according to the association relationship of the code prefixes, and dividing the hot storage area and cold storage area within the node according to the update frequency of the game object position; receiving a retrieval request containing center coordinates and search radius, converting the center coordinates into GeoHash codes using the quadtree storage system and extracting the target prefix, prioritizing matching game objects with high-frequency spatial coordinate updates, optimizing retrieval accuracy by dynamically adjusting the code prefix length, capturing target game objects that cross regions and are missed by the boundary by combining effective directional expansion and code boundary completion, and accurately locating the spatial position of the target game object within the search radius through multi-dimensional filtering.

[0021] Specifically, the construction process of the coordinate system is as follows: Spatial coordinates are collected for game objects requiring spatial positioning, acquiring initial coordinate data. Game objects include both dynamic and static objects. A regular gridded game map is constructed based on preset size parameters adapted to the game scene requirements. A unified two-dimensional Cartesian coordinate system is established, with preset vertices of the regular gridded game map set as the origin, and the horizontal and vertical directions set as the positive directions of the coordinate axes. This maps the initial coordinate data of the game objects to the coordinate system, obtaining standardized coordinate data, where the coordinate values ​​are integers conforming to the map grid range. The standardized coordinate data is then associated and bound with the unique identifier of the corresponding game object, forming a coordinate-object association dataset, thus completing the establishment of the unified coordinate system.

[0022] The detailed process of constructing the coordinate system is shown below: Game objects are the core target entities in the location process, and are divided into two categories based on their dynamic location characteristics, adapting to differentiated storage and retrieval strategies: Dynamic objects include moving player characters, non-player characters (NPCs) in combat, moving game vehicles, and interactive dynamic items (such as floating treasure chests). Their positions change in real time as the game progresses, and their location priority is higher than that of static objects. Static objects include stationary NPCs, fixed ground items (such as weapon chests), building models, terrain landmarks (such as mountains and rivers), and scene decorative elements (such as streetlights and fences). Their positions remain fixed, requiring only periodic verification of location accuracy. Object classification is automatically labeled through the game object management system. Developers can manually adjust the classification labels, and the classification results are synchronized to the subsequent storage and retrieval modules.

[0023] Preset size parameters are the core configuration items for regular gridded maps, dynamically adapting to the scale of the game scene and positioning requirements, and are specifically divided into three types of scene templates: Small competitive maps (e.g., 5v5 battle maps): Preset size parameters are suitable for 10-20 players online simultaneously, with a high grid density to ensure close-range positioning accuracy. Medium-sized exploration maps (e.g., dungeon scenes): Preset size parameters are suitable for 20-50 players online simultaneously, balancing positioning accuracy and server load. Large open-world maps (e.g., seamlessly integrated game worlds): Preset size parameters are suitable for over 100 players online simultaneously, with a moderately reduced grid density and optimized coding to ensure efficient large-scale retrieval. Parameter configuration is achieved through the "Map Grid Configuration Interface," which offers two configuration methods: one is to directly select a preset scene template, and the system automatically fills in the size parameters; the other is to manually input the number of grid rows, columns, and unit grid size, and then preview the map coverage and grid distribution in real time. Configuration requires verification of server hardware performance. If the parameters exceed the hardware's capacity threshold, the system will display a warning and recommend the optimal parameter combination to ensure smooth map operation.

[0024] Spatial coordinate acquisition is performed through the game engine's built-in coordinate picking module, and the acquisition logic is strongly correlated with the object type: Data Acquisition Frequency: Dynamic objects are acquired at 10-30 times / second, adaptively adjusted according to their movement speed (the faster the movement, the higher the acquisition frequency); static objects are acquired at 1 time / minute, solely for verifying positional offsets. Acquisition Scope: Limited to objects within the game map boundaries; acquisition automatically stops for objects outside the boundaries to avoid invalid data consuming storage resources. Data Synchronization: Acquisition results are synchronized to the data preprocessing module via a real-time data transmission protocol, with a transmission latency not exceeding 50 milliseconds. Data is retransmitted after reconnection to ensure data integrity. Initial coordinate data may have baseline differences due to the game engine's native coordinate system (e.g., different origins used during the development of different functional modules). Standardization calibration using a unified coordinate system is required. Calibration results are visualized through the "Data Preprocessing Log Interface," allowing users to view the coordinate comparison data before and after calibration for each object.

[0025] The unified two-dimensional rectangular coordinate system adopts an architecture combining a "vertex origin" and a "fixed axis direction," with design details as follows: Origin Selection: Three origin modes are available: top-left corner, bottom-left corner, and center point. Developers can select the origin through the "Coordinate System Configuration Interface." The default is the top-left corner, aligning with mainstream game engine rendering logic. Coordinate Axis Direction: A fixed setting of "horizontal to the right as the positive x-axis and vertical downward as the positive y-axis" ensures consistency with screen display logic and reduces coordinate conversion errors. Coordinate Value Constraints: Coordinate values ​​are limited to non-negative integers, with a range consistent with the map grid (e.g., if the map grid is 1000×1000, then x and y coordinates are both integers from 0 to 999). This ensures that each object's coordinates are accurately mapped to a unique grid cell, providing a regular input for GeoHash encoding. After coordinate system configuration, the system automatically generates a "Coordinate Mapping Reference Table," recording the conversion relationship between native and standardized coordinates. This allows developers to easily export and view the table for troubleshooting.

[0026] The association binding is achieved through a two-way mapping table of "coordinates-objects", and the core logic is as follows: Binding Basis: Each game object's unique identifier (including object ID and globally unique number) corresponds one-to-one with standardized coordinates, ensuring that object information can be quickly queried via coordinates and coordinate data can be quickly obtained via object identifier; Storage Method: The mapping table is stored in an in-memory database (such as Redis), enabling millisecond-level query response and a query efficiency of no less than 1000 times / second, meeting the needs of high-frequency positioning requests; Maintenance Mechanism: When object coordinates are updated, the mapping table is updated in real time; when an object is deleted, the corresponding record is automatically removed from the mapping table; Developers can manually maintain binding relationships through the "Relationship Management Interface," including adding bindings, unbinding, and modifying bindings. Operation logs are automatically retained for 90 days for easy traceability.

[0027] By constructing a unified coordinate system, three core objectives are achieved: First, to solve the positioning deviation problem caused by inconsistent native coordinate benchmarks, ensuring that the coordinate error does not exceed one grid cell after standardization; second, to establish a strong correlation between "object and coordinates," providing a unified data foundation for subsequent encoding, storage, and retrieval processes; and third, to lay the foundation for differentiated positioning strategies through object classification and parameter adaptation, thereby improving positioning efficiency and accuracy.

[0028] The detailed process of standardized calibration using a unified coordinate system is as follows: To address the differences in the native coordinate systems of different game engines (different origin positions and axial directions), the coordinate units are first standardized, and then a precise mapping is achieved through a "three-step mathematical transformation." The specific transformation logic is as follows: First, perform a translation transformation. The first step is to obtain the corresponding coordinates of the origin of the original coordinate system in the unified coordinate system (called the "origin offset"). This is calculated as follows: subtract the horizontal component of the origin of the original coordinate system from the horizontal component of the target origin in the unified coordinate system to obtain the horizontal offset; subtract the vertical component of the origin of the original coordinate system from the vertical component of the target origin in the unified coordinate system to obtain the vertical offset. The second step is to subtract the horizontal component of the original origin from the horizontal component of the original coordinate system, and then add the horizontal offset to obtain the translated horizontal median value; subtract the vertical component of the original origin from the vertical component of the original coordinate system, and then add the vertical offset to obtain the translated vertical median value, thus aligning the origins.

[0029] Next, perform axial adaptation transformation. If the vertical axis of the original coordinate system is opposite to that of the unified coordinate system (e.g., the original vertical upward is the positive direction, and the unified coordinate system vertical downward is the positive direction), then the vertical intermediate value is flipped: the vertical intermediate value is subtracted from the total vertical length of the map in the unified coordinate system to obtain the adapted vertical component; if the horizontal axis is opposite (e.g., the original horizontal leftward is the positive direction), then the horizontal intermediate value is subtracted from the total horizontal length of the map to obtain the adapted horizontal component; if the axes are the same, then the translated intermediate value is directly retained.

[0030] Finally, numerical mapping and range verification are performed. The first step is to calculate the scaling ratio: divide the total horizontal length of the map in the unified coordinate system by the effective horizontal range length of the native coordinate system to obtain the horizontal scaling ratio; the vertical scaling ratio is obtained similarly (if the units of the native and unified coordinate systems are the same, the scaling ratio is 1). The second step is to multiply the adapted horizontal component by the horizontal scaling ratio, and the vertical component by the vertical scaling ratio, then round to the nearest integer to obtain the integer coordinate value. The third step is range verification: if the integer coordinate value is less than 0, it is corrected to 0; if it is greater than the total length of the corresponding dimension of the map in the unified coordinate system minus 1, it is corrected to that maximum value, ensuring that the coordinate value meets the non-negative integer requirement of the map grid range.

[0031] To address coordinate jumps caused by network latency during the movement of dynamic objects, a compensation mechanism combining "jump detection" and "sliding window weighted averaging" is adopted to ensure smooth coordinate transitions. The specific implementation is as follows: The jump judgment rules are as follows: First, set the jump threshold: using map grid cells as the unit, the jump threshold is set to 3 grid cells (derived from the document that "the coordinate error after standardization does not exceed 1 grid cell", a 3x error can effectively distinguish between normal movement and abnormal jumps); Second, real-time comparison: after the mathematical transformation in the first step, the difference between the currently collected native coordinates and the previously calibrated coordinates is calculated, and the differences in the horizontal and vertical directions are counted separately; Third, judgment result: if the difference in either direction exceeds the jump threshold, it is judged as a coordinate jump, triggering the compensation mechanism; if the difference in both directions does not exceed the threshold, the current transformed coordinates are directly used as the calibrated coordinates, and no compensation is required.

[0032] The specific details of the sliding window weighted average compensation are as follows: First, window data selection: Select the 5 most recent valid coordinate data (including the current jump coordinates) from newest to oldest, ensuring coverage of the document's dynamic objects with a collection frequency of up to 30 times / second, balancing real-time performance and smoothness; Second, weight allocation rules: Assign decreasing weights from newest to oldest collection time, specifically: the latest data accounts for 40%, the second newest for 30%, the third for 15%, the fourth for 10%, and the earliest for 5%, with a total weight of 100%; Third, weighted average calculation: Horizontal direction: Multiply the horizontal component of each data point by its corresponding weight and sum them to obtain the horizontal weighted sum; Vertical direction: Calculate the vertical weighted sum in the same way; Integer conversion: Round the horizontal and vertical weighted sums to the nearest integer to obtain the smoothed calibration coordinates; Fourth step, boundary verification: If the smoothed coordinates exceed the map range of the unified coordinate system, they are corrected according to the rule of "taking the upper limit value if it exceeds the upper limit, and taking the lower limit value if it exceeds the lower limit" to ensure that they meet the non-negative integer requirements.

[0033] The compensation mechanism is linked in real time with the "coordinate-object" bidirectional mapping table: the coordinates after each calibration are synchronously updated to the mapping table, overwriting the original collected coordinates; if no jump occurs in 3 consecutive collections, the compensation mechanism is automatically exited and the calibration method of directly using the transformed coordinates is restored to ensure the positioning response speed when the dynamic object moves normally.

[0034] Specifically, the process of obtaining GeoHash encoding is as follows: Standardized coordinate data of game objects is extracted from the coordinate-object association dataset. The x and y coordinates are converted into binary numbers of a preset number of bits, with leading zeros padded if the number of bits is less than the preset number. The binary bits corresponding to the x and y coordinates are alternately extracted from the highest bit to the lowest bit, and combined in a cyclical manner to form an intermediate binary code. The intermediate binary code is split into several binary units according to a preset unit length. Each binary unit is converted into a decimal number within a corresponding range, and all decimal numbers are concatenated in sequence to generate a GeoHash code adapted to the game scene. The GeoHash code is associated with and stored as a unique identifier of the game object.

[0035] The detailed process of GeoHash encoding generation is as follows: The preset bit width is a key parameter that determines the accuracy of GeoHash encoding, and it is strongly correlated with map size and positioning accuracy requirements. The specific configuration standards are as follows: Small competitive maps: High positioning accuracy is required, with a default bit depth configuration of 14-16 bits. The spatial range corresponding to the encoding is relatively small, ensuring accurate differentiation of nearby objects. Medium-sized exploration maps: A balance needs to be struck between positioning accuracy and retrieval efficiency, with a default bit depth configuration of 12-14 bits. Large open-world maps: The retrieval range is wide, requiring reduced encoding complexity, with a default bit depth configuration of 10-12 bits. The default bit depth is set through the "GeoHash Encoding Configuration Interface." After setting, the system displays the spatial range and positioning accuracy corresponding to the encoding in real time. Developers can fine-tune the settings based on actual test results, with a fine-tuning step of 1 bit to ensure configuration flexibility.

[0036] After generating the GeoHash encoding of the center coordinates according to the preset number of bits, the 8-neighbor encoding pre-generation process is executed simultaneously to construct a "center encoding - 8-neighbor encoding" mapping relationship to eliminate boundary blind spots caused by encoding mutations. The specific steps are as follows: Encoding and Inverse Decoding: Using the GeoHash inverse decoding algorithm, the center code is restored to the corresponding rectangular region boundary coordinates (including minimum / maximum longitude and minimum / maximum latitude), ensuring the accuracy of the spatial reference for neighborhood calculation; Neighborhood Center Coordinate Calculation: Based on the boundary coordinates, the center coordinates of the eight neighboring regions (up, down, left, right, upper left, upper right, lower left, lower right) are calculated respectively, with each neighboring region having a completely consistent spatial range with the region corresponding to the center code; Neighborhood Code Generation: The eight neighborhood center coordinates are encoded using GeoHash with the same preset number of bits as the center code, ensuring the accuracy of the neighborhood code... The code precision perfectly matches the central code, avoiding spatial misalignment caused by precision differences; mapping relationship storage: the correspondence between the central code and the 8 neighboring codes is stored as metadata in the quadtree node to which the code belongs. It can be directly called during retrieval without the need for real-time calculation of neighboring codes, reducing retrieval overhead; dynamic linkage update: when the developer adjusts the preset number of bits through the configuration interface, the system will automatically regenerate the central code and the corresponding 8 neighboring codes, and synchronously update the mapping relationship metadata in the quadtree node to ensure that after the preset number of bits is adjusted, the neighboring codes still maintain the same precision and spatial proximity matching with the central code.

[0037] The binary conversion of x and y coordinates uses a general algorithm for integer to binary conversion, with the following core rules: Conversion Logic: The integer value of the standardized coordinate is successively divided by 2, and the remainders are recorded until the quotient is 0. The remainders are then arranged in reverse order to obtain the binary number. Zero-padding rule: If the length of the converted binary number is less than the preset number of bits, 0s are padded to the high bits to ensure that the binary number lengths of the x and y coordinates are consistent, providing a unified basis for subsequent alternating truncation. For example, if the standardized x-coordinate is 123 (decimal), the preset number of bits is 12, and the converted binary number is 000001111011, the length after zero-padding is strictly equal to the preset number of bits, avoiding encoding errors due to inconsistent lengths. The conversion results are recorded in the "Encoding Preprocessing Log," allowing developers to view the binary conversion process for each coordinate, facilitating the troubleshooting of encoding anomalies.

[0038] Alternating cropping and combining is the core step in converting two-dimensional coordinates to one-dimensional encoding. The specific process is as follows: Extraction order: Extract the first bit of the binary number at the x-coordinate from the most significant bit to the least significant bit, then extract the first bit of the binary number at the y-coordinate, and so on, until all binary bits have been extracted. Combination rule: The extracted binary bits are concatenated in the order of extraction to form a continuous intermediate binary code. The code length is twice the preset number of bits (each of the x and y coordinates occupies a preset number of bits). For example: the binary number at the x-coordinate is... The binary representation of the y-coordinate is After alternating truncation, the middle binary code is: This enables one-dimensional compression of two-dimensional spatial information.

[0039] To avoid different coordinates generating the same intermediate binary code, after combining the intermediate binary code, the horizontal and vertical components of the standardized coordinates are added together, and the last 3 bits of the sum are used as check bits. These check bits are then appended to the end of the intermediate binary code, forming an intermediate code with a check bit, which improves the uniqueness of the code by 8 times. This process is automatically executed by the encoding algorithm module, with an execution efficiency of no less than 1000 times / second, ensuring real-time generation of batch object codes.

[0040] The preset unit length is a fixed rule for splitting intermediate binary codes, and it has two splitting modes, which developers can select through the "Encoding Split Configuration Interface": 2-bit splitting mode: The middle binary code is split into 2 bits each, with each binary unit corresponding to a decimal digit from 0 to 3. The encoded string consists of 0, 1, 2, and 3, resulting in a shorter code length suitable for large maps. 4-bit splitting mode: The middle binary code is split into 4 bits each, with each binary unit corresponding to a decimal digit from 0 to 15. The encoded string consists of 0 to 9 and AF, offering higher encoding precision and suitability for smaller maps. Decimal conversion uses the general logic of binary to decimal conversion. Each binary unit is converted independently and then concatenated in the order of splitting to form the final GeoHash code. If an invalid binary unit appears during the conversion process (e.g., the length after splitting is less than the preset unit length), the system automatically pads it with 0s at the end to ensure code integrity.

[0041] Conflict Detection: After the initial GeoHash encoding is generated, the system automatically queries the distributed cache for the stored encodings. If the current encoding is found to be duplicated with an existing encoding (i.e., different coordinates correspond to the same encoding), conflict resolution is immediately triggered. Resolution Logic: A differential flag bit (value range 0-7) is added to the end of the duplicate encoding. It is allocated according to the "first-come, first-served" principle. The first object to use the encoding has a flag bit of 0, and subsequent conflicting objects increment the flag bit sequentially to ensure that the GeoHash encoding of each object is unique. Flag Bit Maintenance: The differential flag bit is stored in association with the unique identifier of the game object. When the object is deleted or the coordinates are updated, causing the encoding to change, the corresponding flag bit is released for subsequent use to avoid flag bit exhaustion.

[0042] The association between GeoHash encoding and the unique identifier of the game object is stored in key-value pairs, with the following storage architecture: Storage Media: Employs a distributed caching system (such as a Redis cluster), supporting high-concurrency read and write operations with a response time of no more than 10 milliseconds; Storage Structure: Keys are GeoHash codes, and values ​​are a list of unique identifiers for game objects (when the same code corresponds to multiple objects, they are sorted by object type, with dynamic objects first and static objects last); Index Construction: The index is built based on GeoHash code prefixes, allowing for fast queries by prefix. Queries only need to traverse nodes matching the prefix, eliminating the need for a full scan and significantly improving retrieval efficiency; Update Mechanism: When game object coordinates are updated, GeoHash codes are synchronously regenerated, the association between the original code and the object identifier is deleted, and a new association is established, ensuring real-time matching between code and location. The associated storage status is visualized through the "Code Storage Monitoring Interface," including metrics such as code distribution, number of associated objects, and storage space usage. Developers can manually clean up invalid codes (such as records where the object has been deleted but the code has not).

[0043] When the search radius is large and spans multiple GeoHash encoding boundaries, relying solely on adjacent nodes for completion can easily result in insufficient coverage, requiring optimization through correction parameters. Correction parameter calculation: Correction parameter = search radius ÷ single coding unit spatial side length (the single coding unit spatial side length is the spatial range side length corresponding to the current prefix length). The larger the ratio, the stronger the correction force. Expanding the search range: When the correction parameter > 2, in addition to searching directly adjacent nodes (difference of 1 bit at the end of the coding prefix), secondary adjacent nodes (difference of 2 bits at the end of the coding prefix) are searched to ensure coverage of all target objects that cross the boundary. Efficiency optimization: For objects retrieved from secondary adjacent nodes, weights are assigned according to their distance from the center coordinates. The farther the distance, the lower the weight. Objects with a weight lower than 0.2 are automatically removed to avoid excessive expansion that leads to a decrease in search efficiency. Parameter adaptation: The correction parameter can be manually adjusted through the "coding boundary configuration interface". Developers can preset adaptation values ​​according to map coding density and common search radii to balance coverage integrity and search efficiency.

[0044] The core value of the GeoHash encoding generation process lies in three aspects: First, it compresses two-dimensional spatial coordinates into one-dimensional strings, significantly reducing storage overhead. Compared with the original coordinate storage, the storage space occupied is reduced by more than 60%. Second, it can quickly determine the spatial proximity of objects through encoding prefix matching. Objects with the same prefix are in the same spatial region, providing a core basis for quadtree aggregation storage. Third, the encoding structure is simple, which facilitates rapid comparison and retrieval, improving the response speed of positioning requests.

[0045] Specifically, the process of building a quadtree storage system and hot / cold partitioning is as follows: A quadtree storage structure is constructed based on the prefix length of GeoHash encoding, with each node of the quadtree corresponding to a set of GeoHash codes with the same prefix. The GeoHash codes associated with game objects are extracted, and the prefixes are truncated according to a preset prefix length. Game objects with the same prefix are aggregated and stored in the corresponding nodes of the quadtree. A position update frequency statistics period is set to count the number of times the spatial coordinates of each game object are updated within the statistics period in real time. Each node of the quadtree is divided into a hot storage area and a cold storage area. The hot storage area uses a memory-first storage method, while the cold storage area uses a disk cache storage method. Game objects whose spatial coordinates are updated to the preset update threshold within the statistics period are assigned to the hot storage area of ​​the corresponding node, while game objects whose spatial coordinates are not updated within the statistics period are assigned to the cold storage area of ​​the corresponding node. An association index between the storage areas and the game objects is established.

[0046] The detailed explanation of the quadtree storage system construction and hot / cold partitioning is as follows: The quadtree storage structure is based on the number of bits in the GeoHash encoding prefix, and the construction process is automated. Details are as follows: Layering Rules: The levels of the quadtree correspond one-to-one with the number of bits in the GeoHash encoding prefix. The root node (level 0) corresponds to an empty prefix, covering the entire map. Level 1 corresponds to a 1-bit encoding prefix, with 4 nodes (corresponding to prefixes 0, 1, 2, and 3 respectively). Level 2 corresponds to a 2-bit encoding prefix, with 16 nodes; and so on. The deeper the level, the smaller the spatial range of the node and the fewer the number of aggregated objects. Node Capacity: Each node has a preset maximum threshold for the number of objects it can store (50 for small map nodes and 100 for large map nodes). If the number of objects exceeds the threshold, the node is automatically split into four child nodes. The original node is expanded by adding 1 bit (value 0-3) to the end of the GeoHash encoding prefix, splitting into four child nodes. Objects are automatically assigned to corresponding child nodes based on their own encoding prefixes. The splitting process does not interrupt the retrieval service; it only pauses the write operation of the node (pause duration ≤ 10 milliseconds). The four-part splitting method is based on the quadtree adaptation characteristics of GeoHash encoding. Each bit extension of the encoding prefix corresponds to exactly four possible values ​​(0-3), which perfectly matches the four-branch structure of the quadtree. This ensures that the spatial range of child nodes after splitting is non-overlapping and non-omitted. Moreover, the object allocation logic is consistent with the encoding prefix rules, requiring no additional adaptation calculations. Construction efficiency: The quadtree construction time for small maps is no more than 1 second, for medium-sized maps no more than 3 seconds, and for large maps no more than 5 seconds. After construction, the tree structure is displayed through the "Storage Structure Monitoring Interface," and developers can expand to view the object storage status of each node.

[0047] Latency Control Mechanism: A maximum latency threshold of 50 milliseconds is set for priority retrieval in the hot storage area. This threshold can be adjusted according to the game scenario through the "Retrieval Configuration Interface" (30 milliseconds for competitive games, 80 milliseconds for open-world games). If the retrieval time in the hot storage area exceeds the threshold, parallel retrieval in the cold storage area is immediately initiated to avoid timeouts in low-frequency object retrieval responses. Synchronous Verification Mechanism: After the hot storage area retrieval is completed, a fast verification of the cold storage area is automatically triggered. Only the cold storage area of ​​the quadtree node corresponding to the target encoding prefix is ​​retrieved, without full traversal. The verification process only extracts the object coordinates and unique identifier, calculates the actual straight-line distance between the object and the center coordinates, and includes objects that meet the search radius requirements into the candidate set, ensuring that geographically proximate low-frequency objects are not missed. Dynamic Adjustment Mechanism: Real-time correlation with server load (CPU utilization, memory usage). When CPU utilization > 80% or memory usage > 85%, the priority of hot storage area retrieval is temporarily reduced, and hot and cold storage areas are retrieved synchronously. When the load < 50%, hot storage area priority is maintained, but synchronous verification is retained to balance retrieval efficiency and coverage integrity.

[0048] The preset prefix length is a key parameter for aggregated storage of game objects. It is strongly related to the quadtree level and node capacity, and its value ranges from 4 to 8 bits. The specific configuration rules are as follows: A longer prefix length results in a smaller spatial range for each node, fewer aggregated objects, and higher retrieval efficiency, but also more levels in the quadtree, slightly increasing storage overhead. Conversely, a shorter prefix length results in a larger spatial range for each node, more aggregated objects, and slightly lower retrieval efficiency, but fewer levels in the quadtree, resulting in lower storage overhead. Parameter configuration is achieved through the "Quadtree Configuration Interface," allowing developers to dynamically adjust based on object density. The system calculates the adjusted node load and retrieval efficiency in real time and provides adjustment suggestions. For example, when object density is high, it is recommended to increase the prefix length to reduce the load on individual nodes; when object density is low, it is recommended to decrease the prefix length to simplify the quadtree structure.

[0049] The location update frequency statistics period is a core parameter for distinguishing the dynamic characteristics of objects. The default value is 2-5 seconds. Developers can manually adjust it through the "Frequency Statistics Configuration Interface". The adjustment takes effect immediately. Statistical Scope: Only coordinate updates of game objects within the map boundaries are counted; updates outside the boundaries are not included. Statistical Precision: Coordinate update timestamps are recorded at the millisecond level to ensure accurate results and avoid omissions or duplicates. Result Storage: Statistical results are stored in an object status table, associated with a unique identifier for each game object. The storage period is 24 hours; expired results are automatically cleared, releasing storage resources. The choice of the statistical period needs to balance accuracy and performance overhead. A period that is too short may cause dynamic objects to be misjudged as static (e.g., a player briefly staying still), while a period that is too long may not be able to respond promptly to changes in object status (e.g., a player suddenly moving). The period should be adapted to the game type: 2-3 seconds for competitive games and 4-5 seconds for casual games.

[0050] The preset update count threshold is the criterion for determining hot and cold partitions, with a value range of 2-5 times, and is configured differently according to object type: Dynamic objects: The threshold is set to 2-3 times. The coordinate update frequency of dynamic objects in the game (such as players and combat NPCs) follows a Poisson distribution with λ=2 (based on actual test data from 100 competitive games). The probability of P(X≥2) (updates ≥2 times within 3 seconds) is 73.5%, which can effectively distinguish between continuously moving dynamic objects and objects that only stay for a short time, ensuring that frequently moving objects can be quickly assigned to the hot storage area. Static objects: The threshold is set to 4-5 times. The coordinate updates of static objects (such as fixed props and buildings) are mostly triggered by false alarms (such as system false alarms). Their update frequency follows a Poisson distribution with λ=0.5, and the probability of P(X≥4) is only 0.2%, which can minimize the possibility of static objects being mistakenly assigned to the hot storage area and avoid partitioning errors caused by false updates. The threshold configuration is achieved through the "Partition Threshold Configuration Interface". After configuration, the system automatically generates a partitioning rule table to record the threshold standards for different object types. For example, if the statistical period is 3 seconds and the threshold for dynamic objects is set to 2 times, dynamic objects whose coordinates are updated at least 2 times within 3 seconds are assigned to the hot storage area, while those that are not updated are assigned to the cold storage area.

[0051] Differentiated storage strategies are employed between hot and cold storage areas to ensure efficient utilization of storage resources: Hot storage area: Uses an in-memory database (such as Redis) for storage of frequently updated dynamic objects. Read / write speed is no less than 1000 times / second, allowing random read / write to ensure fast retrieval of object data. Cold storage area: Uses a hybrid storage of disk cache and SSDs for storing static objects. Read / write speed is no less than 100 times / second, primarily using sequential read / write to reduce storage costs. Partition switching: Dynamic switching between hot and cold storage areas is possible. When the number of times object coordinates are updated in the cold storage area reaches a threshold, the object is automatically migrated to the hot storage area. When objects in the hot storage area have no updates for two consecutive statistical periods, they are automatically migrated to the cold storage area. The switching process does not affect the response to location requests.

[0052] The threshold is not a fixed value, but is dynamically linked to the server load. The algorithm logic is as follows: Real-time monitoring of server CPU utilization (threshold A) and memory usage (threshold B). When A > 80% or B > 85%, the threshold for dynamic objects is increased by 1 (e.g., from 2 to 3 times), and the threshold for static objects is increased by 1 (e.g., from 4 to 5 times), reducing the write pressure on the hot storage area. When A < 50% and B < 60%, the threshold is reverted to the default value to improve the dynamic response accuracy of the hot storage area and achieve an adaptive balance between "load-threshold-storage efficiency".

[0053] The associative index is a mapping table that records the relationship between "encoding prefix - node - storage area - object identifier". The core design is as follows: Index Structure: Employs a B+ tree index for fast queries based on encoded prefixes, with a query efficiency of no more than 8 milliseconds; Index Updates: Performed synchronously with object storage. When the object storage location changes (e.g., migrated to another node, switched storage areas), the index is updated in real time to ensure consistency between the index and the storage state; Index Maintenance: The system automatically performs index optimization (e.g., defragmentation, redundant deletion) every morning to improve query efficiency; Developers can manually rebuild indexes through the "Index Management Interface." When the index query efficiency falls below a preset threshold (e.g., exceeding 10 milliseconds), the system will display an optimization prompt.

[0054] This step achieves two core objectives through spatial aggregation and differentiated storage: First, the quadtree structure aggregates game objects according to their spatial location, avoiding full object traversal and improving retrieval efficiency by more than 50%; second, hot and cold partitioning allocates storage resources based on the dynamic characteristics of objects, with memory prioritizing high-frequency updated objects and disk caching carrying static objects, balancing retrieval speed and storage costs, and providing efficient storage support for subsequent accurate positioning.

[0055] Specifically, the process of optimizing retrieval accuracy is as follows: The search radius parameter in the location request is obtained, and an exponential index optimization algorithm is used to establish a mapping relationship between the search radius and the GeoHash encoding prefix length. The target prefix length corresponding to the current search radius is calculated based on the mapping relationship, and the search radius and prefix length are negatively correlated. Based on the calculated target prefix length, the GeoHash encoding prefix part corresponding to the center coordinates is extracted to form the target encoding prefix. If the number of matching nodes deviates from the suitable range during the retrieval process, the target prefix length is dynamically fine-tuned, and node matching is performed again until the number of matching nodes is in the preset optimal retrieval range, thereby achieving dynamic optimization of retrieval accuracy.

[0056] The detailed explanation of the search accuracy optimization is as follows: The search radius parameter is a core input item for the search request. It is defined as a circular area with the center coordinates as the center and the game unit as the radius. The specific rules are as follows: Value range: 1-1000 game units (1 game unit corresponds to the side length of 1 grid cell). Players can trigger this through in-game interactions (e.g., when clicking "Find Nearby Teammates," the default search radius is 50 game units), or it can be automatically triggered by the game system (e.g., in a battle scene, the default search radius is 100 game units). Acquisition method: Obtained from the game client or system module via a retrieval request interface. The transmission process uses a data encryption protocol to prevent parameter tampering. Legality verification: After acquisition, the system automatically verifies whether the parameter is within the value range. If it exceeds the range, it is automatically corrected to the default search radius of the corresponding scene, and a correction log is recorded for developers to trace.

[0057] The exponential index optimization algorithm is the core of constructing the mapping relationship between the search radius and the prefix length. The algorithm logic is based on the correlation between the GeoHash encoded prefix length and the spatial range: for every 1 bit increase in the encoded prefix length, the corresponding spatial range shrinks to one-quarter of its original size (adapting to a quadtree 4-branch structure). The specific mapping logic is as follows: Baseline settings: Preset the base prefix length (e.g., 6 bits) and the corresponding base space range (e.g., 6-bit prefix corresponds to 100 game units) as the base for the mapping relationship; The mapping table is dynamically generated based on a geometric progression. The core generation rule is that "for every 1-bit increase in prefix length, the corresponding space range shrinks to one-quarter of the previous position; for every 1-bit decrease in prefix length, the corresponding space range expands to four times the previous position." The specific generation steps are as follows: Starting with the base prefix length and base spatial range, the process proceeds forward (prefix length decreases): for every 1 bit decrease in prefix length, the spatial range is multiplied by 4, until the maximum search radius (1000 game units) is covered; The process then proceeds backward (prefix length increases): for every 1 bit increase in prefix length, the spatial range is divided by 4, until the spatial range is less than the minimum search radius (1 game unit); A mapping table entry is generated: each entry contains "search radius range - corresponding prefix length", for example, when a base length of 6 bits corresponds to 100 game units, 5 bits correspond to 200-400 game units, 7 bits correspond to 25-100 game units, and so on; Non-square map correction method: for non-square maps (different numbers of grids on the x and y axes), the spatial range coefficients in the x and y directions need to be calculated separately. The correction logic is: calculate the spatial range coefficient in the x direction = total number of grids on the map's x-axis ÷ total number of grids on the map's y-axis; candidate prefix lengths are initially calculated according to the square map rules; if the spatial range coefficient in the x direction... If the x-axis spatial range coefficient is greater than 1 (longer along the x-axis), the candidate prefix length increases by 1 bit; if the x-axis spatial range coefficient is less than 1 (longer along the y-axis), the candidate prefix length remains unchanged, while the search range of adjacent nodes in the x-axis is expanded to ensure the complete coverage of the search radius along the major axis. Mapping derivation: When the search radius is greater than the basic spatial range, the prefix length is less than the basic length; the larger the radius, the shorter the prefix length. When the search radius is less than the basic spatial range, the prefix length is greater than the basic length; the smaller the radius, the longer the prefix length. Dynamic update mechanism of the mapping table: The mapping table is strongly correlated with the game map size. When developers modify parameters such as map width, height, and grid density through the "map grid configuration interface," the system automatically recalculates the basic spatial range and geometric progression derivation results, updating the mapping table entries without manual intervention, ensuring that the mapping relationship always accurately adapts to the current map. Algorithm execution: The algorithm execution efficiency does not exceed 2 milliseconds per request, and batch retrieval requests can be processed in parallel to ensure response speed in high-frequency retrieval scenarios. The algorithm prioritizes fast matching through the preset mapping table; when the range exceeds the mapping table, it dynamically calculates based on geometric progression rules.

[0058] Setting the optimal search interval is a key parameter for balancing search efficiency and coverage. Its value ranges from 5 to 15 nodes, and the specific configuration rules are as follows: High-performance servers: Set the interval to 5-10 nodes to prioritize retrieval speed; Low-performance servers: Set the interval to 10-15 nodes to prioritize coverage. Interval configuration is achieved through the "Retrieval Interval Configuration Interface." After configuration, the system automatically monitors the number of matching nodes during the retrieval process. When the number of nodes in 10 consecutive retrievals exceeds the interval, a warning message will pop up, prompting adjustments to the interval parameters or server configuration. The optimal retrieval interval setting should avoid two extremes: too many nodes will increase traversal overhead (e.g., 20 nodes need to be traversed one by one), leading to retrieval delays; too few nodes may miss target objects (e.g., only 3 nodes are matched, failing to cover part of the search radius).

[0059] Dynamic fine-tuning is a supplementary mechanism for optimizing retrieval accuracy; the fine-tuning rules are explicit and configurable. Fine-tuning trigger conditions: The number of matched nodes exceeds the upper limit or falls below the lower limit of the interval during retrieval; Fine-tuning step size: The prefix length is increased or decreased by 1 bit each time a fine-tuning is performed to avoid excessive adjustment that could cause significant changes in the retrieval range; For non-square maps, the prefix length correction along the long axis is prioritized during fine-tuning. For example, for maps with a longer x-axis, the prefix length is increased or decreased first to adapt to the x-axis coverage requirements, ensuring that no target objects are missed along the long axis; Fine-tuning limit: A maximum of 3 fine-tuning operations are performed. If the optimal interval is not reached after 3 fine-tuning operations, the default prefix length is used to ensure that the retrieval does not fall into an infinite loop; Fine-tuning record: The fine-tuning process is recorded through the "Retrieval Log Interface," including information such as the prefix length before adjustment, the number of matched nodes, and the prefix length after adjustment. For example, if the preset optimal retrieval interval is 5-10 nodes, and the number of matched nodes during retrieval is 16 (exceeding the upper limit), the prefix length is increased by 1 bit, and nodes are rematched; if the number of matched nodes is 3 (below the lower limit), the prefix length is decreased by 1 bit, and nodes are rematched, until the number of nodes is within the interval.

[0060] To avoid the limitations of the preset mapping table, the algorithm supports dynamically calculating the prefix length corresponding to the search radius that exceeds the range of the mapping table: when the search radius is greater than the maximum coverage range of the mapping table, iterative derivation is performed according to the rule that "for every 1 bit decrease in prefix length, the spatial range expands by 4 times"; when the search radius is less than the minimum coverage range of the mapping table, iterative derivation is performed according to the rule that "for every 1 bit increase in prefix length, the spatial range shrinks by 4 times". There is no need to manually expand the mapping table, which can adapt to the positioning requirements of any reasonable search radius.

[0061] This step addresses the issue of a fixed prefix length failing to accommodate different search ranges by dynamically adapting the search radius and prefix length: a longer prefix length is used for small-range searches to accurately match a small number of nodes and improve search accuracy; a shorter prefix length is used for large-range searches to match multiple nodes and ensure coverage. Simultaneously, the optimal search interval and dynamic fine-tuning mechanism further balance search efficiency and accuracy, ensuring that location requests in different scenarios can be responded to quickly and accurately.

[0062] Specifically, the process of effective directional expansion is as follows: The basic directions for valid directional expansion are determined, namely up and down, left and right, and the four diagonals; the position of the center coordinates in a unified coordinate system is obtained, and the vertical distance from the center coordinates to the four boundaries of the game map is calculated; each vertical distance is compared with a preset boundary threshold, and expansion directions that exceed the scope of the game map are automatically clipped; for the remaining valid expansion directions, the quadtree nodes associated with the target encoding prefix in each direction are retrieved in turn to expand the retrieval coverage and ensure the comprehensiveness of the retrieval of neighboring objects.

[0063] A detailed description of the effective directional expansion is shown below: The basic directions are 8 fixed spatial directions: up, down, left, right, upper left, upper right, lower left, and lower right, covering all spatial areas around the center coordinates to ensure no direction is missed. Direction Identifier: Each direction is assigned a unique identifier code (e.g., "up" corresponds to code 01, "down" corresponds to code 02) to facilitate system identification and retrieval; Direction Angle: The angle range for each direction is preset, such as "up" corresponding to 90°±22.5°, and "upper right" corresponding to 45°±22.5° to ensure accurate object orientation judgment; Customization Support: Developers can adjust the direction angle range through the "Direction Configuration Interface" to adapt to special shape maps (e.g., circular maps, diamond-shaped maps). After adjustment, the system automatically updates the direction identifier and retrieval logic.

[0064] Vertical distance is calculated using a coordinate difference algorithm, with the core logic as follows: Boundary parameter acquisition: The extreme coordinate values ​​of the four boundaries are read from the map configuration file (minimum x-value of the left boundary, maximum x-value of the right boundary, minimum y-value of the upper boundary, and maximum y-value of the lower boundary). For non-rectangular maps, the core boundary parameters are read (for circular maps, the center coordinates and radius are read; for rhomboid maps, the diagonal endpoint coordinates are read), ensuring accurate calculation. Calculation process: Rectangular map: Center coordinates are (… , When ), the distance to the left boundary is The difference between the minimum x value at the left boundary and the distance to the right boundary is the difference between the maximum x value at the right boundary and the minimum x value at the left boundary. The difference, the distance to the upper boundary is The difference between the minimum value of y at the upper boundary and the minimum value of y at the lower boundary is the distance to the maximum value of y at the lower boundary. The difference; circular map: center coordinates are ( , When the center of a map circle is (cx, cy) and the radius is r, the steps for calculating the distance to the map boundary are as follows: First, calculate the difference between the center coordinates and the map center in the horizontal direction. Second, calculate the difference between the two in the vertical direction. Third, square the two differences respectively. Fourth, add the squared results to get the total. Fifth, take the square root of the total to get the straight-line distance between the two points. Sixth, subtract the straight-line distance from the map radius. A final result greater than or equal to 0 indicates the point is inside the map, and less than 0 indicates the point is outside the map. For a rhombus-shaped map: the center coordinates are (cx, cy). , When the intersection of the map's diagonals is (dx, dy), the length of the long diagonal is 2a, and the length of the short diagonal is 2b, the distance to the boundary is the smaller of "half the length of the long diagonal minus the horizontal distance between the center coordinate and the intersection point" and "half the length of the short diagonal minus the vertical distance between the center coordinate and the intersection point." Calculation precision: The result is rounded to integers, and the unit is game units. The calculation efficiency does not exceed 1 millisecond per calculation, ensuring fast distance calculation and not affecting the retrieval response speed. The calculation results are stored in a temporary cache, used only for this direction expansion judgment, and are automatically cleared after the retrieval is completed to avoid consuming storage resources.

[0065] The preset boundary threshold is the criterion for directional clipping, and its value is 1.2-1.5 times the search radius. Developers can manually adjust it through the "Boundary Threshold Configuration Interface," and the adjustment takes effect immediately. Threshold Adaptation: When the search radius changes dynamically, the boundary threshold is adjusted proportionally to ensure that the threshold and search radius always maintain an adaptive relationship. Clipping Logic: When the vertical distance from the center coordinate to a boundary is less than the boundary threshold, it is determined that the expansion in that direction may exceed the map range, and the direction and its two adjacent diagonal directions are automatically clipped. When the vertical distance is greater than or equal to the boundary threshold, the expansion permission for that direction is retained. For example, if the search radius is 50 game units and the boundary threshold is set to 1.2 times (i.e., 60 game units), if the distance from the center coordinate to the left boundary is 50 game units (less than 60), the left, upper-left, and lower-left directions are clipped to avoid searching invalid nodes outside the map; if the distance to the right boundary is 70 game units (greater than 60), the expansion permission for the right, upper-right, and lower-right directions is retained.

[0066] The effective direction retrieval adopts a "direction-node" association query mechanism, and the specific process is as follows: Associative Node Matching: For each valid direction, the system automatically queries the quadtree nodes associated with the target encoding prefix, with the association rule being "the spatial range corresponding to the direction overlaps with the spatial range of the node"; Retrieval Order: The system retrieves data in the order of "up → down → left → right → upper left → upper right → lower left → lower right" to ensure that each valid direction is traversed; Parallel Processing: Multi-directional parallel retrieval is employed, with a retrieval speed of no less than 20 nodes / second. Retrieval results are aggregated to the candidate object set in real time, sorted by object type (dynamic objects first, static objects last). If no associated node is found in a certain direction during the retrieval process, the system automatically skips that direction and continues to retrieve the next valid direction, avoiding unnecessary waiting and improving retrieval efficiency.

[0067] This step achieves two main goals by combining 8-way full coverage expansion with intelligent boundary pruning: first, it solves the problem of limited coverage of a single node by expanding the search scope from the central node to surrounding related nodes, ensuring that no cross-regional objects are missed; second, it eliminates invalid directions through boundary pruning, reduces unnecessary node traversal, lowers search overhead, and balances coverage integrity and search efficiency.

[0068] Specifically, the process of code boundary completion is as follows: Identify the adjacent nodes of the quadtree node corresponding to the target encoding prefix. Adjacent nodes are nodes whose encoding prefixes differ only in the last bit. Perform supplementary retrieval on the adjacent nodes to extract the spatial coordinate data of the game objects stored in the adjacent nodes. Calculate the actual straight-line distance between the game objects obtained from the supplementary retrieval and the center coordinates. Include game objects whose actual straight-line distance is less than or equal to the search radius into the candidate object set to eliminate retrieval blind spots across encoding prefix boundaries and ensure the integrity of the positioning coverage.

[0069] The detailed content of code boundary completion is as follows: Adjacent node identification uses a prefix difference matching algorithm. The core logic focuses on the difference in the last bit of the encoded prefix. The specific rules are as follows: Recognition criteria: Two nodes are considered adjacent nodes only if their GeoHash encoding prefixes are identical except for the last bit. For example, if the target node's prefix is ​​"1234", then nodes with prefixes "1230", "1231", "1232", "1233", "1235", etc., differing only in the last bit, are all adjacent nodes. Recognition scope: Limited to nodes at the same level as the target node in the quadtree. Nodes at different levels are not considered adjacent nodes even if their prefixes differ in the last bit. Recognition efficiency: The recognition speed is no less than 3 milliseconds per node. Multiple adjacent nodes are identified in batches, and the results are stored in a temporary list for subsequent supplementary retrieval. During the recognition process, if the target node is an edge node of the quadtree (e.g., the prefix last bit is 0, and there are no nodes with a smaller last bit), non-existent adjacent nodes are automatically skipped to avoid invalid recognition.

[0070] Supplementary retrieval is the core step in code boundary completion. The retrieval strategy is consistent with the retrieval logic of effective direction expansion, and the specific details are as follows: Search Priority: Prioritize searching the hot storage area of ​​adjacent nodes, then search the cold storage area to ensure that frequently updated dynamic objects are captured first; Search Content: Only extract the spatial coordinate data and unique identifier of game objects in adjacent nodes, without extracting other redundant information (such as object attributes and status) to reduce data transmission overhead; Search Limits: The number of adjacent nodes to be supplemented for retrieval is limited to a maximum of 8. If the number of adjacent nodes exceeds the limit, they are sorted by spatial distance from the target node, and the nearest node is retrieved first; Search Speed: The search speed is no less than 15 nodes / second, and the search results are transmitted to the distance calculation module in real time to avoid data backlog.

[0071] The actual straight-line distance is calculated using Euclidean distance. The specific calculation steps are as follows: The first step is to obtain the spatial coordinates of the supplementary search objects. , ) and the coordinates of the retrieval center ( , The second step is to calculate the difference in the horizontal direction (); and The difference in the vertical direction and the difference in the vertical direction ( and The first step is to find the difference between the two coordinates. The second step is to square the difference between the two coordinates. The third step is to square the difference between the two coordinates. The fourth step is to add the squared results together to get the sum. The fifth step is to take the square root of the sum, which is the actual straight-line distance between the two coordinates. The calculation precision is kept to one decimal place, the unit is game unit, the calculation efficiency is no more than 0.5 milliseconds / object, and it supports batch object parallel calculation to ensure fast completion of distance filtering.

[0072] To be included in the candidate object set, objects that meet the distance criteria must be retrieved. The specific rules are as follows: Distance determination: Objects whose actual straight-line distance is less than or equal to the search radius are directly included in the candidate set; objects whose distance is greater than the search radius are automatically removed; Deduplication: If the supplementary search object has been included in the candidate set through effective directional expansion, the system automatically deduplicates to avoid duplicate statistics; Sorting rules: Objects included in the candidate set are sorted according to their distance from the center coordinates. The closer the distance, the higher the ranking, providing a priority basis for subsequent multi-dimensional filtering.

[0073] The core objective of code boundary completion is to eliminate retrieval blind spots caused by GeoHash code prefix division: because code prefixes are divided according to spatial range, some objects may be located within the search radius, but their code prefixes differ from the target prefix only in the last bit, making them undetectable through effective directional expansion. By supplementing retrieval with adjacent nodes and filtering by distance, these cross-boundary objects can be accurately captured. This step complements effective directional expansion, which solves the coverage problem of "cross-regional nodes," while code boundary completion solves the omission problem of "cross-code boundaries." Together, they ensure that no target objects within the search radius are missed.

[0074] Specifically, the multi-dimensional filtering process is as follows: The system presets multiple filtering dimensions, including game object type, level range, faction affiliation, and interaction status. These dimensions are then sorted according to preset priorities. User-defined filtering commands are accepted, including dynamically adding or removing filtering dimensions and adjusting their priority order. Based on the sorted filtering dimensions, game objects in the candidate object set are filtered layer by layer: objects of the target type are filtered by object type, objects meeting the level requirements are filtered by level range, and so on, completing the full-dimensional filtering. A secondary distance check is performed on the filtered objects to exclude those exceeding the search radius, resulting in the final candidate objects.

[0075] The detailed instructions for multi-dimensional filtering are as follows: Preset filtering dimensions are the core condition for accurate positioning, covering the key attributes of game objects, as explained below: Object Types: Includes players, NPCs, items, vehicles, etc. Each type is assigned a unique category code. Developers can add types (e.g., "Pets" or "Summoned Items") through the "Filter Dimension Configuration Interface." Level Ranges: Supports custom level ranges (e.g., levels 1-30, 50 and above). Range settings are implemented through the "Level Range Configuration Interface," supporting input of a starting and ending level. The system automatically verifies the validity of the range (starting level ≤ ending level). Faction Affiliation: Includes three categories: Allied, Hostile, and Neutral. Developers can add faction types (e.g., "Third-Party Faction"). Faction tags are associated with game objects through the game's faction management system. Interaction Status: Includes alive, dead, interactive, and non-interactive. Status tags are updated in real-time by the game system to ensure accurate filtering results. Default configurations for each filtering dimension are saved through the "Filter Template Management Interface," enabling quick access (e.g., the "Teammate Search Template" defaults to filtering "Players + Allies + Alive"), improving configuration efficiency.

[0076] The preset priority determines the execution order of the filtering dimensions. By default, it is sorted in the order of "Object Type → Level Range → Faction Affiliation → Interaction Status," ensuring that core dimensions are filtered first, reducing the amount of data for subsequent filtering. Sorting logic: Dimensions with higher priority are filtered earlier. For example, "Player" type objects are filtered first, then objects matching the level range are filtered from players, and so on. Configuration method: Developers can drag and drop to adjust the sorting order in the "Priority Configuration Interface," and the changes take effect immediately. The sorting results are stored in the filtering rules table. Priority basis: Priority settings are based on the filtering efficiency of the dimensions. Object type and level range filtering are the most efficient (quickly removing a large number of irrelevant objects), followed by faction affiliation and interaction status filtering, ensuring an efficient overall filtering process.

[0077] The system allows users (developers or game administrators) to adjust filtering rules through a "custom filter interface" to meet diverse targeting needs. Specific functions are as follows: Dimensional Operations: Users can dynamically add filter dimensions (e.g., adding "Equipment Level" or "Quest Affiliation") and remove irrelevant dimensions (e.g., removing "Faction Affiliation" during item retrieval); Priority Adjustment: Drag and drop to adjust the priority order of dimensions. For example, in competitive scenarios, "Faction Affiliation" can be prioritized first for quick filtering of enemy targets; Rule Saving: Custom filter rules can be saved as filter templates, named, and stored in the template library for later direct access and modification; Access Control: The custom filter function differentiates between permission levels. Developers have full access, game administrators can only adjust certain dimensions (e.g., level range, interaction status), and ordinary users have no custom permissions.

[0078] The layer-by-layer screening process uses a streamlined workflow, which is clear and efficient. Filtering process: First-level filtering (object type) → Second-level filtering (level range) → Third-level filtering (faction affiliation) → Fourth-level filtering (interaction status). Each level of filtering yields a subset of objects, with the size of the subset decreasing progressively. Execution efficiency: Filtering efficiency is positively correlated with the number of candidate objects. When there are 1000 candidate objects, the full-dimensional filtering completion time is no more than 10 milliseconds; when there are 10000 candidate objects, the completion time is no more than 50 milliseconds, enabling batch filtering and meeting high-frequency location requests. Filtering log: The filtering process is recorded through the "Filtering Log Interface," including information such as filtering dimensions, filtering conditions, and the number of filtering results, facilitating the optimization of filtering rules.

[0079] The second distance check is the final guarantee of accuracy, preventing objects from exceeding the search radius due to directional expansion or boundary completion. The specific logic is as follows: Verification Objects: Only objects filtered by multiple dimensions are verified to reduce the amount of verification data; Verification Method: The actual straight-line distance calculation logic is consistent with that of code boundary completion to ensure a unified verification standard; Verification Results: Objects with a distance less than or equal to the search radius are retained and included in the final candidate object set; Objects with a distance greater than the search radius are removed, and the reason for removal is recorded in the verification log; Verification Pass Rate: Under normal circumstances, the verification pass rate is not less than 95%. If the pass rate is less than 90%, the system will automatically issue a warning and prompt you to check the parameter configuration of the direction expansion or boundary completion.

[0080] This process transforms the process from "spatial coverage" to "precise filtering," with its core value manifested in three aspects: First, it eliminates irrelevant objects through multi-dimensional filtering, resolving the issue of mixed object types caused by relying solely on spatial range positioning and improving positioning accuracy. Second, it supports custom filtering rules to adapt to diverse game positioning scenarios (such as finding nearby teammates of the same faction, retrieving items of specific levels, and locating enemy targets). Third, secondary distance verification ensures that the final object meets the spatial range requirements, preventing invalid objects from consuming interactive resources and providing game players with accurate positioning results.

Claims

1. A one-dimensional mapping and positioning method for games, characterized in that, The method includes: Collect spatial coordinate data of game objects, construct a regular gridded game map, and establish a unified coordinate system; Based on the coordinate system, the two-dimensional coordinates of the map are combined in binary and converted to decimal to generate GeoHash encoding that is adapted to the rule-based gridded game map; Based on GeoHash encoding, a quadtree storage system is constructed, which aggregates and stores game objects in corresponding nodes according to the association relationship of the encoding prefix, and divides the hot storage area and cold storage area within the node according to the update frequency of the game object's position. The system receives retrieval requests containing center coordinates and search radius. It uses a quadtree storage system to convert the center coordinates into GeoHash encoding and extracts the target prefix. It prioritizes matching game objects whose spatial coordinates are updated frequently. It optimizes retrieval accuracy by dynamically adjusting the encoding prefix length. It captures target game objects that cross regions and are missed by the boundary by combining effective directional expansion and encoding boundary completion. After multi-dimensional filtering, it accurately locates the spatial position of target game objects within the search radius.

2. The one-dimensional mapping and positioning method for games according to claim 1, characterized in that, The specific process of constructing the coordinate system is as follows: Spatial coordinates are collected for game objects that require spatial positioning in the game to obtain initial coordinate data. Game objects include dynamic objects and static objects. A regular gridded game map is constructed based on preset size parameters, which are adapted to the needs of the game scene. A unified two-dimensional rectangular coordinate system is established, the preset vertices of the regular gridded game map are set as the coordinate origin, and the horizontal and vertical directions are set as the positive directions of the coordinate axes. This allows the initial coordinate data of the game objects to be mapped into the coordinate system, resulting in standardized coordinate data, where the coordinate values ​​are integers that conform to the range of the map grid. By associating standardized coordinate data with the unique identifiers of corresponding game objects, a coordinate-object association dataset is formed, thus establishing a unified coordinate system.

3. The one-dimensional mapping and positioning method for games according to claim 2, characterized in that, The process of obtaining the GeoHash encoding is as follows: Extract standardized coordinate data of game objects from the coordinate-object association dataset, and convert the x and y coordinates into binary numbers of a preset number of bits, padding the higher bits with 0 if the number of bits is less than the preset number of bits. The binary bits corresponding to the x and y coordinates are alternately extracted and combined in order from the most significant bit to the least significant bit to form the intermediate binary code. The intermediate binary code is split according to a preset unit length to obtain several binary units; Each binary unit is converted into a decimal number within the corresponding range. All decimal numbers are then concatenated sequentially to generate a GeoHash code adapted to the game scenario. The GeoHash code is then associated with and stored as a unique identifier for the game object.

4. The one-dimensional mapping and positioning method for games according to claim 3, characterized in that, The specific process of dividing the hot storage area and the cold storage area using the quadtree storage system is as follows: A quadtree storage structure is constructed based on the prefix length of the GeoHash encoding. Each node of the quadtree corresponds to a set of GeoHash codes with the same prefix. Extract the GeoHash code associated with the game object, truncate the code prefix according to the preset prefix length, and aggregate and store game objects with the same code prefix into the corresponding node of the quadtree; Set the location update frequency statistics period to count the number of times the spatial coordinates of each game object are updated within the statistics period in real time; Within each node of the quadtree, a hot storage area and a cold storage area are divided. The hot storage area uses a memory-first storage method, while the cold storage area uses a disk cache storage method. Game objects whose spatial coordinates are updated a preset number of times within the statistical period are assigned to the hot storage area of ​​the corresponding node, while game objects whose spatial coordinates are not updated within the statistical period are assigned to the cold storage area of ​​the corresponding node. An association index between the storage area and the game object is established.

5. A one-dimensional mapping and positioning method for games according to claim 4, characterized in that, The specific process for optimizing the retrieval accuracy is as follows: Obtain the search radius parameter from the location request, and use the exponential index optimization algorithm to establish a mapping relationship between the search radius and the GeoHash encoding prefix length; The target prefix length corresponding to the current search radius is calculated based on the mapping relationship. The search radius and the prefix length are negatively correlated. Based on the calculated target prefix length, the prefix portion of the GeoHash encoding corresponding to the center coordinates is extracted to form the target encoding prefix; If the number of matching nodes deviates from the suitable range during the retrieval process, the target prefix length is dynamically adjusted and node matching is performed again until the number of matching nodes is within the preset optimal retrieval range, thereby achieving dynamic optimization of retrieval accuracy.

6. The one-dimensional mapping and positioning method for games according to claim 5, characterized in that, The specific process of expanding the effective direction is as follows: Determine the basic directions for effective directional expansion. The basic directions are up and down, left and right, and the four diagonal directions. Obtain the position of the center coordinates in a unified coordinate system, and calculate the vertical distance from the center coordinates to the four boundaries of the game map; Each vertical distance is compared with a preset boundary threshold, and the expansion direction that exceeds the game map range is automatically cropped. For the remaining valid expansion directions, sequentially retrieve the quadtree nodes associated with the target encoding prefix in each direction to expand the retrieval coverage and ensure the comprehensiveness of neighbor object retrieval.

7. A one-dimensional mapping and positioning method for games according to claim 6, characterized in that, The specific process of encoding boundary completion is as follows: Identify the adjacent nodes of the quadtree node corresponding to the target coding prefix. The adjacent nodes are nodes whose coding prefixes differ only in their last bit. Perform supplementary searches on adjacent nodes to extract the spatial coordinate data of game objects stored in adjacent nodes; Calculate the actual straight-line distance between the game object obtained from the supplementary retrieval and the center coordinates; Game objects whose actual straight-line distance is less than or equal to the search radius are included in the candidate object set to eliminate retrieval blind spots across encoding prefix boundaries and ensure the integrity of positioning coverage.

8. A one-dimensional mapping and positioning method for games according to claim 7, characterized in that, The specific process of the multi-dimensional filtering is as follows: The system offers multiple preset filtering dimensions, including game object type, level range, faction affiliation, and interaction status. Sort the filtering dimensions according to preset priority; Receive user-defined filtering instructions, including dynamically adding or removing filtering dimensions, and adjusting the priority order of each dimension; Based on the sorted filtering dimensions, the game objects in the candidate object set are filtered layer by layer. The target type objects are filtered by object type, and the objects that meet the level requirements are filtered by level range, and the full-dimensional filtering is completed in sequence. A second distance check is performed on the filtered objects to exclude those that actually exceed the search radius, thus obtaining the final candidate objects.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is executed by a processor to implement a game one-dimensional mapping and positioning method according to any one of claims 1-8.

Images