Data editing method, device, medium and product based on grid map

Abstract

The embodiment of the application relates to the technical field of game map editing, and discloses a data editing method based on a lattice map. A lattice metadata class is acquired through an editor interface to generate corresponding lattice data structure; a lattice template is created according to the lattice metadata class, and map data of a specified size is generated based on the lattice template; the map data is loaded in a partition mode for editing; the map data is stored in a tuple mode to separate and save unique data and common data of the lattice; and the map data is saved to a specified format according to editing requirements. Metadata classes can be automatically written, the design of partition loading of the map guarantees the editing of a large side length map, and the saving mode of data separation effectively reduces the size of the map data. The lattice map editing complex technical problem can be solved at least.

Description

Technical Field

[0001] This application relates to the field of game map editing technology, and in particular to a data editing method based on grid maps. Background Technology

[0002] In developing grid-based map games, map data editing is a core step. Developers need to determine the layout of map elements before the game runs and dynamically adjust the map structure according to design requirements. While current mainstream game development engines (such as Unity) provide basic editor tools (Unity Editor), their specialized data editing capabilities for grid-based maps are significantly lacking.

[0003] Existing tools lack a mechanism for automatically generating grid metadata. Developers must manually write code to define grid attributes (such as type, label, display information, etc.), which is inefficient and prone to maintenance difficulties due to code redundancy. For 2D planar maps with custom side lengths, the lack of an intuitive visual editing interface makes it difficult to easily modify the attributes of individual grids or batches of areas, resulting in low map editing efficiency. When the map size is large, existing solutions cause severe editor lag if all map data is loaded, failing to meet the editing needs of complex maps. Summary of the Invention

[0004] One objective of this application is to provide a data editing method based on grid maps, which at least addresses the complex technical problems associated with grid map editing.

[0005] To achieve the above objectives, some embodiments of this application provide the following aspects:

[0006] In a first aspect, some embodiments of this application also provide a data editing method based on a grid map, including obtaining grid metadata through an editor interface and generating a corresponding grid data structure; creating a grid template based on the grid metadata and generating map data of a specified size based on the grid template; loading the map data in a partitioned manner for editing; storing the map data in a tuple pattern, separating and saving the unique data and common data of each grid; and saving the map data to a specified format according to editing requirements.

[0007] Secondly, some embodiments of this application also provide an electronic device, the electronic device comprising: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method described above.

[0008] Thirdly, some embodiments of this application also provide a computer-readable medium having computer program instructions stored thereon, which can be executed by a processor to implement the method described above.

[0009] Fourthly, some embodiments of this application also provide a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the method described above.

[0010] Compared with related technologies, the solution provided in this application embodiment can automatically write metadata, the partitioned map loading design can ensure the editing of large side-length maps, the data separation saving method can effectively reduce the size of map data, that is, the data in the editor will not be included in the game package, and the use of tuple mode to save map data can effectively reduce the size of map data. Attached Figure Description

[0011] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0012] Figure 1 This is a flowchart illustrating a data editing method based on a grid map according to an embodiment of this application;

[0013] Figure 2 This is a system architecture diagram of a grid map editor provided according to an embodiment of this application;

[0014] Figure 3 This is a schematic diagram of a data editing method based on a grid map according to an embodiment of this application;

[0015] Figure 4 This is a schematic diagram of the structure of grid map data provided according to an embodiment of this application;

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

[0017] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] First Embodiment

[0019] The first embodiment of this application relates to a data editing method based on a grid map. For example... Figure 1 As shown, the method may include the following steps:

[0020] S101: Obtain grid metadata through the editor interface and generate the corresponding grid data structure.

[0021] For example, in one possible implementation, users can define grid metadata in the editor interface, including basic grid attributes such as color, type, and accessibility. The corresponding data structure is automatically generated based on user input for subsequent map editing. Assuming a grid's metadata contains three attribute fields, it can be mapped to a lightweight data structure for fast in-memory reading and manipulation. This approach reduces the tedious work of manually writing data structures, improves development efficiency, and ensures the accuracy of the data structure.

[0022] S102, Create a grid template based on the grid metadata, and generate map data of a specified size based on the grid template.

[0023] Specifically, users can design multiple grid templates based on metadata, such as one template representing "grassland" and another representing "water," each with preset attribute values. Next, the system allows users to specify the map size, such as a map with a width and height of 50, and then quickly fills each grid position using the templates. The advantage of this approach is that template-based design significantly improves map generation efficiency while ensuring the consistency of grid attributes. Map data is loaded in a partitioned manner for editing.

[0024] S103, The map data is loaded in a partitioned manner for editing.

[0025] In one embodiment, the map is divided into multiple regions, each with a size of 10x10 grids, and only the data for the region currently being edited by the user is loaded. For example, when the user edits the top-left region, data for other regions remains unloaded, thereby reducing memory usage. Testing has shown that this method effectively avoids lag issues when editing large maps, improving editing smoothness.

[0026] S104, The map data is stored in tuple mode, separating and saving the unique data of each grid from the common data.

[0027] Map data is stored using a tuple schema, separating unique data for each cell from shared data. For example, the system stores shared data such as "grass type" for all cells in one set, while unique data for each cell, such as "location coordinates," is stored separately and indexed to the shared data set. Assuming a map has 1000 cells, only 10 types of shared data need to be stored, significantly reducing the amount of duplicate data storage and file size.

[0028] S105, Save the map data to the specified format according to editing requirements.

[0029] Specifically, the system supports saving map data in multiple formats, such as JSON for debugging or binary for loading during game runtime. Users can choose the appropriate format according to their needs, such as choosing JSON during the editing stage to view the data content, and choosing binary when publishing to improve loading speed. This flexibility ensures efficient data management and application.

[0030] Second Embodiment

[0031] The second embodiment of this application relates to a data editing method based on a grid map. The second embodiment is an improvement upon the first embodiment, specifically in that:

[0032] The editor interface retrieves grid metadata and generates the corresponding grid data structure, including:

[0033] Developers can input grid metadata attributes through the editor interface. For example, in a grid-based map editor, developers can input basic grid attributes such as grid type, color, and accessibility. Suppose a grid needs to be defined as "grass," its attributes might include a green color, passability (accessible), and no special effects. This attribute information can be directly entered through input boxes or dropdown menus in the editor interface, allowing developers to intuitively define the characteristics of each grid. This approach reduces the complexity of manual configuration and improves editing efficiency.

[0034] The system automatically generates code for the grid data structure based on the attribute information. For example, after inputting the attributes of the "grass" grid, the system automatically generates corresponding data structure code to describe the grid's fields and logical relationships. For instance, based on the input color and accessibility, the system generates a data class containing these attributes, ensuring that subsequent programs can recognize and call these attributes. This automation avoids the risk of developers manually writing tedious code while ensuring the consistency and accuracy of the data structure.

[0035] The code retrieves the specific fields and values ​​of the grid metadata through the grid data structure. The generated code then uses reflection to read the fields of the "grass" grid, such as the color field being green and the accessibility field being 1. These fields and values ​​are parsed and stored by the system for later use in map editing or game runtime. This design ensures the dynamism and scalability of the data, facilitating subsequent editing.

[0036] The fields and values ​​are mapped to the editor interface for display and editing. For example, the value of the "grass" cell field will be directly displayed on the editor interface, allowing developers to check if the color is the expected green or if the passability meets design requirements. If problems are found, adjustments can be made directly on the interface. This mapping mechanism makes data editing more intuitive and reduces the probability of errors.

[0037] If the fields and values ​​need adjustment, the attribute information is updated and the code is regenerated through the editor interface to determine the grid data structure for subsequent map generation. For example, if the developer changes the accessibility of the "grass" grid from passable to impassable, the editor will regenerate the data structure code based on the updated information, ensuring that the adjusted attributes take effect in real time. This dynamic update mechanism guarantees design flexibility. Finally, the grid data structure is determined for subsequent map generation. Specifically, the confirmed "grass" grid data structure will be saved as a standard template for batch use during map generation.

[0038] Create a grid template based on the grid metadata definition, and generate map data of a specified size based on the grid template, including:

[0039] Configure the attributes and styles of grid templates based on the grid metadata. For example, in one possible implementation, assuming the grid metadata defines attributes such as terrain type, color, and accessibility, a grid template for a forest terrain could be set to green as the main color and accessibility to 50%, indicating that character movement will be somewhat hindered. This configuration intuitively reflects terrain characteristics, facilitating quick identification of different grid functions during subsequent map design. During style configuration, borders or icon effects can be added to the grids; for example, forest grids could display small tree icons, enhancing visual recognizability in the editor. This improves editing efficiency while ensuring template reusability and reducing repetitive design work.

[0040] By batch filling grid data using the grid template, for example, in an 80x80 map area, a forest template can be selected to fill a specified area at once, such as setting the entire top-left 20x20 area as forest grids. This batch operation can greatly save editing time, especially when dealing with large areas of similar terrain. Batch filling can also be combined with randomization parameters, such as randomly distributing some impassable shrub grids within the forest area to increase the realism of the map. This approach ensures efficiency while enhancing map diversity through subtle changes, meeting design requirements.

[0041] Obtain the map's size parameters and generate complete map data based on these parameters and the grid template. For example, when designing a game level, the designer might set the map size to 100x100 grid units to suit the level's storyline. The size parameters can be adjusted based on device performance or game type; for instance, mobile games might be limited to 50x50 to ensure smooth gameplay, while PC games could expand to 200x200. Clearly defining the size range helps optimize subsequent data generation and partition loading, avoiding resource waste and ensuring the map size aligns with the design goals.

[0042] If the map data requires local adjustments, individual cells can be edited through the editor interface to obtain a map data structure that meets design requirements. For example, in the center of the map, the designer might need to manually adjust a cell to be a special event trigger point, such as setting it as a portal, and changing its color to purple for distinction. The individual cell editing function allows for fine-tuning, ensuring that map details conform to the design intent without affecting the overall integrity of other areas. This flexibility is particularly important for creating personalized levels, significantly enhancing the map's expressiveness. After all editing is complete, the map data is integrated into a complete structure containing terrain, attribute, and event information, such as saving the coordinates and attribute values ​​of each cell in JSON format. This structured data is easy for the game engine to read and supports subsequent expansion, such as adding new event layers or dynamic effects. The final data formation ensures a seamless transition from design to implementation, providing reliable support for game development.

[0043] The map data is loaded for editing using a partitioned approach, including: dividing the map data into multiple regions based on its total size; obtaining the range parameters of the current editing region; loading only the map data corresponding to the range parameters into the editor interface; editing the grid data within the current editing region through the editor interface; if the editing region is switched, loading the map data of the corresponding region based on the new range parameters; and completing the editing of the map data region by region using the partitioned loading method.

[0044] The map data is divided into multiple regions based on its total size. For example, a very large map with a width and height of 200 squares can be divided into 16 regions, each 50 squares by 50 squares. This division method aims to manage the massive map data in blocks, reducing the amount of data loaded at a time and thus improving the editor's efficiency. When dividing the regions, the size can be adjusted according to hardware performance or editing needs. For instance, on lower-performance devices, regions can be reduced to 30 squares by 30 squares to further reduce loading pressure. This approach allows for flexible adaptation to editing needs in different scenarios, ensuring smooth operation.

[0045] Obtain the range parameters of the current editing area. Specifically, assuming the current editing area is the first area in the upper left corner of the map, its range parameters can be defined as x-coordinate 0 to 50 and y-coordinate 0 to 50. By obtaining these parameters, the system can clearly define the range of data to be loaded, avoiding interference from irrelevant data. The advantage of this method is that it accurately locates the editing area, reduces resource waste, and provides a clear basis for subsequent loading.

[0046] Only the map data corresponding to the specified range parameters is loaded into the editor interface. In one embodiment, when the editing area is defined as x-coordinate 0 to 50 and y-coordinate 0 to 50, the editor only loads the data for these 2500 cells, instead of loading the entire map's 40000 cells. This selective loading significantly reduces memory usage, especially when processing large maps. The rationale for this approach is to avoid lag caused by loading too much data at once, thus improving the editing experience.

[0047] The user can edit the grid data within the current editing area through the editor interface. For example, within the current area, the user can edit the terrain type grid by grid or apply templates in batches, such as setting an area as a forest terrain. This method supports both fine-grained editing and efficient batch operations, meeting different editing needs. Its advantages include improved editing flexibility and time savings.

[0048] If the editing area is switched, the map data for the corresponding area is loaded according to the new range parameters. For example, when the user switches from the first area to the second area (x-coordinate 50 to 100, y-coordinate 0 to 50), the system unloads the data from the previous area and loads only the 2500 cells of the new area. This dynamic loading method keeps the editor under low load, ensuring smooth operation. Its purpose is to support seamless area switching and improve the user experience.

[0049] The map data is edited region by region using a partitioned loading method. In one embodiment, the user can edit each region sequentially from left to right and top to bottom to complete the entire map. This approach breaks down a large task into smaller ones, reducing editing difficulty, while maintaining stable system performance through partitioned loading, making it particularly suitable for editing very large maps.

[0050] The map data is stored using a tuple schema, separating and saving cell-specific data from shared data. This includes: extracting the data content of each cell in the map data; dividing the data content into cell-specific data and shared data; establishing a unified set storage for the shared data; assigning an index value pointing to the shared data to each cell; storing the cell-specific data separately in the corresponding cell; and combining the index value and the cell-specific data to form a complete cell data representation.

[0051] Extracting data from each grid cell in the map: This step involves comprehensively collecting information from every grid cell in the map to form a complete dataset. For example, in a game map, each grid cell might contain information such as terrain type, resource distribution, and whether it is passable. We can iterate through each grid cell of the map, recording this information one by one to form an initial data table, preparing for subsequent classification. The purpose of this is to ensure data integrity, avoid missing key information, and lay the foundation for subsequent separation and storage.

[0052] Dividing the data into cell-specific and shared data: This step categorizes the extracted data, distinguishing which data is shared across multiple cells and which is unique to a specific cell. For example, terrain types like "grassland" might be shared by multiple cells, while resource quantities like "5 units of wood" are unique to a particular cell. Categorization reduces redundant storage and improves data efficiency. This separation method significantly reduces data redundancy, providing a basis for subsequent storage optimization.

[0053] Establish a unified collection for common data: After classification, store the common data in a unified collection. For example, store all terrain types such as "grassland" and "desert" in a list, recording each type only once. This approach avoids repeatedly storing the same data, saving space. The benefits of centralized storage include easier management and maintenance, and convenience for subsequent indexing.

[0054] Assigning an index value pointing to shared data to each cell: This step involves assigning an index value to each cell that points to the set of shared data. For example, if a cell is "grass," its index value points to the location of "grass" in the set. This way, only a single number needs to be stored to represent complex shared information, significantly reducing the amount of data. The introduction of an indexing mechanism is key to data compression and can effectively improve storage efficiency.

[0055] Storing unique data for each cell individually: For data unique to each cell, such as resource quantity or special markers, it is stored directly in the cell's own data structure. For example, a cell storing "5 units of wood" requires no additional index. This method ensures the independence of unique data, facilitating quick access and modification.

[0056] A complete grid data representation is formed by combining index values ​​and unique data. Finally, the index values ​​and unique data are combined to reconstruct the complete grid information. For example, by finding "grassland" using the index value and combining it with the unique data "5 units of wood," the grid can be fully described. This combination method saves storage space, ensures data integrity, and enables rapid data restoration when editing and loading maps, thus improving system performance.

[0057] The step of saving the map data to a specified format according to editing needs includes: acquiring the edited map data; distinguishing between editor-specific data and game running data according to the editing environment; separating the editor-specific data from the game running data; selecting a storage format for the game running data; saving the game running data to a target file using the storage format; and if cross-platform use is required, adjusting the storage format according to the target platform and resaving the game running data.

[0058] Retrieving the Edited Map Data: This step involves integrating the final map data into a single dataset after all data editing is complete in the map editor. For example, in a grid-based map editor, assuming the map size is 100x100 grids, each grid contains information such as terrain type and object location. After editing, the system will extract this data from the editor's memory, forming a complete data structure for subsequent processing. This ensures data integrity and lays the foundation for subsequent separation and saving.

[0059] The game distinguishes between editor-specific data and game-running data based on the editing environment: Specifically, the editor contains data used only for editing, such as grid names and editor display styles, while the game only needs core information such as terrain data and object positions. For example, a grid might be labeled "Test Area" in the editor, but this information is not needed in the game. The purpose of distinguishing these data is to reduce the game package size and improve running efficiency.

[0060] Separate editor-specific data from game runtime data: For example, in an 80x80 map, editor-specific data might account for 20% of the total data. By separating them, this data can be stored locally in the editor instead of being packaged into the game files. The benefit of this is a significant reduction in game data size and optimized loading speed.

[0061] Choosing a storage format for game runtime data: In one possible implementation, developers can choose JSON format for easier debugging or binary format for faster loading, depending on their needs. For example, JSON format is suitable for viewing data during cross-platform development, while binary format is more suitable for scenarios where performance is paramount. Choosing the appropriate format can effectively balance development efficiency and runtime performance.

[0062] Save game runtime data to a target file using a specific storage format: for example, save the game runtime data as a binary file and store it in a designated path to ensure fast readability during game runtime. This method guarantees data security and read efficiency, providing stable support for the game.

[0063] If cross-platform use is required, the storage format should be adjusted according to the target platform, and the game runtime data should be saved again. For example, a smaller file size may be needed on mobile devices, so the data is converted from JSON to a compressed binary format, while on PCs, the JSON format may be retained for debugging. The purpose of adjusting the format is to adapt to the characteristics of different platforms and ensure efficient use of data across platforms.

[0064] The step of obtaining grid metadata definitions through the editor interface and generating corresponding grid data structures includes: configuring the name and type of metadata through the editor interface; generating corresponding attribute fields based on the name and type; constructing a framework of the grid data structure through the attribute fields; obtaining the display characteristics of each field in the framework; presenting the grid data structure in the editor interface according to the display characteristics; and adjusting the display characteristics and updating the grid data structure if the display characteristics do not meet the requirements.

[0065] When configuring metadata names and types through the editor interface, developers can define basic grid attributes in the visual interface. For example, they can create an enumeration attribute named "Terrain Type," containing three types: grassland, desert, and water. They can also define movement costs as integers, with a value range of 1 to 10. This configuration method allows non-programmers to participate in map design, greatly improving development efficiency.

[0066] During the process of generating corresponding attribute fields based on the name and type, the system automatically converts the configuration information into structured data fields. Specifically, after defining the terrain type enumeration, the system generates corresponding attribute fields and assigns default values, while creating corresponding numeric fields for the movement consumption integer type to ensure data consistency and integrity.

[0067] When constructing the framework of the grid data structure using the attribute fields, the system organizes the individual attribute fields into a complete data structure. For example, multiple fields such as terrain type, movement cost, and passability can be integrated into a complete grid data class, forming a unified data access interface to facilitate subsequent data operations and management.

[0068] During the stage of obtaining the display characteristics of each field in the framework, the system analyzes the data type and constraints of each field to determine its display format in the editor. In one embodiment, enumeration type fields are identified as drop-down selection boxes, numeric type fields are configured as sliders or input boxes, and boolean types are displayed as checkboxes. This automatic recognition mechanism ensures the intuitiveness of the editing interface.

[0069] When the grid data structure is presented in the editor interface according to the display characteristics, the system generates corresponding UI controls based on the field characteristics. Preferably, for the movement consumption field, the system generates a slider ranging from 1 to 10, allowing users to intuitively adjust the value and preview the effect in real time. This visual editing method significantly reduces the complexity of data configuration.

[0070] The adjustment mechanism for situations where the described display characteristics do not meet requirements allows developers to modify the display method of fields according to actual needs. It should be noted that when the default slider does not meet the requirements for precise input, it can be adjusted to a numeric input box, or an icon can be added to the enumeration field. This flexible adjustment mechanism ensures that the editor can adapt to the specific needs of different projects, improving the tool's versatility and usability.

[0071] Third Embodiment

[0072] The third embodiment of this application relates to a data editing method based on a grid map. The third embodiment is an improvement upon the first embodiment, specifically in that:

[0073] like Figure 2 As shown, a GBME system was designed based on Unity Editor and Odin Inspector. The architecture revolves around a three-layer design: data layer, control layer, and interaction layer. The core solution is to address the issues of editing efficiency, performance optimization, and data simplification of grid map data. Through layered decoupling, it achieves data storage separation, automated processing logic, and visualized interactive operations.

[0074] The data layer distinguishes between game runtime data and editor auxiliary data, while maintaining code templates to provide a foundation for automated generation. The code side includes: grid classes, defining the basic attributes of grids and serving as the structural template for game data; and extended template classes, defining reusable grid combinations that support batch drawing. The data side includes: game data, containing specific grid data, specific map data, and extended data, which is the core data for game runtime; and editor data, containing specific grid displays and specific map displays. Shared displays (reused display configurations, such as a unified display style for "grass") are not included in the game package release to avoid package redundancy.

[0075] The control layer is used for automated processing, connecting data and interaction. As the central hub for data processing, it enables automatic code generation, data storage / compression, and template management, solving problems such as inefficiency from manual coding and performance bottlenecks in large maps. Automated generation of grid metadata code parses the grid class structure through attribute tags, automatically generating metadata with serialization characteristics, significantly improving development efficiency. Grid template data storage and retrieval supports template drawing functions (such as one-click drawing of an entire forest) by reading and writing batch grid combinations defined in the extended template class. Data compression / restore performs partitioned compression on large map data, combined with partitioned loading in the interaction layer, solving lag issues during editing. Map data storage and retrieval supports multi-format export (JSON, Asset, binary) to adapt to different deployment scenarios (e.g., JSON for hot updates, Asset for local debugging). Extended data generation / storage is similar to the grid metadata process, automatically generating code for custom extended attributes and managing their storage to meet customized business needs.

[0076] The interaction layer is used for visual editing, reducing operational costs and providing a WYSIWYG editing interface, allowing developers to intuitively manipulate grid attributes and map layout. The grid metadata editing area includes: grid metadata editing for visually configuring basic grid attributes (such as type and label), which is mapped in real-time to the code generation logic of the control layer; and grid template editing for editing reusable grid combinations (such as "town modules"), linked to the template access functionality of the control layer. The map data editing area includes: map drawing supporting single-grid editing and batch template drawing (using grid template data access), allowing direct modification of game data; and data extension configuration for custom business attributes (such as grid event triggering logic), linked to the extended data management of the control layer.

[0077] The process of using GBME is as follows: Open the editor application, edit the metadata of the grid, create a grid template based on the metadata, generate a map of the specified size, and fill it using the grid template. When data expansion is required, edit the metadata of the additional data, edit the corresponding metadata, generate a map of the specified size, fill it using the grid template, and obtain the final grid map.

[0078] like Figure 3 As shown, when automatically generating grid metadata code, this generated code leverages C# emission features to retrieve attributes from the metadata and display them in the editor, where the specific values ​​for the corresponding attributes are entered. For example, a grid class includes a class name, a name, and a list of metadata. The metadata includes name, type, tags, and some easily displayed attributes; some are built into the Unity Editor, while others are provided by the Odin Inspector. The corresponding code is generated based on the grid's metadata. The Unity Editor is part of the Unity engine, providing developers with a set of tools for customizing and extending Unity; the Odin Inspector is a Unity engine plugin used to assist in customizing and extending Unity.

[0079] When drawing maps, you can edit data cell by cell or use the brush mode to import template cells in batches for drawing. Maps are loaded in partitions, allowing you to load only a specific area. The size of each area is controllable. Saved data is separated based on whether it's used solely in the editor; for example, cell names and display information in the editor are saved in the editor data and will not appear in the game.

[0080] like Figure 4 As shown, map data is stored using a tuple schema, which categorizes and stores data shared by each cell into unique data. Shared data is stored as a set, duplicate data is removed, and then an index is added to each cell to point to the stored shared data. As illustrated, the number of shared data points, n, is much smaller than the number of cells, m. The final saved map data supports multiple formats, such as JSON, asset, and binary, including the most basic map data.

[0081] Map data can include width and height, i.e., the maximum number of cells per row and column. Cell data (stored as a list) includes: cell index, which can be converted to coordinates on the map (x = index / height, z = index % height); cell length and width (the default cell is a square with a side length of 1, but custom width w and height h are also supported; in this case, the cell can be viewed as w*h cells with a side length of 1 joined together), and the cell index represents the index of the top-left cell; pathfinding information, pre-calculated using the A* algorithm, which is then reused during game execution to "trade space for time" (avoiding redundant calculations); unique data, distinguished by metadata tags, representing attributes unique to a single cell (their existence is determined by the business scenario); and shared data index, distinguished by metadata tags, storing the index values ​​of the shared data list (enabling data reuse and reducing redundancy). All shared map data is stored as a list.

[0082] The editor configures and manages the interface layout and editing parameters, providing configuration support for the partition loading and compression strategies of the control layer. For example, in the interaction layer: the user selects the "Forest Template" in the map drawing module and sets the drawing area. The control layer responds by calling the grid template data storage and loading the template; combining data compression and restoration to determine whether the target area needs partition processing; and updating the data layer by instantiating the template data into specific grid data (game data) while recording the specific grid display (editor data, used only for editing and previewing).

[0083] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0084] Furthermore, some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices.

[0085] The electronic device includes: one or more processors; and a memory storing computer program instructions that, when executed, cause the processor to perform the steps of the methods provided in any one or more of the above embodiments. Figure 5 An exemplary structural diagram of the electronic device is disclosed. For example... Figure 5 As shown, the electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise as required. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0086] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103, and output device 1104 may be connected via a bus or other means. Figure 5 Taking the example of a connection between China and Israel via a bus.

[0087] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display (LCD), a light-emitting diode (LED) display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0088] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0089] In this embodiment, a computer-readable medium stores a computer program / instructions that, when executed by a processor, implement the steps of the methods provided in any one or more of the above embodiments. This computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into that device. The aforementioned computer-readable medium carries one or more computer-readable instructions.

[0090] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0091] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0092] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0093] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, read-only optical disc (CD-ROM), digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0094] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0095] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the steps or functions described above. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, or similar devices. Furthermore, some steps or functions of this application can be implemented in hardware, for example, as circuitry that works with a processor to perform the various steps or functions.

[0096] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0097] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0098] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device in software or hardware. Terms such as "first," "second," etc., are used only for distinguishing descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0099] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A data editing method based on grid maps, characterized in that, The method includes: The process involves obtaining grid metadata through an editor interface and generating a corresponding grid data structure. This includes: inputting attribute information of the grid metadata through the editor interface; automatically generating code for the grid data structure based on the attribute information; obtaining specific fields and values ​​of the grid metadata through the code of the grid data structure; mapping the fields and values ​​to the editor interface for display and editing; and updating the attribute information and regenerating the code through the editor interface if the fields and values ​​need to be adjusted, thereby determining the grid data structure for subsequent map generation. Configure the name and type of metadata through the editor interface, and generate corresponding attribute fields based on the name and type; construct a framework of grid data structure through the attribute fields, and obtain the display characteristics of each field in the framework; present the grid data structure in the editor interface according to the display characteristics; if the display characteristics do not meet the requirements, adjust the display characteristics and update the grid data structure. A grid template is created based on the grid metadata, and map data of a specified size is generated based on the grid template; The map data is loaded in a partitioned manner for editing; The map data is stored using a tuple schema, separating and saving the unique data and shared data of each cell. This includes: extracting the data content of each cell in the map data and dividing the data content into cell-specific data and shared data; establishing a unified set storage for the shared data and assigning an index value pointing to the shared data to each cell; storing the cell-specific data separately in the corresponding cell, and combining the index value and the unique data to form a complete cell data representation. Save the map data to the specified format according to the editing requirements.

2. The method according to claim 1, characterized in that, The step of creating a grid template based on the grid metadata and generating map data of a specified size based on the grid template includes: Configure the attributes and style of the grid template according to the grid metadata, and then fill the grid data in batches using the grid template; Obtain the map's size parameters, and generate complete map data based on the size parameters and the grid template; If the map data needs to be adjusted locally, the specific grid can be edited individually through the editor interface to obtain the map data structure.

3. The method according to claim 2, characterized in that, The method of loading the map data in a partitioned manner for editing includes: Divide the map data into multiple regions based on the total size of the map data, obtain the range parameter of the current editing region, and load only the map data corresponding to the range parameter into the editor interface; The grid data within the current editing area can be edited through the editor interface. If the editing area is switched, the map data of the corresponding area is loaded according to the new range parameters. The map data is edited area by area by area through the partition loading method.

4. The method according to claim 1, characterized in that, The step of saving the map data to a specified format according to editing needs includes: Acquire the edited map data and distinguish between editor-specific data and game runtime data based on the editing environment; Separate the editor-specific data from the game runtime data, and select a storage format for the game runtime data; The game running data is saved to the target file using the aforementioned storage format; if cross-platform use is required, the storage format is adjusted according to the target platform and the game running data is saved again.

5. An electronic device, characterized in that, The electronic device includes: One or more processors; and A memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method as described in any one of claims 1 to 4.

6. A computer-readable medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 4.

7. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method described in any one of claims 1 to 4.

Images