Map design methods and related equipment

Abstract

This application discloses a map design method and related equipment. The method includes: dividing the layers within each level of an initial map into blocks to obtain multiple tiles for each layer; for each tile, calculating the geographic coordinates assigned to the tile based on its layer location information and intra-layer location information, where intra-layer location refers to the tile's orientation within its layer; loading and rendering the geographic coordinates and element arrangement information contained in the target tile area to display a map at a scale that meets the map display requirements. By using the concepts of hierarchy and block division to maintain the initial map, the initial map can achieve a more granular expression and processing in the form of tile composition, rather than being limited in size and unable to be freely scaled as in traditional methods. This application supports the unlimited expansion of the map's visible range while reducing the operational pressure and resource consumption caused by transmitting and processing large amounts of map data.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to map design methods and related equipment. Background Technology

[0002] In recent years, maps have been used and demanded more and more widely in electronic interfaces. For example, maps can be used to find out the location of enemy and friendly forces, plan movement trajectories, or build virtual game scenes.

[0003] The current method for designing maps is to pre-set the map size in the tile editor, and then the developer or artist imports the pre-set drawing content into the map project of the editor. After adjusting the node configuration in the tile map, the map can be displayed in use.

[0004] In actual gameplay, players often need to zoom in and out of the generated game map to adapt to different interface operation requirements. However, the map size produced by the above methods is fixed and does not support dynamic zooming in or out, failing to meet players' needs for zooming in and out at any time. Therefore, it is necessary to provide an effective solution. Summary of the Invention

[0005] This application provides a map design method and related equipment to meet users' needs for dynamic map scaling.

[0006] The first aspect of this application provides a map design method, including:

[0007] The initial map is divided into layers at each level to obtain multiple tiles for each layer; wherein, each layer is associated with the arrangement information of placeholder tiles according to a preset tile distribution rule, and each tile includes at least one graphic element among user icons, plant icons and building icons.

[0008] For each of the aforementioned map tiles, the geographic coordinates assigned to the map tile are calculated based on the layer location information and the intra-layer location information of the map tile. The intra-layer location refers to the orientation of the map tile within its respective layer.

[0009] The target tile area referred to in the map display request is determined, and the geographic coordinates and element layout information contained in the target tile area are loaded and rendered to display a scale map that conforms to the map display request; the view area of ​​the scale map is proportional to that of the initial map.

[0010] Optionally, the initial map supports adding tiles to form a larger map.

[0011] A second aspect of this application provides an electronic device, including:

[0012] Central processing unit, memory, and input / output interfaces;

[0013] The memory is either a short-term storage memory or a persistent storage memory;

[0014] The central processing unit is configured to communicate with the memory and execute instructions in the memory to perform the method described in the first aspect of the embodiments of this application or any specific implementation thereof.

[0015] A third aspect of this application provides a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the method described in the first aspect of this application or any specific implementation thereof.

[0016] A fourth aspect of this application provides a computer program product comprising instructions or a computer program, which, when run on a computer, causes the computer to perform the method described in the first aspect of this application or any specific implementation thereof.

[0017] As can be seen from the above technical solutions, the embodiments of this application have at least the following advantages:

[0018] By employing a hierarchical and tile-based approach to maintain the initial map, it enables more granular representation and processing of the map in the form of tiles, rather than the traditional map which is limited in size and cannot be freely scaled. Specifically, when faced with a request to zoom in on the map to display local features, the geographic coordinates and feature layout information contained in the target tile area are loaded and rendered to display the map at the required scale. This satisfies the request for infinitely expandable maps, supporting infinitely expandable map visibility, while simultaneously reducing the operational pressure and resource consumption caused by transmitting and processing large amounts of map data. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0020] It should be noted that although the steps in the flowcharts (if any) involved in the embodiments are drawn sequentially according to the arrows, unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts involved in the embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0021] Figure 1 This is a schematic diagram of a system architecture for the map design method according to an embodiment of this application;

[0022] Figure 2 This is a schematic flowchart of a map design method according to an embodiment of this application;

[0023] Figure 3 This is a schematic diagram of a map representing an embodiment of this application;

[0024] Figure 4 This is another schematic diagram of the map design method according to an embodiment of this application;

[0025] Figure 5 This is another schematic diagram of the map design method according to an embodiment of this application;

[0026] Figure 6 This is another schematic diagram of the map design method according to an embodiment of this application;

[0027] Figure 7 This is another schematic diagram of a map representing an embodiment of this application;

[0028] Figure 8 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0030] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] In the following description, expressions such as "one specific implementation" or "one specific example" describe a subset of all possible embodiments. However, it is understood that "one specific implementation" or "one specific example" can be the same or different subset of all possible embodiments and can be combined with each other without conflict. In the following description, the term "multiple" means at least two. When a certain value mentioned in this application reaches a threshold (if it exists), in some specific examples, it may include the former being greater than the latter. When "any" or "at least one" or similar expressions are mentioned, it specifically refers to any one of the listed examples or any combination of these examples.

[0032] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0033] Please see Figure 1 , Figure 1 A schematic diagram illustrating an application environment applicable to embodiments of this application is shown. The map design method provided in embodiments of this application can be applied to, for example... Figure 1The interactive system 100 shown includes a terminal device 101 and a server 102. The server 102 is communicatively connected to the terminal device 101. The server 102 can be a traditional server or a cloud server, without specific limitations. The terminal device 101 can be various electronic devices with a display screen that support data input, including but not limited to smartphones, tablets, laptops, desktop computers, and wearable electronic devices. Specifically, data input can be based on a voice module on the terminal device 101 to input voice, a character input module to input characters, or an image input module to input images. It can also be based on a gesture recognition module installed on the terminal device 101, allowing users to perform interactive methods such as gesture input. A client application can be installed on the terminal device 101, allowing users to communicate with the server 102 through the client application (e.g., an app, a mini-program), or to perform the aforementioned data input through the client application. Similarly, server 102 may also be deployed with a server-side application, which can work with the aforementioned client application to implement this method, such as processing map operation requests input by the client application, and returning a zoomed map to terminal device 101 for display.

[0034] The method described in this application will be further explained in detail below.

[0035] Please see Figures 2 to 3 The first aspect of this application provides a specific embodiment of a map design method, which includes the following operational steps:

[0036] 21. Divide the layers within each level of the initial map into blocks to obtain multiple tiles for each layer.

[0037] The layers are associated with the layout information of placeholder elements according to preset element distribution rules. These elements include at least one graphic element from user icons, plant icons, and building icons. For example... Figure 3 As shown, the area enclosed by the rectangular dashed frame can be regarded as a layer, which can be divided into four tiles; the initial map can also contain land or water map elements, and the specific types and quantities of map elements added to the map can be set by user needs or game scene.

[0038] One possible implementation is to start with a first layer centered within the initial map, and then expand outwards to create more layers, such as a second, third, etc., with each layer divided into multiple tiles of equal area. It should be noted that in practical applications, multiple layers can be expanded outwards from the center of the visual screen, rather than from the center of the initial map. Alternatively, multiple layers can be divided from left to right or from top to bottom; the method of layering the initial map is not limited. The areas of the tiles within each layer can also be unequal.

[0039] 22. Calculate the geographic coordinates assigned to each map tile.

[0040] For each tile, the geographic coordinates assigned to the tile are calculated based on its layer location information and intra-layer location information. Intra-layer location refers to the tile's position within its layer, such as its tile number within the first layer. For example, layer location information includes the layer level, such as first layer, second layer, etc., while geographic coordinates can specifically refer to the position coordinates in a two-dimensional Cartesian coordinate system or a three-dimensional coordinate system. Converting the layer and tile location information to Cartesian or three-dimensional coordinates here is to adapt to the front-end's signal processing configuration, thereby facilitating the successful display of the back-end map content on the front-end screen.

[0041] 23. Based on the geographic coordinates and element layout information contained in the map tiles, render the scale map to be displayed.

[0042] Determine the target tile area referred to in the map display request, load and render the geographic coordinates and element layout information contained in the target tile area to display a scale map that conforms to the map display request; the view area of ​​the scale map is proportional to that of the initial map.

[0043] In summary, the embodiments of this application maintain the initial map using the concepts of hierarchy and tile division, enabling the initial map to be expressed and processed with finer granularity in the form of tile composition, rather than being limited in size as in traditional maps and not supporting free scaling. Specifically, when faced with a request to zoom in on the map to display local features, loading and rendering the geographic coordinates and feature layout information contained in the target tile area allows for the display of the map at the required scale, thus satisfying the request for infinitely expandable maps. Simultaneously, it reduces the operational pressure and resource consumption caused by transmitting and processing large amounts of map data.

[0044] Based on the examples above, some specific possible implementation examples will be provided below. In practical applications, the implementation details of these examples can be combined as needed according to the corresponding functional principles and application logic.

[0045] Please see Figures 4 to 7This application provides another specific embodiment of the map design method, which includes the following operation steps:

[0046] 40. Divide the layers within each level of the initial map into blocks to obtain multiple tiles for each layer.

[0047] In some specific examples, the process of associating a layer with the layout information of placeholder elements according to preset element distribution rules includes: analyzing the element types and quantities required by the element distribution rules to obtain the allowed location nodes for each element, with each node supporting only one element; and determining the layout information of the placeholder elements in the layer nodes based on the initial placeholder area fed back by the element distribution rules and the analyzed node positions. The initial placeholder area can refer to the approximate location of a certain element, such as the lower right corner or the center.

[0048] In practical applications, large-scale map scenarios should include all registered users, with each user marked by a house. Furthermore, to ensure a certain degree of randomness and aesthetics, the location allocation process often requires the random generation of trees and empty spaces as decorative elements. Correspondingly, a hierarchical or block-based approach can be used to analyze the placement of these elements. For example, given the rule that "the number of trees in a block is greater than the number of users (i.e., the house icons in the attached diagram)," the probability distribution between trees and houses can be calculated as 3:1. Then, three random integers from 1 to 3 are generated based on this probability, and corresponding number of placement spaces (nodes) are allocated to these integers. Specifically, a value of 1 might be allocated only to users (i.e., houses in the diagram), a value of 2 to both users and trees, and a value of 3 to users, trees, and other elements, reserving one unused space as an empty node.

[0049] In this embodiment of the application, each node only supports the arrangement of one graphic element, that is, the occupancy between graphic elements is mutually exclusive, such as the mutually exclusive distribution positions between the tree and the user. This is because it is necessary to ensure that the positions occupied by each graphic element do not overlap or interfere with each other.

[0050] 411. Encode and compress the map tile information.

[0051] To reduce the size of the map data packets returned from the backend and alleviate the transmission pressure on network packets, map data compression optimization can be performed. Specifically, the geographic coordinates and primitive layout information contained in each tile of the initial map can be encoded according to the tile division method to obtain compressed map data for each tile; the compressed map data is used for decoding and rendering a scaled map. This compressed map data can be in the form of strings or vectors, etc.

[0052] Please see Figure 6 For example, the map is divided into equal-sized tiles (e.g., tiles with width2 = 20*20). The geographic information in each tile is encoded according to certain rules; for example, trees are encoded as 3, houses as 1, and no elements are encoded as 0 (the corresponding node can be considered an empty node). Using this encoding method, starting from the top-left corner of the tile, the entire tile is traversed in a certain order, and the information of the entire tile is encoded into a string (e.g., 03010103…00). Thus, the tile can be represented as a structure of a top-left corner coordinate and a string, thereby completing the data compression of the tile's data packet. For the front-end, after receiving this structure (i.e., top-left corner coordinates + a string) from the network, it learns the appearance of the block, its distribution location, and the composition of its constituent primitives, including their types, quantities, and positions. Then, according to the encoding rules, it parses the block's content and renders it. This rendering process displays different types of primitive data on the page with different behaviors (e.g., houses or trees). Furthermore, rendering restores data cached in compressed encoding (without coordinates) to its corresponding type of data with coordinates. In some examples, the top-left corner coordinates of the block (which can be considered node coordinates) can be determined by the block's layer position and its intra-layer coordinates.

[0053] Alternatively, the backend can decode and render the map data in the required format and provide it to the frontend, allowing the frontend to directly display the local or global map. In some examples, empty nodes can be filled with large blank squares to reduce the performance overhead of node creation.

[0054] 412. Compress map textures.

[0055] In practical applications, an image has four channels: R (red), G (green), B (blue), and A (transparency). The transparency channel, also known as the Alpha channel, stores a single value (0 for transparency, 1 for opacity), which manifests as transparency; for example, a black background indicates transparency. Therefore, by analyzing the layers, we can optimize the processing of the transparency channel in the compressed texture within the layer, i.e., remove the memory footprint of the transparency channel in the map, thereby further optimizing performance. Specifically, for areas within the initial map where the transparency value is preset, the transparency channel data for that area can be removed.

[0056] For example, the transparency of a map image in a certain area can be scanned to determine whether the image is 0; when generating compressed textures, for images with 0 transparency, some parameters can be set to cause the operating tool to extract only the RGB three-channel data of the image, so as to ensure that the generated texture data does not contain the transparency channel data.

[0057] 42. Calculate the geographic coordinates assigned to each map tile.

[0058] In some specific examples, the specific operation process of step 42 may include: selecting spare tiles from at least one layer, and generating a corresponding number of numbers according to the area size of the spare tiles to form a set of numbers for the spare tiles. The numbers are used to reflect the distribution location of the nodes that make up the tiles. For each tile, randomly extracting any number from the set of numbers without replacement, and calculating the geographic coordinates assigned to the tile based on the layer position information, the intra-layer position information, and the extracted numbers. If the number set of numbers is exhausted and empty, numbers are extracted from other non-empty number sets. The layer position information includes the level corresponding to the layer.

[0059] like Figure 5 As shown, when setting tile locations (assigning geographic coordinates), the concept of hierarchy can be maintained in the background service. For example, starting from the central area, more layers can be added outwards, with each layer dividing into tiles of equal size (e.g., 20 pixels in length and width). This can be summarized as follows: the xth layer can be divided into 8x-4 tiles. Taking the second layer as an example, the specific process for assigning geographic coordinates to each tile within the layer is as follows:

[0060] 1) The allocation process starts from the first layer at the center. After the allocation of this layer is completed, it is extended outward to the next layer in sequence, that is, to continue to allocate geographic coordinates to the tiles of the next layer.

[0061] 2) When allocating a layer, randomly select any block from all blocks in this layer as a spare tile. If the block is being allocated for the first time (i.e., it has not been allocated geographic coordinates before), generate a corresponding number of numbers (such as 400 integers from 0 to 399) according to the area size of the block (20*20=400). These numbers can be written into the set of the storage system, which can be regarded as completing the initialization of the block.

[0062] 3) If the block has been initialized, randomly select one or more integers from the existing set of numbers for the block, without replacing them with replacement. Based on the selected integer's index and the block's position (e.g., layer location information "level" and cell location information "block number within the layer"), calculate the block's geographic coordinates (x, y) in a two-dimensional or three-dimensional coordinate system. The conversion formula is (x, y) = f(level, cell, index). This completes one allocation process, yielding the block's assigned geographic coordinates (x, y). The existing set of numbers here can be understood as the remaining set of numbers formed when numbers in the initially generated set have been taken by other blocks; conversely, the original set of numbers may remain unchanged when facing this block, meaning no numbers have been taken.

[0063] As one possible implementation, the process of "extracting any number from the number set without replacement and calculating the geographic coordinates assigned to the tile based on the layer position information, intra-layer position information and the number taken" can specifically include: each tile taking a number from a non-empty number set generated from its own tile, tiles of the same layer or different layers; starting from the first layer centered in the initial map, calculating the geographic coordinates assigned to each layer of tiles layer by layer outward based on the layer position information, intra-layer position information and the number taken.

[0064] For example, if a set of numbers is exhausted and becomes empty, numbers are taken from other non-empty sets. This could be done by taking numbers from sets generated by other blocks within the same or different layers, thus supporting cross-layer numbering to calculate the geographic coordinates of the current layer's tiles. This is because the original set of numbers for tiles of equal area within each layer contains the same number of numbers, and the numbers within the set can be completely identical, such as all being 400 integers from 0 to 399. Another reason is that these 400 integers can be seen as ranking numbers among the 400 nodes within the block, their function being to more finely distinguish the positional relationships between nodes, indicating which node is which position within the block, thus facilitating subsequent location of which node is assigned a primitive. It is understandable that in the process of converting geographic coordinates (x, y), the layer position and intra-layer positional information, i.e., layer-level and block-level positional information, play a major or decisive role, while the node number plays a supporting role. Of course, the numbers within each set can also not be completely identical, depending on the actual situation.

[0065] In practical applications, it is not necessary to start the location assignment from the first layer. That is, the order in which the geographic coordinates are assigned to the tiles in each layer is not limited. For example, the coordinates of the second layer tiles can be assigned first, and then the coordinates of the first layer tiles can be assigned. Of course, they can also be executed simultaneously. The specifics depend on the actual scenario and are not restricted here.

[0066] 4) If the allocation process for each block in this layer is completed, the allocation for this layer is considered complete, and the process begins to extend to the next layer, repeating processes 2 and 3, until each block in each layer is assigned geographic coordinates.

[0067] The above processes 1) to 4) enable the scaling effect corresponding to the layered and block-based approach, allowing it to be widely applied to map display scenarios. Processes 1) to 4) can use distributed memory key-value pairs and Lua scripts to implement location allocation, ensuring that the allocated locations do not overlap.

[0068] 43. Based on the geographic coordinates and element layout information contained in the map tiles, render the scale map to be displayed.

[0069] In some specific examples, the process of loading the geographic coordinates and element layout information contained in the target tile area (loading data) may include: 1. For the first map display request, determine that the target tile area is a local map in the initial view area of ​​the initial map, and load all the geographic coordinates and element layout information contained in the local map to render a scaled map showing the local map elements; the initial view area refers to the preset envelope area around the center point of the screen view; 2. For viewpoint movement or zoom operation requests that occur based on the first map display request, determine the new target tile area pointed to by the latest request, traverse the new target tile area and its preset outer area to see if there are any unloaded areas to be loaded, until all the required geographic coordinates and element layout information are loaded and there are no areas to be loaded, then pass all the loaded data to the rendering layer to display a new scaled map with the elements of the new target tile area.

[0070] Due to the massive size of the map data, it can only be loaded in stages as needed to reduce the amount and time of network data transmission. Therefore, as... Figure 7 As shown, map data can be preprocessed and preloaded through the following process.

[0071] 1) When entering the map for the first time, load data of a certain area (e.g., area size 50*50) near the center point (e.g., the center point of the screen view) to meet the needs of the initial rendering and display of the map.

[0072] 2) Traverse the visible area: Calculate the loaded map data (including coded strings such as 0301, etc.) in 1.5 times the visible area (i.e., the initial view area, or the target tile area and its preset outer area), convert it into specific rendering data structures (such as trees, houses, etc.) and pass them to the rendering layer logic. At the same time, calculate whether there is any unloaded area size in the visible area. If there is, proceed to process 3; otherwise, proceed to process 4.

[0073] 3) Request the area data to be loaded in the visible area, and then proceed to process 2) to render the map data representation of the corresponding type (tree or house).

[0074] 4) Upon re-entering the map, wait for the user's view to move or zoom before proceeding to step 2).

[0075] In some specific examples, by rendering a size 1.5 times the user's visible area, nodes in non-visible areas can be dynamically recycled to achieve a node pooling solution suitable for map scenarios, thereby reducing the performance loss caused by constantly removing information from the parent set. In contrast, this parent set not only contains massive amounts of node data but also non-required data such as node timestamps and primitive timestamps. Therefore, a node pool needs to be built to selectively retrieve and store node data, avoiding redundancy or performance degradation caused by other non-required data. Specifically, the process of rendering the geographic coordinates and primitive layout information contained in the target tile area (rendering data) can include: treating the target tile area and the area outside its preset outer area as a non-view area, and recycling the node information of the non-view area to the node pool; if a view movement or zoom operation request occurs, the stored content of the node pool is updated, including extracting node information belonging to the new view area for loading and rendering the corresponding primitives, and recycling node information not belonging to the new view area to the node pool. Optionally, the radius of the preset outer area envelope can be greater than or equal to 0, depending on the needs.

[0076] For example, when a user moves, zooms in, or zooms out on the map, the visible nodes within the view area change accordingly. Therefore, from a performance perspective, a node recycling scheme can be adopted. This recycling process doesn't destroy the nodes and their information; instead, they are placed in a node pool. Later, when a new node needs to be added to the view area, its information is retrieved from the node pool for supplementary rendering. In other words, moving or zooming the map updates the stored content of the node pool. This node pool can be used for multiple operation requests, demonstrating high utilization during node pool reuse.

[0077] Steps 40, 42 to 43 are similar to steps 21 to 23, and will not be repeated here. The execution order of steps 411, 412, and 412 is not limited, and they can be executed simultaneously, depending on the actual situation. Compared to Figure 2 The example shown illustrates that the additional steps 411 and 412 are not necessarily required in practice. If more than two steps are added, they can be implemented in combination or individually, depending on the actual scenario.

[0078] Understandably, the above explanation can be summarized as follows: because map displays in large map scenarios should include all registered users, the backend service design may have the following requirements to provide a high-quality view: support for large-scale data storage, with a storage capacity of tens of millions or more; support for fetching thousands of data points at the minimum zoom level; and as the number of users grows, the map needs to expand outward from the central area while ensuring that user positions do not overlap. Accordingly, the overall design architecture of this method can be divided into two parts: writing to the map and reading from the map. The writing to the map part can be summarized as follows: a user initiates a registration request - the user's geographic element is assigned to a certain current layer - the user's geographic element is specifically assigned to a random tile in the current layer - the geographic element information (e.g., the element type is "user") and location information (layer position, intra-layer position) contained in the tile are extracted - the geographic element information and location information (can be compressed and recorded in an encoded form) and other map data are stored, thus successfully writing the user to the map; the reading to the map part can be summarized as follows: a user initiates a map display request - the corresponding cached content is read based on the ID information of the tile to be displayed - the cached content is rendered to display the map at the required scale.

[0079] The primary map storage can be a MongoDB database to store user locations and randomly generated tree and other element information. MongoDB's 2D index is used as the geographic location index to retrieve information near the target tile area (e.g., the center point of the front-end screen view). This information includes element information near the center point (e.g., element type "user" or "tree") and location coordinates (layer position, intra-layer position). If it's a house, it also includes user account information. This information is used to render map data so that the front-end can accurately display a map with elements such as houses and numbers. Since the front-end map is draggable, when the front-end is dragged to different positions (i.e., the target tile area changes), it needs to display map information near those different positions.

[0080] When reading the map, the map can first be divided according to the layer and block concepts mentioned above to convert the map into a fine-grained block representation. Then, the memory cache and distributed memory (KV) cache can be read according to the block ID. Finally, the main storage MongoDB is queried. If the query finds that the block has been allocated, the background service will generate data cache such as geographic coordinates and primitive information for it, and store it in the KV storage system with compression encoding.

[0081] In summary, after defining map generation rules (such as primitive distribution rules), map data can be obtained through corresponding algorithm operations. In this embodiment, when users view the map, optimizing network transmission packet size and compressed textures can significantly reduce data transmission pressure and improve network efficiency. Node pool reuse and local map rendering techniques are used to further optimize rendering performance, thereby meeting the performance and functional requirements of the game map. This includes supporting the dynamic, infinite expansion, contraction, or movement of the map. Compared to tilemaps, which have fixed map sizes, cannot dynamically expand or contract, only support one type of image, and cannot dynamically combine or transform images, this embodiment supports the combination or transformation of multiple image types. Furthermore, it reduces the manual workload and time required compared to tilemap solutions. Therefore, this embodiment considers data partitioning and rendering, supports infinite map expansion and contraction, allows customization of animation effects in the map (such as adding multiple primitive types), significantly improves data transmission efficiency, reduces network pressure, supports rapid expansion of map data capacity, and supports rendering pressure. Of course, a completely virtual map solution can also be used, where the requested backend data is not stored locally, thus greatly reducing the pressure on local storage.

[0082] Please see Figure 8 The electronic device 800 in this application embodiment may include one or more central processing units (CPUs) 801 and a memory 805, wherein the memory 805 stores one or more applications or data.

[0083] The memory 805 can be volatile or persistent storage. The program stored in the memory 805 can include one or more modules, each module including a series of instruction operations on the electronic device. Furthermore, the central processing unit 801 can be configured to communicate with the memory 805 and execute the series of instruction operations stored in the memory 805 on the electronic device 800.

[0084] Electronic device 800 may also include one or more power supplies 802, one or more wired or wireless network interfaces 803, one or more input / output interfaces 804, and / or one or more operating systems, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0085] The central processing unit 801 can perform the operations performed by the first aspect or any specific method embodiment of the first aspect, which will not be described in detail here.

[0086] This application provides a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the method as described in the first aspect or any specific implementation thereof.

[0087] This application provides a computer program product containing instructions or computer programs, which, when run on a computer, causes the computer to perform the method described in the first aspect or any specific implementation thereof.

[0088] It is understood that, in the various embodiments of this application, the sequence number of each step does not imply the order of execution. The execution order of each step should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0089] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system (if it exists) and device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0090] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system or apparatus, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0091] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0092] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0093] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product (computer program product) is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a business server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A map design method, characterized in that, include: The initial map is divided into layers at each level to obtain multiple tiles for each layer; wherein, each layer is associated with the arrangement information of placeholder tiles according to a preset tile distribution rule, and each tile includes at least one graphic element among user icons, plant icons and building icons. For each of the aforementioned map tiles, the geographic coordinates assigned to the map tile are calculated based on the layer location information and the intra-layer location information of the map tile. The intra-layer location refers to the orientation of the map tile within its respective layer. The target tile area referred to in the map display request is determined, and the geographic coordinates and element layout information contained in the target tile area are loaded and rendered to display a scale map that conforms to the map display request; the view area of ​​the scale map is proportional to that of the initial map.

2. The map design method according to claim 1, characterized in that, For each of the map tiles, the geographic coordinates assigned to the map tile are calculated based on the layer location information and intra-layer location information of the map tile, including: Select spare tiles from at least one of the layers, and generate a corresponding number of numbers according to the area size of the spare tiles to form a set of numbers for the spare tiles. The numbers are used to provide feedback on the distribution position of the nodes that make up the tiles. For each of the aforementioned map tiles, any number of numbers are extracted from the number set without replacement, and the geographic coordinates assigned to the map tile are calculated based on the layer position information, intra-layer position information, and the extracted number; wherein, if the number set of numbers is exhausted and becomes empty, numbers are extracted from other non-empty number sets, and the layer position information includes the layer level corresponding to the layer.

3. The map design method according to claim 2, characterized in that, The step of extracting any number without replacement from the number set and calculating the geographic coordinates assigned to the map tile based on the layer location information, intra-layer location information, and the extracted number includes: Each block is numbered from a non-empty set of numbers generated from its own blocks, blocks at the same level, or blocks at different levels. Starting with the first layer centered in the initial map, the geographic coordinates of each layer of map tiles are calculated layer by layer outwards based on the layer position information, intra-layer position information, and the number of the tile.

4. The map design method according to claim 1, characterized in that, The layer is specifically composed of multiple nodes; the process by which the layer is associated with the arrangement information corresponding to the placeholder elements according to a preset element distribution rule includes: By analyzing the primitive distribution rules, the primitive types and quantities required are determined, and the allowed locations of each primitive are obtained, with each node supporting only one primitive arrangement. Based on the initial occupancy area of ​​the graphic elements fed back by the graphic element distribution rules and the analyzed node positions, the arrangement information of the occupancy graphic elements in the layer nodes is determined.

5. The map design method according to claim 1, characterized in that, Before loading and rendering the geographic coordinates and feature layout information contained in the target tile region, the method further includes: According to the tile division method, the geographic coordinates and primitive layout information contained in each tile of the initial map are encoded to obtain the map compression data of each tile; the map compression data is used to decode and render a scale map.

6. The map design method according to claim 1, characterized in that, The process of loading the geographic coordinates and feature layout information contained in the target tile region includes: For the first map display request, the target tile area is determined to be a local map in the initial view area of ​​the initial map, and all geographic coordinates and primitive layout information contained in the local map are loaded to render a scaled map displaying the local map primitives; the initial view area refers to the preset envelope area around the center point of the screen view. For viewpoint movement or zoom operation requests that occur based on the initial map display request, determine the new target tile area pointed to by the latest request, traverse the new target tile area and its preset outer area to see if there are any unloaded areas to be loaded, until all the required geographic coordinates and primitive layout information are loaded and there are no unloaded areas, then transfer all the loaded data to the rendering layer to display the new scale map.

7. The map design method according to claim 1, characterized in that, The process of rendering the geographic coordinates and feature layout information contained in the target tile region includes: The area outside the target tile region and its preset outer area is designated as a non-view area, and the node information of the non-view area is recycled to the node pool. If a viewpoint movement or zoom operation request occurs, the stored content of the node pool is updated. The update includes extracting node information belonging to the new view area for loading and rendering the corresponding primitives, and reclaiming node information that does not belong to the new view area to the node pool.

8. The map design method according to claim 1, characterized in that, Before displaying a map at a scale that conforms to the map display request, the method further includes: For areas within the initial map where the transparency is a preset value, remove the transparency channel data for those areas.

9. An electronic device, characterized in that, include: Central processing unit, memory, and input / output interfaces; The memory is either a short-term storage memory or a persistent storage memory; The central processing unit is configured to communicate with the memory and execute instructions in the memory to perform the method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, Includes instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 8.

Images