Method and program product for editing a game map

Abstract

The present disclosure provides a game map editing method and program product, in the case of a game map in a draft state, a plurality of sub-stages included in the game map are respectively assigned corresponding first identifiers; in response to an association relationship configuration instruction, association relationship configuration information is determined; in response to a release instruction of the game map, a corresponding map instance of each sub-stage is generated, wherein each map instance is respectively assigned a corresponding second identifier, and the second identifier is used to locate the corresponding map instance at runtime; a mapping relationship between the first identifier and the second identifier is established; when the game map is in a running state, the first identifier carried in the jump request is parsed into the corresponding second identifier according to the mapping relationship, and the corresponding map instance is located according to the determined second identifier. The author can complete the design of multi-stage jump logic in full draft state at one time without waiting for the release to backfill dynamic instance identifier.

Description

Technical Field

[0001] This disclosure relates to the field of games, and in particular to a method, apparatus, electronic device, and program product for editing game maps. Background Technology

[0002] In related technologies, when authors complete multi-level chaining within the editor, they typically need to first publish each sub-level as an independent map instance, and then have the platform backend assign corresponding map identifiers to each instance. Subsequently, the author needs to query the map identifiers of each published instance in an external data dashboard, return to the editor, and hard-code this map identifier as a parameter for the cross-instance transmission interface in the jump logic script. After completing the above configuration, the map instance containing the jump logic must be republished for the cross-level jump relationship to take effect on the runtime side.

[0003] However, since configuring cross-level jump relationships within the editor requires based on map markers after publication, the draft state cannot complete the connection in advance, resulting in coupling of the creation and publication process. Modifications require multiple publications and re-filling, which in turn leads to a lack of verification of level logic before publication, resulting in poor production efficiency and creative continuity of multi-level content. Summary of the Invention

[0004] The purpose of this disclosure is to provide a method, device, electronic device, and program product for editing game maps, in order to solve the problem of coupled creation and publishing processes and the inability to pre-configure cross-level jump relationships in the draft state when multiple levels of a game map are linked together.

[0005] In a first aspect, this disclosure provides a method for editing a game map, comprising: when the game map is in a draft state, controlling the assignment of corresponding first identifiers to multiple sub-levels included in the game map; in response to an association configuration instruction, determining association configuration information, wherein the association configuration information is configured based on the first identifiers and is used to describe the cross-level jump relationship between multiple sub-levels; in response to a game map publishing instruction, controlling the generation of map instances corresponding to each sub-level, wherein each map instance is assigned a corresponding second identifier, the second identifier being used to locate the corresponding map instance at runtime; establishing a mapping relationship between the first identifier and the second identifier; when the game map is in a running state, resolving the first identifier carried in the jump request to the corresponding second identifier according to the mapping relationship, and locating the corresponding map instance according to the determined second identifier.

[0006] Secondly, this disclosure provides an information processing apparatus, comprising: an allocation module configured to, when the game map is in a draft state, control the allocation of corresponding first identifiers to multiple sub-levels included in the game map; a configuration module configured to, in response to an association configuration instruction, determine association configuration information, wherein the association configuration information is configured based on the first identifiers and is used to describe the cross-level jump relationship between multiple sub-levels; a publishing module configured to, in response to a publishing instruction of the game map, control the generation of map instances corresponding to each sub-level, wherein each map instance is allocated a corresponding second identifier, the second identifier being used to locate the corresponding map instance during runtime; an establishment module configured to, establish a mapping relationship between the first identifiers and the second identifiers; and a running module configured to, when the game map is in a running state, parse the first identifier carried in the jump request into the corresponding second identifier according to the mapping relationship, and locate the corresponding map instance based on the determined second identifier.

[0007] Thirdly, this disclosure provides an electronic device including a processor and a memory, wherein the processor executes instructions in the memory to perform the steps in any of the above-described methods for editing a game map.

[0008] Fourthly, this disclosure provides a computer program product that stores a computer program, which, when executed by a processor, performs the steps in any of the above-described methods for editing a game map.

[0009] This disclosure provides a method, apparatus, electronic device, and program product for editing game maps. By assigning a corresponding first identifier to sub-levels in the draft state and configuring cross-level jump relationships between multiple sub-levels based on the first identifier, the complete design of multiple levels can be completed in the draft state without the need for any sub-levels to be pre-released during the creation phase. This decouples logical creation from platform release and reduces the number of release re-fillings. At the same time, based on the mapping relationship between the first and second identifiers, the first identifier in the jump request is parsed at runtime to locate the corresponding map instance, ensuring accurate execution of cross-map instance jumps and improving the interactive experience. The multi-level jump logic can be completely configured in the draft state, enhancing the organizational flexibility and level association depth of multi-level content under the state synchronization architecture and improving the richness of the game. Furthermore, by establishing and maintaining the mapping relationship between the first and second identifiers, the draft state identifier system and the runtime identifier system are effectively isolated, solving the computer domain problem of process coupling and high iteration costs caused by the mixing of creation state and runtime identifiers during game map editing. Attached Figure Description

[0010] 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 of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A schematic diagram of a system architecture according to an embodiment of this disclosure is shown; Figure 2 A flowchart illustrating a method for editing a game map according to an embodiment of this disclosure is provided. Figure 3 A schematic diagram of a map sub-level management interface is shown in an embodiment of this disclosure; Figure 4 A schematic diagram of a game map editing device according to an embodiment of the present disclosure is shown; Figure 5 A schematic diagram of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0012] Exemplary embodiments of this disclosure will be described more fully below with reference to the accompanying drawings.

[0013] The accompanying drawings are schematic illustrations of this disclosure and are not necessarily drawn to scale. Some block diagrams shown in the drawings may be functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in hardware modules or integrated circuits, or in networks, processors, or microcontrollers. Implementations can be carried out in various forms and should not be construed as limited to the examples set forth herein. The features, structures, or characteristics described in this disclosure can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough description of embodiments of this disclosure. However, those skilled in the art will recognize that one or more specific details may be omitted when implementing the technical solutions of this disclosure, or other methods, components, apparatuses, steps, etc., may be used to replace one or more specific details.

[0014] To make the objectives, technical solutions, and advantages of this disclosure clearer, the embodiments of this disclosure will be described in further detail below with reference to the accompanying drawings.

[0015] Figure 1A system architecture diagram of the operating environment of this embodiment is shown. This system architecture may include a first client 110, a second client 120, and a server 130. The first client 110 and the second client 120 are terminal devices that have installed and run game client programs, such as mobile phones, tablets, personal computers, smart wearable devices, game consoles, etc. They have display functions and can display a graphical user interface, which may include the operating system interface or the application interface. The first client 110 is the client used by the first game account, and the second client 120 is the client used by the second game account; that is, the game client program running on the first client 110 is logged into the first game account, and the game client program running on the second client 120 is logged into the second game account. The server 130 generally refers to the backend system providing game services in this exemplary embodiment; it can be a single server or a cluster of multiple servers. A game server program is deployed on the server 130 to perform server-side game data processing. The first client 110, the second client 120, and the server 130 can be connected via wired or wireless communication links for data transmission. For example, the first client 110 can send information (such as an editing assistance request) to the second client 120 through the server 130, and the second client 120 can send information (such as an edited first game lineup) to the first client 110 through the server 130. In addition, the first client 110 and the second client 120 can also communicate directly through wired or wireless means.

[0016] In one implementation, the above method can be implemented and executed based on a cloud interaction system. The cloud interaction system can be based on the aforementioned system architecture. Various cloud applications can run under the cloud interaction system, such as cloud gaming. Taking cloud gaming as an example, cloud gaming refers to a gaming method based on cloud computing. In the cloud gaming operating mode, the game program's execution entity and the game screen presentation entity are separated. The storage and execution of in-game control and interaction methods are completed on the cloud gaming server (such as the aforementioned server 130). The cloud gaming client (such as the aforementioned first client 110 and second client 120) includes receiving and sending data, as well as presenting the game screen. For example, the cloud gaming client can be a display device with data transmission capabilities located close to the user, such as a mobile terminal, television, computer, or PDA; while the information processing is performed by the cloud gaming server in the cloud. When playing or editing, the player operates the cloud gaming client to send operation commands to the cloud gaming server. The cloud gaming server runs the game according to the operation commands, encodes and compresses game screen data, returns it to the cloud gaming client via the network, and finally decodes and outputs the game screen through the cloud gaming client.

[0017] This embodiment provides a method for editing a game map. Figure 2 This is a flowchart of a game map editing method according to an embodiment of the present disclosure, such as... Figure 2 As shown, the process includes the following steps: Step S110: When the game map is in draft state, control the assignment of corresponding first identifiers to the multiple sub-levels included in the game map. Step S120: In response to the association configuration instruction, determine the association configuration information, wherein the association configuration information is configured based on the first identifier and is used to describe the cross-level jump relationship between multiple sub-levels; Step S130: In response to the game map release command, control the generation of map instances corresponding to each sub-level, wherein each map instance is assigned a corresponding second identifier, which is used to locate the corresponding map instance at runtime; Step S140: Establish the mapping relationship between the first identifier and the second identifier; Step S150: When the game map is in running state, the first identifier carried in the jump request is parsed into the corresponding second identifier according to the mapping relationship, and the corresponding map instance is located according to the determined second identifier.

[0018] The method provided in this implementation allows for the automatic allocation of a first identifier in the draft state and direct referencing of this stable identifier in the association configuration. Upon release, a map instance is uniformly generated and a mapping relationship between the two sets of identifiers is established. At runtime, the static first identifier is dynamically resolved into a runtime-effective second identifier based on this mapping relationship to locate the target instance. This decouples logical creation from platform release, allowing authors to complete the design of multi-level jump logic in the entire draft state without waiting for the dynamic instance identifiers to be filled back after release. This significantly improves the interactive experience and creation smoothness on the editor side. At the same time, complex cross-level jump relationships between multiple sub-levels can be freely designed and verified in the draft stage, enriching the content organization dimension and gameplay connection depth of the game map, effectively enhancing the game's richness. In the computer field, this method decouples the strong coupling relationship between static reference identifiers and dynamic runtime instance addressing identifiers through a dual identifier system and runtime dynamic mapping mechanism. This avoids the problem of hard-coded dynamic identifiers becoming invalid due to instance reconstruction or version iteration, significantly reducing the production and maintenance costs of multi-level content under a state synchronization architecture.

[0019] The steps described above are explained in detail below.

[0020] In step S110, specifically, in the draft state of the map project, the system can generate identity identifiers for each sub-level as the basis for subsequent cross-level association references.

[0021] The "draft" status of a game map indicates a creation stage where the map content is not yet officially released and remains in an editable configuration by the author. This attribute works in conjunction with subsequent release and runtime stages to form a comprehensive lifecycle management solution covering map editing, instance release, and runtime transitions. For example, the draft status can be achieved through an unreleased version in local editing mode; alternatively, it can be achieved through a private editing state within the author's workspace; and still others, it can be achieved through a pending review state within a controlled testing environment.

[0022] In an optional implementation, the game map being in draft mode can be a private editing mode within the creation environment that has not yet been approved by the platform. This mode only grants read and write permissions to the author and their collaborators. Level data is temporarily stored in the local workspace or private cloud storage, and does not enter the platform's registration process, thus creating a clear separation from the published, publicly available runtime state. For example, after the author enters the level management interface and creates a new map project, the system immediately sets the currently open map project to a draft state visible only to the author locally. At this time, all newly created sub-levels are in the content organization stage awaiting publication. The author can freely adjust the level structure and assign a first identifier without triggering the generation of any runtime map instances.

[0023] In an optional implementation, the game map being in a draft state can be considered a local configuration stage where the map data has not yet been packaged and uploaded to the runtime server. During this stage, the editor only operates on local project files; all identifier assignments and navigation configurations apply to offline data and are only synchronized to the runtime platform after publication, thus achieving physical isolation between the creation and runtime environments. For example, any adjustments and identifier assignments made by the author to sub-levels within the editor only affect the local cache. Only after a subsequent release command is triggered does the instance generation process become visible to the platform, at which point the draft state ends and the process transitions to the release processing stage.

[0024] It should be noted that the game map being in a draft state can be just one of the above implementation methods, such as the current map project being only in local private editing mode; the game map being in a draft state can also be multiple of the above implementation methods at the same time, such as the map project being both in an unpublished state in the local cache and in a private editing state within the author's workspace.

[0025] The assignment of a first identifier to each of the multiple sub-levels within the game map can be seen as an operation involving the allocation of a unique identification code automatically generated by the system for each sub-level. This operation works in conjunction with subsequent association configuration and mapping establishment steps, enabling cross-level jump logic to locate dynamically generated map instances based on stable and unchanging reference information. For example, the first identifier can be automatically assigned using the system's built-in globally unique identifier generation service; alternatively, it can be generated using a serialization encoding rule based on a combination of timestamps and random numbers; still another example is assigning the first identifier to a fixed string obtained by processing the basic information of the sub-level through hash operations.

[0026] In an optional implementation, assigning a corresponding first identifier to each of the multiple sub-levels included in the game map can be achieved by the system automatically dispatching a fixed string identifier when the author triggers the creation of a new sub-level. The editor listens for level creation events and, upon triggering, generates a stable identifier string for the new sub-level that does not change with publication, displaying it in the general settings area for copying and referencing. For example, when the author clicks the "Create Level" button in the level management interface, the editor immediately calls the internal identifier service to assign a stable identifier string to the newly generated sub-level that does not change with the publication status, and displays it in the general settings area for subsequent navigation logic to reference.

[0027] In an optional implementation, assigning a corresponding first identifier to each of the multiple sub-levels included in the game map can be achieved by pre-registering identification codes for each content unit during the map project initialization phase. At the beginning of game project creation, the system assigns a corresponding first identifier to each content unit according to the planned sub-level structure list and records it in the project metadata for unified reference in subsequent jump scripts. For example, at the beginning of game map project file creation, the system assigns a corresponding first identifier to each content unit according to the planned sub-level structure list and records the identifier in the project metadata for unified reference in jump scripts.

[0028] It should be noted that assigning a corresponding first identifier to each of the multiple sub-levels included in the game map can be only one of the above implementation methods, such as triggering the assignment of a single identifier only when the author creates a new sub-level; assigning a corresponding first identifier to each of the multiple sub-levels included in the game map can also be multiple of the above implementation methods at the same time, such as the system supporting both real-time assignment when a single level is created and batch pre-assignment during project initialization.

[0029] In a specific application, the author opens the map editor and enters a map project containing a multi-area dungeon structure. At this time, the system detects that the project is in a draft state and immediately assigns a first identifier to the three sub-levels: the entrance hall, the BOSS room, and the treasure vault. After seeing these identifiers in the level management interface, the author can start configuring the teleportation relationship between them.

[0030] In step S120, specifically, the author initiates an association configuration operation in the editing environment, and the system generates configuration information describing the jumpable paths between each sub-level, and the information directly references the assigned first identifier as the jump target.

[0031] The relationship configuration command can be an operation command triggered by the author in the editing environment to initiate the cross-sub-level jump relationship configuration process. This command works in conjunction with the first identifier allocation step, enabling the author to complete the editing configuration of the jump path after knowing the identity identifiers of each sub-level. For example, the relationship configuration command can be triggered through the visual connection operation in the toolbar; another example is that the relationship configuration command can be triggered through specific command input in the script editing window; yet another example is that the relationship configuration command can be triggered through the drag-and-drop connection operation in the node editing panel. This operation command can be implemented through click operations, swipe operations, long press operations, and / or other operations. Taking the click operation as an example, after the author clicks the jump logic configuration entry in the editor, the system responds to this click operation, determines the relationship configuration information, where the relationship configuration information is based on the first identifier configuration and is used to describe the cross-level jump relationship between multiple sub-levels.

[0032] In one optional implementation, the association configuration instruction can trigger an operation for defining a jump relationship initiated by the author by clicking the association configuration button in the editor interface. For example, when configuring a portal connection between two sub-levels, the author clicks the configure association option in the level management panel, and the system immediately opens the jump logic editing window and captures the click instruction as an association configuration instruction. In another optional implementation, the association configuration instruction can trigger a cross-level reference configuration through code completion in the script editing area. For example, when the author enters a jump function, the system automatically prompts a list of available first identifiers. The author selects the target first identifier and confirms the input, and the editor records this script change as an association configuration instruction.

[0033] It should be noted that responding to the association configuration instruction may be only one of the above embodiments, such as being triggered by clicking a button; responding to the association configuration instruction may also be multiple of the above embodiments, such as triggering the overall process by clicking the configuration panel button and triggering the specific reference configuration by selecting the identifier in the script area.

[0034] Specifically, the relationship configuration information can be structured data generated by the system in response to editing operations to record cross-instance jump paths between sub-levels. This data, together with the first identifier and mapping relationship, forms a complete jump information chain from draft-state logical description to runtime instance addressing. For example, the relationship configuration information can be carried by a jump logic script file; alternatively, it can be stored through connection attribute data in a visual node graph; still others, it can be organized through jump record entries in a data table.

[0035] In an optional implementation, the relationship configuration information can be a configuration file generated in the visual editing panel that records one-way jumps between sub-levels. For example, the author configures a jump parameter pointing to the first identifier of the subsequent sub-level in the exit area of ​​the previous sub-level. The editor then generates relationship configuration information with the first identifier as the target parameter and saves it in the project data.

[0036] In an optional implementation, the relationship configuration information can be determined as intermediate cross-level jump data generated after syntax parsing during script compilation. For example, the author writes jump call statements in the script with a first identifier as a function parameter. The editor parses the script in the background, extracts the source identifier and target identifier from each jump statement, and generates structured relationship configuration information.

[0037] It should be noted that the configuration information for determining the relationship can be only one of the above implementation methods, such as only a visual configuration file; the configuration information for determining the relationship can also be multiple of the above implementation methods at the same time, such as including both visual node graph data and intermediate representation data after script parsing, which are merged into unified configuration information when published.

[0038] The association configuration information, based on the first identifier configuration, allows for a setting method where jump configuration data uses the stable identity identifier of the sub-level rather than the dynamic instance identifier as the reference basis. This setting method works in conjunction with the first identifier allocation step and the dynamic mapping resolution step, ensuring that the reference information entered in the draft state can still correctly point to the target map instance during the release and runtime phases. For example, the jump target field in the configuration information can directly store the string value of the first identifier; another example is that the jump target field in the configuration information can be associated through a reference link pointing to the first identifier; yet another example is that the jump target field in the configuration information can be mapped through an index key value containing the first identifier.

[0039] In an optional implementation, the association configuration information based on the first identifier can be configured by directly writing the first identifier into the target parameter field in the jump logic. For example, when configuring the jump from the main city level to the dungeon level, the author fills the first identifier of the dungeon level into the script as the only target parameter of the jump function. Based on this, the system determines that the jump relationship directly references the first identifier rather than other dynamic identifiers.

[0040] In an optional implementation, the association configuration information based on the first identifier can be configured in a form where nodes representing each sub-level are bound to the corresponding first identifier in a visual configuration interface. For example, when an author drags a level node with a first identifier from the level list to the target position in the jump relationship graph, the editor establishes the binding between the node and the first identifier and generates association configuration information describing the cross-level jump relationship accordingly.

[0041] It should be noted that the configuration of the association relationship based on the first identifier may be only one of the above implementation methods, such as configuring it directly in the script; the configuration of the association relationship based on the first identifier may also be multiple of the above implementation methods, such as writing the first identifier string value in the script and binding the level node with the corresponding first identifier in the visualization interface to achieve double redundancy reference guarantee.

[0042] In a specific application, the author viewed three sub-levels with assigned first identifiers in the game map editor. By clicking the association configuration button in the editor, the association configuration instruction was triggered. Subsequently, in the jump logic script, the first identifier of the main city level was filled into the jump function parameter leading to the dungeon level. The system determined the association configuration information based on this. This information directly referenced the first identifier and described the cross-level jump relationship from the main city to the dungeon.

[0043] In step S130, specifically, after receiving the release instruction, the system registers each sub-gate as an independent running instance and assigns a second identifier to each instance that can be located during runtime.

[0044] The publish command in response to the game map can be a state transition command triggered by the author or the system after editing, used to transform the draft map content into a runnable instance. This command works in conjunction with the draft editing steps and the runtime parsing steps to realize a complete publish chain from content creation to instance launch and then to navigation. For example, the publish command can be triggered by the author clicking the publish button at the top of the editor; another example is that the publish command can be automatically triggered by the system when a scheduled task reaches a preset publish time; yet another example is that the publish command can be triggered by the merge commit operation in the version management tool. This operation command can be implemented through click, swipe, long press, and / or other operations. Taking the click operation as an example, after the author clicks the publish button in the editor interface, the system responds to this click operation and controls the generation of map instances corresponding to each sub-level.

[0045] In one alternative implementation, the release command for the game map can be a global deployment request triggered by the author clicking the release button after editing. For example, after the author completes the jump logic configuration for all sub-levels, they click the release button in the editor toolbar. The system captures this click operation as a release command and then begins registering each sub-level in the map project as an independent map instance with the platform.

[0046] In one alternative implementation, the release command in response to the game map can be an automated release signal triggered by the commit process of the version control system. For example, the author merges the branch code containing configuration information for each sub-level and its relationships into the main branch. After the merge is successful, the version control system automatically generates a release command and sends it to the release service to trigger the subsequent map instance generation process.

[0047] The process of controlling the generation of map instances corresponding to each sub-level can be described as the process by which the system deploys the content of each sub-level as an independent, runnable service instance according to the release instructions. This process works in conjunction with the first identifier and mapping relationship establishment step, ensuring that each sub-level has an independent instance identity at runtime and maintains a persistent association with the stable identifier. For example, map instances can be generated by packaging the sub-level into a container image and deploying it on the runtime platform; alternatively, map instances can be generated by allocating an independent process space for the sub-level on the state synchronization server; still others can be generated by registering the sub-level on the platform and allocating runtime resources.

[0048] In an optional implementation, the generation of map instances corresponding to each sub-level can be controlled by the platform backend allocating independent runtime space for each sub-level and loading the level content after receiving the release command. For example, the system uploads content data packages containing main city levels, dungeon levels, and wilderness levels to the runtime platform respectively, and the platform backend starts an independent map instance process for each data package, so that each level has an independent runtime environment on the server.

[0049] In an alternative implementation, controlling the generation of map instances corresponding to each sub-level can be achieved by cloning runnable copies of each sub-level using a template instantiation mechanism during the publishing process. For example, the system predefines a map template containing the basic operating environment. During publishing, the system calls this template to create an instance for each sub-level and injects the content of the corresponding sub-level into the instance, thereby generating each map instance.

[0050] It should be noted that when generating a map instance, each sub-level within the game map is created as an independent map instance. That is, from both a platform perspective and a logical standpoint, the game map at this point comprises multiple independent maps. Each game instance (sub-level) supports independent execution and loading, and carries its own independent game rules and game state.

[0051] The second identifier assigned to each map instance can be a runtime addressable digital identity assigned by the platform to each deployed map instance. This identifier, in conjunction with the first identifier and mapping relationship, establishes a queryable conversion bridge between stable references in the draft state and dynamic instances in the runtime state. For example, the second identifier can be assigned through a numerical number sequentially issued by the platform's identifier service; alternatively, it can be assigned through a string generated by the platform based on a combination of the instance deployment area and the instance sequence number; still others can be assigned through a unique numerical identifier generated by a third-party identifier allocation service using the Snowflake algorithm.

[0052] For example, when the publishing module registers a sub-level as a map instance, the platform calls the internal identifier service to retrieve an unused integer number from the available identifier pool and assign it to the instance as its unique identifier for location requests at runtime.

[0053] The second identifier, used to locate the corresponding map instance at runtime, can be a functional attribute of the runtime addressing system that retrieves and connects to the target map instance on the server based on this identifier. This functional attribute, in conjunction with the first identifier and dynamic mapping resolution, ensures that cross-instance jump requests are ultimately routed to the correct running instance. For example, the location process can be achieved by querying the instance node address corresponding to the second identifier in the server-side distributed hash table; alternatively, the location process can be achieved by sending the second identifier to the platform addressing service and receiving the returned instance access point information; still another example is that the location process can be achieved by retrieving the server network address bound to the second identifier from the service registry center.

[0054] In an optional implementation, the second identifier used to locate the corresponding map instance at runtime can be a addressing process where the server retrieves the target instance's network address from the instance routing table based on the second identifier. For example, the jump execution module sends the parsed second identifier to the platform addressing service, which queries the registration record corresponding to the second identifier and returns the current running node address of the map instance, thereby completing the location.

[0055] In an optional implementation, the second identifier used to locate the corresponding map instance at runtime can be a connection process that resolves the target instance load balancing entry point in the distributed service mesh using the second identifier. For example, at runtime, the system inputs the second identifier into the service mesh's resolution module, which then locates the available node currently hosting the map instance in the instance cluster and returns the load-balanced access address to establish a connection.

[0056] It should be noted that the second identifier used to locate the corresponding map instance at runtime can be only one of the above implementation methods, such as addressing only through the instance routing table; the second identifier used to locate the corresponding map instance at runtime can also be multiple of the above implementation methods at the same time, such as supporting both positioning through the platform addressing service and resolving the load balancing entry in the service mesh, so as to improve the reliability of runtime addressing.

[0057] In a specific application, after the author completes the jump script configuration, he clicks the publish button in the editor. The system responds to the publish command by packaging and uploading the map project as the publish unit. The platform backend generates corresponding map instances for the three sub-levels in sequence and assigns a unique number to each instance as a second identifier. At this time, each instance has the conditions to run independently but has not yet formed a direct addressing association with the draft content on the author's side.

[0058] In step S140, specifically, during the release phase, the system associates and records the stable identity identifier of the sub-gate with the actual running instance identifier after deployment, so as to enable bidirectional querying during the runtime.

[0059] Establishing a mapping between the first and second identifiers involves creating a queryable correspondence between the persistent identity identifier of a sub-level and the dynamic identity identifier of its actual running instance. This operation, in conjunction with draft-state identifier allocation and runtime resolution, forms the core link for converting stable references into actual addressable instances at runtime. For example, the mapping relationship can be recorded using a key-value pair data structure; alternatively, it can be recorded using a relational database's join table; and still others, it can be recorded using index entries in a distributed cache.

[0060] In an optional implementation, establishing the mapping relationship between the first identifier and the second identifier can be achieved by the mapping maintenance module writing the first identifier of each sub-level and the second identifier returned by the platform into an internal mapping table during the publishing process. For example, each time the publishing module successfully registers a sub-level as a map instance, it receives the second identifier of that instance from the platform and inserts the second identifier and the corresponding first identifier of the sub-level as a record into the mapping data table, thus completing one mapping establishment.

[0061] In an optional implementation, establishing the mapping relationship between the first identifier and the second identifier can be achieved by asynchronously maintaining the correspondence between the two sets of identifiers through an event subscription mechanism in the publishing pipeline. For example, after the platform generates a map instance and assigns a second identifier, it triggers an instance creation completion event. The system subscribes to this event and automatically binds and records the first identifier and second identifier corresponding to the instance in the event handler, thereby realizing the asynchronous establishment of the mapping relationship.

[0062] It should be noted that establishing the mapping relationship between the first identifier and the second identifier can be only one of the above implementation methods, such as only completing it through synchronous write operations during the publishing process; establishing the mapping relationship between the first identifier and the second identifier can also be multiple of the above implementation methods, such as supporting both synchronous table record writing during publishing and asynchronous supplementation of mapping data in a distributed environment through an event subscription mechanism.

[0063] In step S150, specifically, when a virtual character triggers a cross-level jump in the game, the server receives a request carrying a first identifier, searches for the currently effective second identifier through a pre-established mapping relationship, and then addresses the target map instance to complete the transfer.

[0064] The "game map is in running state" attribute indicates that the game map has been published and loaded into the runtime environment, making it available for players to enter and interact with. This attribute, along with the publication phase and runtime resolution steps, forms a complete service provision chain from content launch to player interaction. For example, the running state can be represented by the server process being started and listening for external connections; it can also be represented by the map instance being registered in the platform's running service list and being queryable; or it can be represented by the map instance reaching a state where it can push status synchronization data to player clients.

[0065] In an optional implementation, the game map being in a running state can mean that the map instances corresponding to each sub-level have been loaded on the running server and are ready to accept player access requests. For example, the platform backend allocates map instances to running nodes and starts the instance process. The instance reports a heartbeat to the platform registration center, and the platform determines that the instance has entered a running state and grants player access permissions.

[0066] In an optional implementation, the game map being in a running state can be an online service phase where the map instance has exposed its network access point and has the capability to perform state synchronization services. For example, after the map instance starts, it is bound to the platform's network access gateway. Player clients can query the second identifier of the map instance through the platform's matching service and request to establish a data channel. At this time, the map instance is in a running state.

[0067] It should be noted that the game map being in a running state can be only one of the above implementation methods, such as only the state where the server process has started; the game map being in a running state can also be multiple of the above implementation methods at the same time, such as requiring both the instance process to be started and the network access point to be bound and open to player access.

[0068] Specifically, resolving the first identifier carried in the jump request to the corresponding second identifier based on the mapping relationship can be considered a runtime query and parsing process that converts the stable checkpoint reference information carried in the jump request into the currently effective map instance identity identifier. This process works in conjunction with the mapping establishment and instance location steps to achieve the key identifier conversion from static references in the draft state to dynamic addressing at runtime. For example, the parsing process can be implemented by directly querying the second identifier corresponding to the first identifier in the local memory mapping table; alternatively, it can be implemented by sending a query request to the distributed mapping service and receiving the returned second identifier; still another example is that the parsing process can be implemented by prioritizing the query in the cache layer and then checking the persistent mapping storage when a match is not found.

[0069] In one optional implementation, resolving the first identifier carried in the jump request to the corresponding second identifier according to the mapping relationship can be the process by which the server-side jump execution module queries the internal mapping data table after receiving the player's teleportation request. For example, when a virtual character triggers cross-level teleportation, the server receives a jump request carrying the first identifier of the source level. The jump execution module calls the mapping maintenance module to query the mapping data table for the second identifier currently bound to the first identifier and returns it.

[0070] In an optional implementation, resolving the first identifier carried in the redirection request to the corresponding second identifier according to the mapping relationship can be a service request process that performs cross-instance identifier conversion by calling a platform-level identifier resolution service. For example, the server sends the first identifier in the received redirection request to the platform identifier resolution service, which then returns the valid second identifier corresponding to the first identifier in the current version based on globally maintained mapping data.

[0071] It should be noted that resolving the first identifier carried in the jump request to the corresponding second identifier according to the mapping relationship can be only one of the above implementation methods, such as querying only through the local memory mapping table; resolving the first identifier carried in the jump request to the corresponding second identifier according to the mapping relationship can also be multiple of the above implementation methods at the same time, such as supporting both fast local memory query and initiating a back lookup to the platform-level resolution service when the local memory is not found.

[0072] Specifically, locating the corresponding map instance based on the second identifier involves finding the target map instance in the server's address space based on the runtime instance's identity identifier and completing the final addressing operation for access. This operation, in conjunction with the first identifier resolution and mapping relationship, ensures that cross-level jump requests are ultimately routed to the correct independent map instance to complete the directional teleportation of the virtual character. For example, the location operation can be achieved by querying the server network address bound to the second identifier in the instance registry and initiating an access request to that address; alternatively, the location operation can be achieved by sending the second identifier to the platform runtime manager, which will then return the instance proxy address; still another example is that the location operation can be achieved by locating the partition node address corresponding to the second identifier in a distributed consistent hash ring.

[0073] In one optional implementation, locating the corresponding map instance based on the second identifier can be achieved by requesting the instance access point information currently bound to the identifier from the platform addressing service after parsing the second identifier. For example, after obtaining the second identifier, the jump execution module initiates a query request to the platform addressing service, which returns the instance node address and port information currently registered with the second identifier, allowing the system to connect to the target map instance.

[0074] In one optional implementation, locating the corresponding map instance based on the second identifier can be achieved by retrieving the current node of the target instance from the service registry center of the server cluster using the second identifier and establishing a connection. For example, the server maintains a service registry center where each map instance registers its own second identifier and network address upon startup. The jump execution module directly obtains the real-time connection information of the target instance by querying this center to complete the location.

[0075] It should be noted that the map instance corresponding to the location based on the second identifier may be only one of the above implementation methods, such as querying only through the platform addressing service; the map instance corresponding to the location based on the second identifier may also be multiple of the above implementation methods, such as requesting an access point from the platform addressing service and performing a fallback search through the service registry center when the query fails.

[0076] In an exemplary application of this embodiment, the author uses an editor to create a large multi-region adventure map. In the draft state, the system assigns corresponding first identifiers to multiple sub-levels. In response to the association configuration command, the author determines the association configuration information based on the first identifier to describe the cross-level jump relationship between each sub-level. Subsequently, in response to the release command, the platform controls the generation of map instances corresponding to each sub-level and assigns second identifiers to them. The system establishes a mapping relationship between the first identifier and the second identifier. After the map enters the running state, the server parses the first identifier carried in the player's jump request into the corresponding second identifier according to the mapping relationship, and then locates the target map instance according to the second identifier, completing the transfer of the virtual character between different running instances of the sub-level.

[0077] In a game map editing method provided in one embodiment of this application, the first identifier is a stable identifier string assigned by the system, which remains unchanged throughout the entire life cycle of the sub-level and does not change with release, re-release or version update; the stable identifier string cannot be customized on the author's side.

[0078] The method provided in this embodiment configures the first identifier as a stable identifier string assigned by the system, which remains constant throughout the entire lifecycle of the sub-level and does not change with release, re-release, or version update. At the same time, it restricts the author's custom permissions. On the one hand, it can provide the author with a ready-to-use and conflict-free identity identifier during the creation stage, reducing the interactive burden of manually configuring and managing identifiers. On the other hand, it can maintain the continuous validity of cross-level reference relationships during release and subsequent iterations, avoiding association breakage or resolution failure caused by identifier changes. This ensures that the game map can maintain the integrity and correctness of complex cross-level jump logic even after multiple version updates, improving the long-term richness of interactive experience and game content. At the same time, it ensures the stability of the identifier system and the reliability of mapping resolution from the computer implementation level.

[0079] The above plan will be explained in detail below.

[0080] Specifically, the first identifier is uniformly assigned by the system during the creation phase, and its form is configured as a stable identifier string. This stable identifier string remains constant throughout the entire lifecycle of the sub-level from creation to deletion, and does not change due to processes such as release, re-release, or version update. Furthermore, the creator does not have the permission to customize and edit this stable identifier string.

[0081] The first identifier is a stable identifier string assigned by the system, which can be a string identity generated by the system according to a globally unique strategy during the sub-level creation phase. This identifier is decoupled from author-side operations after assignment, providing a unified and persistent positioning basis for cross-level references. In one implementation, the system can generate this identifier string based on a combination of timestamp and random entropy; in another, a hierarchical identifier can be generated by concatenating the project namespace and level sequence number; and in yet another implementation, the platform's central service can distribute sequentially encoded identifiers according to a partitioning strategy.

[0082] In an optional implementation, the first identifier, a stable identifier string assigned by the system, can be generated by the server using a globally unique algorithm. This string is automatically written into the level's metadata when the author creates a sub-level. The author can copy this string in the association configuration interface to establish cross-level jump relationships. For example, if the author creates a new ruins entrance sub-level in the map project, the system automatically assigns the identifier string mT9kP2vL. When configuring the association relationship from the main city to this sub-level, the author can directly fill in this string in the jump parameter box.

[0083] In an optional implementation, the first identifier, a stable identifier string assigned by the system, can be pre-cached in batches on the editor's backend server. When the author selects any sub-level in the level management list, its attribute panel automatically displays the pre-assigned stable string. The author can directly copy this string and call it in the association configuration. For example, if a local map project contains five sub-levels, the system generates a stable identifier string for each sub-level in parallel when the author first saves the project. The author references these pre-assigned strings when configuring any cross-level jump relationship.

[0084] It should be noted that the first identifier, which is a stable identifier string assigned by the system, can be only one of the above embodiments, or it can be multiple of the above embodiments simultaneously. For example, the system can either generate the first identifier in real time based on a random algorithm, or it can pre-cache a batch of identifier strings for direct use when creating new sub-levels.

[0085] The attribute that remains unchanged throughout the entire lifecycle of a sub-level serves as an identifier that maintains a constant value throughout its entire lifecycle. This attribute works in conjunction with lifecycle management to ensure that the positioning criteria of a sub-level do not drift during any state transition. In one implementation, the system can write this identifier to the level project configuration file in read-only mode; in another, a record with this identifier as the primary key and which is prohibited from being updated can be created in the database; still another implementation can mark this field as a persistent item during engine serialization.

[0086] In an alternative implementation, keeping the sub-level unchanged throughout its entire lifecycle can be manifested in the fact that the first identifier is locked as a fixed value after the sub-level is created, and regardless of subsequent save, backup or migration operations, the identifier always exists as a fixed identity credential for the sub-level within the project.

[0087] In an alternative implementation, keeping the sub-level unchanged throughout its entire lifecycle can be achieved by having the first identifier included in the project version tracking from the moment the sub-level is generated. In subsequent project commits and branch merging processes, this identifier maintains its initial value without change. For example, if the author uses version control to revert to a project version from three months prior, where the first identifier of each sub-level remains the same as the identifier in the latest version, the historical jump configuration can be resolved correctly without any modification.

[0088] Among these, the "unchanged with release" attribute can be a cross-stage identifier that maintains its original value throughout the entire transition of a map project from draft to release. This attribute is decoupled from the release process, ensuring that references in the association configuration remain effective before and after the state switch. In one implementation, the system can write the identifier as is into the manifest file during release packaging without replacing it; in another implementation, the release server can avoid performing secondary encoding or hash conversion on the identifier; and in yet another implementation, the system can list the identifier as an immutable field during the release review stage.

[0089] In an optional implementation, the "unchanged upon publication" principle can be manifested in the fact that when the author triggers the publication command to register the draft sub-level as a map instance, the system retains the original string content of the first identifier, only allocating a second identifier required for runtime; both exist in parallel. For example, if the first identifier of the sub-level in the draft state is lvlA23x, after publication to the platform, its map instance obtains the numeric ID 10086, but the lvlA23x filled in the author's association configuration will not be replaced and will remain unchanged.

[0090] In an optional implementation, the "unchanged with release" aspect can be manifested in the release process performing pass-through processing on the association configuration data containing the first identifier. That is, after receiving the overall release data package, the platform backend does not modify the first identifier field already referenced in the configuration, but only appends the runtime identifier mapping. For example, when releasing a map project containing three sub-levels, the first identifier of each of the three sub-levels appears repeatedly with the same string in the configuration files before and after the release. The system only adds a new mapping record on the backend.

[0091] Among these, the "unchanged" attribute refers to a stable identifier that remains unchanged when a released level undergoes a re-release process. This attribute works in conjunction with the incremental update mechanism to avoid the breakage of reference relationships caused by repeated releases. In one implementation, the system can compare the historical mapping table and reuse the original first identifier during the update release; in another implementation, the re-release process can skip the step of reallocating identifiers for existing sub-levels; in yet another implementation, the system can retain the reference index of the original identifier in the hot update patch.

[0092] In this implementation, the principle of "not changing with republishing" means that when an author republishes an already released sub-level to fix content, the system detects that the sub-level already has a historical publication record and automatically uses its initially assigned first identifier, without generating a new string. For example, if a published Boss battle sub-level needs to adjust scene props, after the author republishes it, the first identifier references of other levels pointing to that Boss battle remain valid, without needing to check the jump configuration line by line.

[0093] In other implementations, the principle of not changing with each re-release can be reflected in the re-release process, where the release module first checks whether the mapping maintenance module already contains a first identifier record for the sub-level. If the query finds a match, the identifier is directly extracted and reused, while maintaining the original mapping relationship with the second identifier. For example, if the entire map project undergoes ten content updates and re-releases, the first identifier of each sub-level remains fixed from the initial release, and the cross-level jump configuration after ten updates is completely consistent with the referencing method at the time of the initial release.

[0094] It should be noted that "not changing with each re-release" can be just one of the above implementation methods, or it can be multiple of the above implementation methods simultaneously. For example, the system can either reuse the historical first identifier during the second release, or it can query the mapping table and reuse existing records before each re-release.

[0095] Among these, the attribute that remains unchanged with version updates can be a cross-version identity that persists throughout multiple version iterations of the map project. This attribute works in conjunction with version management, ensuring that historical jump logic is automatically inherited and compatible in new versions. In one implementation, the system can automatically inherit the first identifier allocation table from the previous version when upgrading the version number; in another implementation, the system can use the first identifier as the basis for level uniqueness comparison when merging project branches; in yet another implementation, the system can include this identifier in the metadata whitelist that must be retained during major version refactoring.

[0096] In an exemplary application of this embodiment, the author opens the level management interface and clicks the "Create Level" button. The system immediately assigns a stable identifier string Xy7Z9pLm to the new sub-level in draft mode. This identifier string is displayed in the attribute area on the right and cannot be modified by the author. The author directly copies this identifier string and references it in the multi-level association configuration. Subsequently, the entire map project is published. The platform assigns a second identifier in digital form to each map instance. The system automatically establishes a mapping relationship between the first identifier and the second identifier in the background. Afterward, the author updates and republishes the sub-level three times. The first identifier of the sub-level remains unchanged. Jump requests from other levels to this sub-level are all successfully parsed through this stable first identifier and correctly reach the target map instance.

[0097] In one embodiment of the application, a method for editing a game map includes determining association configuration information in response to an association configuration instruction, which includes: Step S310: Control determines the jump logic script, which describes the jump relationship across sub-levels. Step S320: In response to the configuration instruction, control the configuration of the first identifier in the jump logic script so that the jump logic script can directly reference the first identifier. The method provided in this implementation allows authors to configure cross-sub-level jump relationships in the draft state using the first identifier. The jump logic script directly references the stable first identifier without needing to be aware of the second identifier in the runtime state, thereby decoupling logic creation from platform publishing, reducing post-publishing reflow editing operations, and improving the editor's interactive efficiency and ease of use. At the same time, this mechanism lowers the design threshold for multi-level content, which is conducive to creators building more complex and closely related sub-level structures, enriching the gameplay layers. In addition, by directly referencing the draft state identifier in the script, the identifier management and mapping process is simplified from the perspective of computer information processing, avoiding the system resource overhead caused by multiple publishing queries and backfilling, and improving the data processing efficiency in the map editing and publishing process.

[0098] In step S310, specifically, when configuring cross-sub-level association relationships, the system first determines the script carrier used to carry the jump logic, namely the jump logic script. This script is used to define the jump rules and connection methods between different sub-levels, thereby providing a logical basis for subsequent level chaining.

[0099] The control-determined jump logic script can be a pre-defined logical carrier within the editor to carry cross-sub-level jump rules. This logical carrier, together with the first identifier, constitutes the basis for level chain configuration in draft state without needing to be published. Optionally, this jump logic script can be a logic flow diagram in a visual node editing panel, a text script based on a code editor, or a logic configuration page in a hybrid editing interface that combines graphical blocks and text commands. It can be pre-provided by the system or created based on the user's editing operations.

[0100] In an optional implementation, the control to determine the jump logic script can be to present each sub-level as a module node in the graphical script configuration interface. The author specifies the jump direction by establishing directed connections between nodes. The system automatically associates the first identifier of the corresponding sub-level on the connection and writes the script data, thereby completing the determination of the jump logic script.

[0101] In an optional implementation, the control to determine the jump logic script can be a file framework provided in the code editor. The author fills in the jump instructions with a first identifier as a parameter within the framework. After saving, the system identifies this file as the jump logic script for the current game map. For example, a new script file named LevelJump is created, which calls the jump service and fills in the first identifier of the castle level as the target location parameter. After saving, the script is recognized by the system as a jump logic script describing the jump relationship between the forest level and the castle level. It should be noted that the control to determine the jump logic script can be only one of the above implementation methods, or it can be multiple of the above implementation methods simultaneously. For example, the jump relationships between some sub-levels in the same map project are determined by graphical node connections, while the jump relationships between other sub-levels are determined by code editing. The system supports a combination of these two methods.

[0102] In step S320, specifically, based on the determined jump logic script, the system receives the configuration instruction triggered by the author and controls the writing of the first identifier into the corresponding position in the script, so that the script content directly records the first identifier itself rather than other indirect identifiers, thereby completing the configuration of cross-sub-level association relationship.

[0103] Specifically, the configuration command can be an operation trigger signal initiated by the author to the editor to write an associated identifier in the jump logic script. This signal, in conjunction with the control to configure the first identifier in the jump logic script, completes the closed loop from the author's input to the generation of script data. Optionally, this configuration command can be generated by clicking an interface button, by saving a file in the script editor, or by dragging and dropping a level icon to the script panel.

[0104] In an optional implementation, the system generates a configuration instruction in response to the author's operation of selecting a sub-level and clicking the confirmation association button in the graphical configuration interface. This instruction triggers the subsequent process of writing the first identifier in the jump logic script, which serves as the trigger signal for script data generation.

[0105] For example, the author fills the first identifier of the castle level into the jump target area of ​​the forest level, and then clicks the confirm association button. The system responds to this configuration instruction and controls the first identifier of the castle level to be directly written into the jump logic script.

[0106] In an optional implementation, the system can generate a configuration instruction in response to the author completing the jump instruction with a first identifier as a parameter in the code editor and executing the operation of saving the script file. The system then controls the first identifier to be permanently stored in the script data, thereby completing the configuration trigger.

[0107] For example, the author modifies the jump logic script in the code editor, fills the first identifier of the castle level as a parameter into the teleportation function, and after pressing the save shortcut key, the system responds to the configuration command generated by the save operation and controls the first identifier to be fixed in the script data.

[0108] It should be noted that responding to configuration commands can be just one of the above implementation methods, or it can be multiple of the above implementation methods simultaneously. For example, the author can trigger configuration by clicking the confirmation button or by saving the script file. The system will respond to both configuration commands and execute the write operation of the first identifier.

[0109] Specifically, configuring the first identifier in the jump logic script allows the system to write structured data, such as the level stability identifier, into the jump logic script and persist it. This operation, triggered by the author's configuration instructions, completes the persistent recording of the identifier data, establishing a direct association between the script and the sub-level. Optionally, the system can automatically insert the first identifier into a predetermined parameter field of the script, or it can append the first identifier as a comment and then parse and write it into the formal field, or it can batch write multiple first identifiers into the jump list in sequence.

[0110] In an optional implementation, configuring the first identifier in the jump logic script allows the system to automatically fill the first identifier of the sub-level to be associated into the preset target level parameter field in the jump logic script. The entire process does not require the author to manually edit the script source code; the editor backend directly completes the writing and storage configuration of the identifier data.

[0111] In an optional implementation, controlling the configuration of the first identifier in the jump logic script can allow the system to support authors to place the first identifier into a specified area of ​​the script editor by copying and pasting, and the system can identify the content of the area and confirm it as a valid configuration item in the script.

[0112] It should be noted that configuring the first identifier in the jump logic script can be just one of the above implementation methods, or it can be multiple of the above implementation methods simultaneously. For example, some of the first identifiers are automatically filled in by the system into the parameter field, while others are copied and pasted by the author and then recognized and confirmed by the system. Both methods are used to complete the configuration of the first identifier in the script.

[0113] The direct reference to the first identifier in the jump logic script can be a direct data reference method where the stable identifier of the level is recorded in the original string form and remains unchanged upon release. This reference method, in conjunction with the runtime mapping mechanism, ensures that the script maintains reference consistency throughout the level's lifecycle without needing to be updated with each release. Optionally, the jump logic script can directly store the first identifier as a string constant, store multiple first identifiers as array elements, or directly pass the first identifier as a parameter in the jump function call.

[0114] In an optional implementation, the jump logic script can directly reference the first identifier by recording it as the sole and direct locator for the jump target location, without any intermediate conversion or dynamic lookup and replacement. The first identifier recorded in the script is completely consistent with the first identifier displayed in the level management interface. For example, in the jump logic script, the instruction parameter sent to the castle level is directly written as the first identifier string of the castle level. At runtime, the system queries the mapping relationship based on this original record, rather than replacing it with other placeholders or temporary variables.

[0115] In an optional implementation, the direct reference of the first identifier in the jump logic script can be that in a script containing multiple jump paths, the jump target record of each path directly references the first identifier of the corresponding sub-level, forming a one-to-one direct mapping table, and no target position is referred to through a second identifier or other indirect means.

[0116] In one exemplary application of this embodiment, after the author creates the forest sub-level and the castle sub-level in the multi-level map editor, he enters the jump relationship configuration interface. The system control determines the jump logic script and receives the configuration instruction triggered by the author. The first identifier of the castle level is directly written into the script to describe the cross-sub-level jump relationship from the forest level to the castle level, thereby completing the draft state design of the multi-level chain logic without publishing any sub-level.

[0117] In one embodiment of the application, a method for editing a game map is provided, in which a jump logic script uses a first identifier as the target parameter of a jump request, and the jump request is used to request a transfer across map instances.

[0118] Specifically, in the process of determining the association configuration information, the jump logic script uses the first identifier as the target parameter of the jump request, which is used to request the transfer across map instances at runtime.

[0119] Specifically, the jump logic script uses the first identifier as the target parameter of the jump request, and the script layer can use a stable identifier string as the input parameter for cross-instance addressing. Furthermore, this parameter works in conjunction with the runtime dynamic mapping service to decouple the jump description at creation time from runtime instance location. In addition, the script can also obtain the jump entry based on the logical name mapping table, or use a persistent handle to replace the explicit identifier, or split the target parameter into a combination of namespace and local identifier.

[0120] The jump request, used to request cross-map instance transfer, can be a network request that triggers the migration of virtual objects between different map runtime instances. Furthermore, this request works in conjunction with the instance-isolated runtime architecture to achieve seamless object transfer while ensuring the independent state of each map instance. In addition, the jump request can also be used for scene migration across shard servers, switching between different logical containers on the same physical node, or delivering characters from the lobby instance to the combat instance.

[0121] For example, after a player triggers a portal, the client sends a jump request to the server carrying the first identifier of the castle level. The server parses this as the currently active map number identifier and then seamlessly teleports the player character from the forest map instance to the castle map instance.

[0122] For example, when a large number of players simultaneously request to enter a competitive level, the server will distribute the redirect requests to multiple running instances corresponding to that level, so that players are evenly distributed across different map instances and each instance remains independent.

[0123] In a game map editing method provided in one embodiment of this application, the jump logic script is configured as a complete state of cross-sub-level jump relationship when the game map is in the draft state, wherein the configuration is not contingent on the release of any sub-level.

[0124] The method provided in this implementation allows for the complete pre-setting of cross-sub-level jump logic in draft mode, without waiting for any sub-level to be published, thus decoupling logic creation from platform publishing. Authors no longer need to go through multiple backflow operations of publishing, querying tags, backfilling, and republishing, which lowers the creative threshold and improves the smoothness of interaction on the editing side. In addition, by eliminating the strong dependence on the sub-level publishing status, unnecessary data interaction and version iteration overhead between the editor and the platform backend are reduced, optimizing the efficiency of the game content production pipeline on the computer side.

[0125] Specifically, in draft mode, the jump logic script can carry the jump association information between all sub-levels, and this configuration process does not depend on whether any sub-level has been published.

[0126] Specifically, the jump logic script, configured as a complete cross-sub-level jump relationship in the draft state of the game map, allows for the pre-definition of jump logic between all sub-levels during the map editing stage. This feature, in conjunction with the first identifier assigned by the system, completes the multi-level chain definition during the editing stage. Furthermore, it can also be configured through drag-and-drop of the complete jump relationship via a visual configuration panel; or by directly entering cross-level jump parameters through text editing; or by reusing the jump relationship of an existing map through template inheritance and adjusting it accordingly.

[0127] For example, when the game map is in edit mode, the author writes a jump instruction in the jump logic script to jump from the end portal of sub-level A to the starting square of sub-level B, and specifies that the first identifier of sub-level B is used as the target parameter, thus forming a complete cross-level jump description before release.

[0128] For example, in the visual editing interface, the author drags and connects the node representing the end area of ​​sub-level A with the node representing the starting area of ​​sub-level B. Based on this, the editor automatically generates a cross-level jump relationship record with the first identifier in the jump logic script.

[0129] It should be noted that the jump logic script, configured as a complete state of cross-sub-level jump relationships in the draft state of the game map, can be only one of the above implementation methods, or multiple of them simultaneously. For example, within the same map project, it is permissible to directly describe cross-level jump relationships using a scripting language, or to generate corresponding jump logic through connection operations in the visual node panel. The configuration data generated by the two methods can coexist and complement each other in the draft state.

[0130] The feature that allows configuration not to be contingent on the release of any sub-level removes the preconditions imposed on the release status of sub-levels for cross-level jump logic configuration. This feature relies on the stability of the system's pre-allocated first identifier to independently complete all jump configurations on the editing side. Furthermore, it can also execute jump relationship configurations even when all sub-levels have not been submitted to the platform for review; or continue editing jump logic in a mixed state where some sub-levels have been released while others are still drafts; or complete all configurations in offline editing mode and submit them all at once after connecting to the internet.

[0131] Optionally, configuring the jump relationship without requiring the release of any sub-level can be implemented when all sub-levels in a map project are unreleased. In this approach, the author directly establishes a cross-level jump mapping on the editing side based on a pre-assigned first identifier, without the platform backend participating in pre-verification or interception. This solution frees the creation process from being limited by the platform's release queue and instance generation cycle. Alternatively, configuring the jump relationship without requiring the release of any sub-level can be implemented during level iteration when the author adds or modifies jump relationships in a map project containing both released and draft sub-levels. This allows the configuration to take effect in subsequent versions without re-releasing the released levels. This method supports incremental, progressive multi-level content creation and relationship maintenance. For example, if the author has already released the first and second sub-levels and now adds a third draft sub-level, they can directly add a jump instruction from the second to the third sub-level in the jump logic script, while the first and second sub-levels remain in their original released state and do not need to be re-released.

[0132] It should be noted that the configuration is not contingent on the release of any sub-level; it can be just one of the above implementation methods, or it can be multiple of the above implementation methods simultaneously. For example, the author can complete the overall jump configuration when all sub-levels have not been released, or continue to add jump relationships for unreleased levels when some levels have been released. In both cases, triggering the release process of any sub-level is not a prerequisite for configuring the jump logic.

[0133] One embodiment of the application provides a method for editing a game map, in which the game map is published as a single publishing unit, including: Step S610: Publish the entire game map to the platform so that each sub-level can be registered as a map instance.

[0134] The method provided in this implementation allows authors to publish the entire game map as a single unit to the platform. This enables them to deploy the entire map project, including multiple sub-levels, with a single publishing operation, avoiding repetitive publishing, tag querying, and reflow editing. This significantly improves creation efficiency and ease of interaction. Simultaneously, it lowers the barrier to entry for complex multi-level map projects, promoting the creation of large game maps with rich sub-levels and complex transition relationships, thus enhancing game richness. Furthermore, by merging previously scattered platform interactions into a single request, it achieves atomic publishing management at the map project level, reducing the number of round-trip communications between the client and server. This avoids issues such as partial sub-level registration failures or tag mapping errors caused by step-by-step publishing, improving the reliability and data consistency of the publishing process.

[0135] Specifically, in response to the game map release command, the complete map project data, including multiple sub-levels and their associated configuration information, is submitted to the platform. After receiving the data, the platform creates corresponding map instances for each sub-level, enabling each sub-level to register as an independent map instance and obtain a runtime identifier.

[0136] Publishing the game map as a single unit provides a foundation for atomic deployment and lifecycle management, using the complete map project as the smallest granularity. This approach aggregates the deployment process of multiple sub-levels into a single platform interaction, reducing the complexity of multi-instance registration and ensuring seamless transition between draft and deployment states. In practice, the map project can be configured to support scheduled deployment, automatically triggering the overall deployment process and registering as a map instance at a specified time; alternatively, it can be configured to support canary deployment, allowing each sub-level to gradually complete map instance registration according to a preset ratio; or, it can be configured to support batch rollback, revoking the map instance registration of all sub-levels in the event of an overall deployment failure.

[0137] In an optional implementation, publishing the game map as a single publishing unit allows the editor to respond with a unified upload command, enabling the platform backend to automatically identify all sub-levels within the map project and sequentially complete their instantiation, orchestration, and runtime registration. For example, after completing the level-skipping logic design consisting of five sub-levels, the author only needs to trigger the publish button once. The platform will then generate five independent map instances in parallel in the background and assign their respective runtime identifiers. The author does not need to manually confirm the publishing status and addressing information of each sub-level individually.

[0138] In an optional implementation, publishing the game map as a single publishing unit allows the platform to identify all sub-levels in the map project and complete batch verification and instantiation deployment of the resources dependent on each sub-level based on the unified published project package.

[0139] Publishing the entire game map to the platform involves migrating the complete draft map project data to the platform server in one go to trigger the core publishing operation of instantiation. During this process, while maintaining the reference relationships between sub-levels, the platform can assign runtime identifiers and independent addressing capabilities to each sub-level. In practical applications, the map project can be configured to be uploaded to the platform as a compressed package, with the platform backend handling decompression and distribution; alternatively, the map project can be configured to be uploaded incrementally, transmitting only the sub-level data that has changed since the last release; or, the map project can be configured to transmit metadata and scene data separately, with the platform reassembling the data upon receipt.

[0140] Registering each sub-level as a map instance is a standardized instantiation process where the platform creates independent running instances and assigns runtime addressing identifiers to each sub-level. This allows each sub-level to have independent process resources and runtime space, supporting cross-instance navigation and the seamless entry and exit of external objects. In practical applications, each sub-level can be registered as a containerized map instance, with the platform allocating isolated computing resources to each container; alternatively, each sub-level can be registered as a process-level map instance, giving each instance an independent game logic process; or, each sub-level can be registered as a distributed node instance in a cluster, with a load balancer uniformly allocating external access points.

[0141] In an optional implementation, registering each sub-level as a map instance allows the platform to generate an independent runtime environment for each sub-level and bind a unique numerical identifier after receiving the overall published map project, enabling addressing on the server side. For example, after a map project containing three sub-levels is published, the platform generates three map instances for each and binds them with their respective numerical identifiers. Each instance runs in an independent service process, allowing players to enter the corresponding level scene through different numerical identifiers, and the running status of each scene does not interfere with each other.

[0142] In an optional implementation, registering each sub-level as a map instance allows the platform to allocate differentiated runtime resource configurations to each sub-level based on its type and capacity requirements, and updates its instance status to accessible after registration. For example, for a map project containing small dialogues and large battle scenes, the platform allocates lightweight resources to dialogue scene sub-levels and high-concurrency resources to battle scene sub-levels, enabling each sub-level to have runtime capabilities matching its content immediately after registration.

[0143] In one exemplary application of this embodiment, the author constructed a puzzle map project comprising three sub-levels: underwater ruins, a secret chamber, and the final altar. During the draft stage, the author copied the level reference codes for each sub-level and set up cross-level teleportation relationships in the jump logic script for entering the secret chamber from the underwater ruins and reaching the final altar from the secret chamber. After completing all configurations, the author published the entire game map to the platform, registering the three sub-levels as three independent map instances at once. During runtime, the first player enters the underwater ruins map instance to begin solving the puzzle. Upon triggering a specific mechanism, the player initiates a jump request carrying the level reference code. The system parses the reference code into the map instance identifier of the secret chamber based on the mapping relationship and teleports the player to that instance. Other players can directly enter the secret chamber map instance through matchmaking to participate in the collaboration, demonstrating the independent operation of each sub-level after the multi-level map project is published as a whole, and supporting free entry and exit.

[0144] In one embodiment of the application, a method for editing a game map includes establishing a mapping relationship between a first identifier and a second identifier, which includes: Step S710: During the release process, establish a mapping relationship between the first identifier of each sub-level and the second identifier assigned to the corresponding map instance; Step S720: When updating and publishing the published sub-levels, maintain the mapping relationship between the first identifier and the second identifier of the published sub-levels before they were updated and published.

[0145] The method provided in this implementation ensures that after establishing the mapping relationship between the first and second identifiers during the release process, the existing mapping remains unchanged when the released sub-levels undergo updates, thereby decoupling level creation iteration from platform instance deployment. Authors do not need to reconfigure jump parameters after each update, effectively reducing the production and maintenance costs of multi-level content. Since the reference target of the jump script remains constant, the identifier resolution link at runtime will not be interrupted due to version iterations, significantly improving the reliability of cross-level jumps. Furthermore, the stable mapping supports continuous updates to level content without affecting the existing jump network, providing a foundation for the dynamic expansion of the game map and enriching the overall gameplay and content depth of the game.

[0146] The above plan will be explained in detail below.

[0147] In step S710, specifically, during the publishing phase, for each sub-level, a mapping association is established between its corresponding first identifier and the second identifier assigned to the corresponding map instance.

[0148] The process of mapping each sub-level's first identifier to its corresponding second identifier assigned to the map instance during the release phase allows for the association and registration of stable identity identifiers for each sub-level with the corresponding map instance identifier during the release stage. This, combined with the release process and runtime resolution, constitutes a complete identifier mapping management system. This process can be implemented by entering multiple identifier mappings at once through a batch registration interface during release; alternatively, the mapping can be triggered after the map instance is created and verified; or, a version snapshot record can be generated simultaneously when establishing the mapping.

[0149] In an optional implementation, in response to the overall release command during the release phase, the second identifiers already assigned to each map instance are batch-associated with the first identifiers of the corresponding sub-levels and centrally written into the mapping data table. This process can be automatically triggered in the background by the release service after the overall map project is uploaded, without requiring the author to manually enter the identifier information one by one, thereby ensuring the completeness, accuracy and timeliness of the mapping establishment, and effectively reducing the probability of incorrect entry or omission during manual configuration.

[0150] In other implementations, instance creation and identifier allocation operations are performed one by one for each sub-level. After the map instance of each sub-level is successfully generated in the platform backend, the publishing service triggers in real time the establishment and activation of the mapping relationship between the first identifier and the assigned second identifier of the sub-level. This method can complete the mapping registration as needed in scenarios where there are differences in platform resource allocation, thereby improving adaptability to different instance generation latencies.

[0151] In step S720, specifically, when a content update is performed on a published sub-level and then republished, the mapping association between the first identifier and the second identifier established before the update for that sub-level remains unchanged.

[0152] The update and release of published sub-levels can be an iterative release operation that modifies level content, replaces instances, and re-releases existing sub-levels. Combined with a mapping maintenance mechanism, this ensures the continued stability of identifier reference relationships during version iterations. This process can involve creating a new map instance and assigning a temporary second identifier during the update, followed by an atomic mapping switch after verification; alternatively, incremental uploads can be used to transmit only the changed data while retaining the original map instance; or, the author can choose whether to retain the original mapping relationship.

[0153] Maintaining the mapping relationship between the first and second identifiers of published sub-levels before updates and releases ensures that the existing identifier mapping binding remains unchanged during the iterative release of level content. This forms a closed-loop identifier management system throughout the entire lifecycle, together with the initial mapping establishment at release and the dynamic resolution during runtime. This process can be achieved by adding a version stamp field to the mapping table and only refreshing the version stamp during updates; alternatively, it can automatically roll back to the mapping state before the update if the release fails; or, a redundancy backup mechanism can be used to keep the mapping relationship consistent across multiple nodes.

[0154] In an optional implementation, maintaining the mapping relationship between the first identifier and the second identifier of the published sub-level before it is updated and published can be achieved by the system detecting the mapping entries of the sub-level registered in the mapping maintenance module during the update and publication process. After the map instance content is updated in the platform background, the original correspondence between the first identifier and the second identifier recorded in the entry is retained, and the entry is not replaced or deleted to maintain the continuity of the historical addressing path.

[0155] In an optional implementation, maintaining the mapping relationship between the first and second identifiers of a published sub-level before it is updated and published can be achieved by the system controlling the verification of whether there are valid historical records of the first and second identifiers of the sub-level in the mapping data table when the published sub-level is triggered to go online again in the editor. If the verification passes, the record is directly used and continues to be effective after the update and publication are completed, thereby avoiding the situation of mapping failure or identifier reassignment.

[0156] It should be noted that maintaining the mapping relationship between the first identifier and the second identifier of the published sub-level before it is updated and published can be just one of the above implementation methods, or it can be multiple of the above implementation methods. For example, the mapping can be maintained simply by retaining the original table entries, or it can be combined with version stamp refresh and redundant backup mechanisms to add update flags or cross-node consistency checks on the basis of retaining table entries.

[0157] In one exemplary application of this embodiment, after the author completes the editing of a game map containing multiple sub-levels, they initiate an overall release. During the release process, the system automatically establishes a mapping relationship between the first identifier of each sub-level and the second identifier of the corresponding map instance. Subsequently, the author optimizes the content of one of the already launched sub-levels and releases it again. While updating the map instance corresponding to that level, the system maintains the original mapping relationship between its first and second identifiers, ensuring that jump requests from other levels to that sub-level during runtime can still accurately locate the updated map instance.

[0158] One embodiment of the application provides a method for editing a game map, which further includes: Step S810: During the release process, maintain the first identifier in the association configuration information and prohibit replacing the first identifier with the second identifier.

[0159] The method provided in this implementation ensures that the association configuration information always maintains the first identifier in the draft state during the publishing process. This avoids script jump logic failure due to identifier replacement, eliminates the need for authors to return to the editor to fill in or modify the identifier after publishing, and improves the interactive experience of the creation process. At the same time, since the reference identifiers in the draft state and the published state are decoupled, authors can freely design arbitrarily complex cross-level jump networks in the draft stage, increasing the richness of game content. In addition, by prohibiting the replacement of the first identifier with the second identifier, the references in the association configuration information and the positioning identifiers in the runtime mapping table remain independent at the data level, effectively solving the data consistency and maintenance cost problems caused by identifier coupling in the publishing process.

[0160] Specifically, during the release process, the system implements protection measures for the association configuration information containing cross-level jump relationships. It maintains the original value of the first identifier used to describe the sub-level jump relationship, while preventing the release process from rewriting the first identifier to the second identifier of the corresponding map instance. This ensures that the jump reference established in the draft state remains valid after release and guarantees that the correct map instance can be resolved through an independent mapping mechanism at runtime.

[0161] Maintaining the first identifier in the relationship configuration information during the publishing process can be a maintenance strategy that keeps the original draft reference identifier in the configuration data unchanged during the publishing phase. Combined with the relationship configuration information, this ensures that sub-level references established in the draft state do not become invalid due to the publishing action. Specifically, this can be achieved by attaching integrity verification information to fields containing the first identifier when packaging the publishing data, ensuring that the publishing process only transmits the original value. Alternatively, a configuration data snapshot can be set in the publishing service, prioritizing the reading of the original first identifier from the snapshot when merging into the publishing package. Furthermore, a field protection protocol can be established between the editor and the publishing service, declaring the configuration path containing the first identifier as a publishing-immune region.

[0162] In one optional implementation, maintaining the first identifier in the association configuration information during the publishing process can be achieved by the publishing service imposing read-only protection on script data containing cross-level jump relationships when the map project is uploaded to the publishing platform as a single publishing unit. This forces the script data to retain its original value during platform backend processing, preventing the referenced first identifier from being rewritten or re-encoded by the platform publishing process. Alternatively, maintaining the first identifier in the association configuration information during the publishing process can be achieved by setting a pass-through identifier rule at the data conversion node of the publishing process. This requires that when the cross-level jump association configuration information is serialized or packaged by the platform backend, the first identifier referenced by each jump path within it must be written directly into the publishing package in its original value without escaping or mapping.

[0163] Prohibiting the replacement of the first identifier with the second identifier can serve as a constraint mechanism to block identifier replacement during the release phase. This works in conjunction with the dual-identifier mapping establishment process to prevent draft-state reference identifiers from being prematurely resolved to runtime positioning identifiers during the release phase. Specifically, the identifier types in the association configuration information can be scanned during the preprocessing phase of the release service, and the replacement process can be skipped when the first identifier is identified. Alternatively, access control can be used to prohibit the release service from performing write operations on the association configuration information. Furthermore, a double-buffering mechanism can be used to write the mapping data to an independent cache area, while prohibiting the writing of the second identifier to the original configuration area.

[0164] In one exemplary application of this embodiment, the author uses a game editor to configure cross-level portals for a game map containing sub-levels X and Y, filling in the first identifier of sub-level Y as a target parameter in the jump logic script. After completing the configuration, the author initiates a global release command. During the process of generating the map instances and second identifiers for the two sub-levels, the system maintains the first identifier in the jump logic script unchanged and prohibits replacing the first identifier in the script with the corresponding second identifier. After release, when a player enters the portal in the map instance of sub-level X, the server queries the mapping relationship based on the first identifier carried in the jump request, obtains the second identifier of the map instance of sub-level Y, and completes the cross-instance teleportation. Throughout the entire process, the author does not need to query or backfill any runtime identifiers.

[0165] In a game map editing method provided in one embodiment of the application, the step of resolving a first identifier carried in a jump request into a corresponding second identifier according to a mapping relationship includes: Step S910: Query the mapping relationship to resolve the first identifier to the currently effective second identifier.

[0166] The method provided in this implementation allows the system to accurately convert the stable identifier used by the author into the currently effective runtime instance identifier by querying the pre-stored mapping relationship during the runtime phase. This achieves dynamic decoupling between the draft identifier and the runtime identifier, avoiding the tedious operation of manually backfilling or modifying the identifier after publication. This significantly reduces system coupling and improves data processing efficiency. At the same time, the author can complete the full configuration of cross-level jump relationships in the draft state, and the runtime automatically completes the identifier resolution and instance location without the author's further intervention, greatly simplifying the interactive process of creating and publishing multi-level content. In addition, based on the stable referencing mechanism, the author can flexibly design multi-level chain structures of arbitrary complexity in the draft state, and the runtime can accurately address them, effectively supporting the richness and scalability of large-scale multi-level game maps.

[0167] Specifically, during the operation phase, in response to a jump request carrying a first identifier, the system queries the established mapping relationship between the first identifier and the second identifier and converts the first identifier into the second identifier that is currently in effect.

[0168] The query mapping relationship, which resolves the first identifier to the currently effective second identifier, can be a step in the runtime phase to resolve the author-side stable identifier to the currently effective runtime instance identifier based on the pre-stored mapping relationship. In other words, this step works in conjunction with the steps of allocating stable identifiers in draft mode and establishing mapping relationships during publication to achieve seamless identifier conversion during cross-level transitions. Furthermore, this query processing can accelerate the parsing process by querying the mapping relationship using a hash index, reduce the overhead of repeated queries by caching recent query results, and support multi-server scenarios by querying through a distributed mapping service.

[0169] In one optional implementation, querying the mapping relationship to resolve the first identifier to the currently effective second identifier can be achieved by the server extracting the level reference code from the jump request after receiving a cross-level jump request at runtime, accessing the internally maintained mapping data, matching the level reference code to the currently corresponding map identifier, and thus determining the actual running address of the target map instance. Alternatively, after receiving a jump request, the server can retrieve internal mapping records based on the draft state identifier carried in the request, obtain the currently effective runtime identifier assigned to that identifier during the release phase, and locate the corresponding online map instance in the platform environment based on that runtime identifier to complete the addressing.

[0170] It should be noted that querying the mapping relationship to resolve the first identifier to the currently effective second identifier can be just one of the above implementation methods, or it can be multiple of the above implementation methods simultaneously. For example, the server can complete the identifier resolution through conventional mapping record retrieval, or it can combine hash indexes and caching strategies to improve resolution efficiency, or it can use sharded queries to achieve resolution in distributed deployment scenarios.

[0171] In one embodiment of the application, a method for editing a game map, after locating the corresponding map instance based on the parsed second identifier, further includes: Step S1010: The target virtual character in the game map is transferred from the current map instance to the map instance corresponding to the second identifier; wherein, the running state of each map instance is independent of each other, each map instance allows the virtual character to enter from the current map instance to the map instance determined based on the second identifier; or, each map instance allows the object to exit from the current map instance midway.

[0172] The method provided in this embodiment enables the map instance located by the parsed second identifier to be used as the actual target for virtual character teleportation, and assigns each map instance an independent running state, with no interference between instances. Thus, when the target virtual character is teleported from the current map instance to the target map instance, its actual migration process can be completed independently in an isolated running environment, avoiding state coupling and resource contention between different level instances. At the same time, since each map instance supports virtual characters entering the target instance determined by the second identifier and supports objects exiting midway, players can flexibly move between multiple independent level instances according to the game progress, without waiting for a unified room state or being constrained by a single process. This not only solves the coupling and synchronization problems of multi-instance parallel operation at the architectural level, but also significantly improves the user's interactive freedom and continuous experience in multi-level scenarios, thereby enriching the overall game's level-connecting gameplay and dynamic content arrangement space.

[0173] Specifically, after locating the target map instance based on the second identifier, the target virtual character in the current map instance is transferred to the target map instance, thereby completing the migration process of the virtual character across map instances.

[0174] Specifically, teleporting a target virtual character within the game map from the current map instance to the map instance corresponding to the second identifier can be an operation triggered by runtime map identifier resolution results, allowing the virtual character to migrate across independent instances. This works in conjunction with the architecture where each map instance operates independently, transforming the identifier resolution results into spatial transfers of the virtual character across instances. Alternatively, it can also involve migrating a non-player-controlled object from the current instance to the target instance, or projecting the virtual character's following viewpoint to the target instance and generating a reverse teleportation channel within the target instance.

[0175] In an optional implementation, transferring a target virtual character within the game map from the current map instance to the map instance corresponding to the second identifier can be achieved by the server, in response to a jump command, completely migrating the virtual character and its current state data from the process space of the original map instance to the process space of the target map instance, and reloading the virtual character in the memory of the target map instance to maintain its behavioral continuity. For example, when a virtual character triggers a cross-level jump through a portal, the server removes the virtual character's location coordinates and inventory data from the current map instance and writes them into the memory of the target map instance determined by the second identifier, allowing the virtual character to be loaded at the spawn point of the target map instance and continue running.

[0176] In one optional implementation, the target virtual character located on the game map is transferred from the current map instance to the map instance corresponding to the second identifier. This can involve creating a mapping object of the virtual character in the target map instance and establishing the virtual character's local interactive state according to the environmental rules of the target map instance, enabling it to have behavioral capabilities that meet the scene requirements in the new instance. For example, when a virtual character moves from a desert level instance to a snow mountain level instance, the server generates the virtual character's object data in the snow mountain level instance and configures the virtual character with the cold resistance attributes and movement parameters required for the snow mountain environment, allowing it to participate in combat and exploration normally in the new map instance.

[0177] In this architecture, each map instance operates independently, allowing for independent process resources and lifecycles. This, combined with the second identifier allocation mechanism, provides an isolated operating environment for virtual roles to navigate between instances without interference. Alternatively, each map instance can be deployed on different physical server nodes; each instance can also have its own independent database connection pool and memory management unit; or, each instance can have its own independent matching queue and player limit configuration.

[0178] In an optional implementation, the running states of each map instance are independent of each other. Each sub-level can be instantiated as a completely isolated process space on the server after it is published. The logical operations and state updates in each process space do not interfere with each other, and an anomaly in a single process will not spread to other processes.

[0179] In one optional implementation, the running status of each map instance is independent of each other, meaning that the interruption or restart of the operation of any map instance will not cause the synchronization interruption or data rollback of other map instances, and each instance has independent online and offline scheduling capabilities. For example, when the snow mountain level instance needs to be restarted due to a version update, the desert level instance and forest level instance associated with it can continue to run, and the game process of the virtual characters within each instance will not be affected. After the restart is completed, the virtual characters can still jump normally from the desert level instance to the snow mountain level instance.

[0180] It should be noted that the running status of each map instance is independent of each other. It can be only one of the above implementation methods, such as using only an independent process space for isolation; or it can be multiple of the above implementation methods at the same time. For example, each instance runs in an independent process space and is isolated from each other at the physical server level, and restarting a single instance does not affect other instances.

[0181] Each map instance allows virtual characters to enter a map instance determined by a second identifier from the current map instance, providing instance access capabilities that enable virtual characters to migrate forward from the current running instance to the target running instance. This, in conjunction with character teleportation actions and an independent operating architecture, constructs a complete cross-level forward jump link. Furthermore, it can support multiple virtual characters entering the target map instance simultaneously as a team; or virtual characters entering the target map instance while carrying specific items; or virtual characters entering the target map instance triggered by non-teleportation interaction nodes.

[0182] In an optional implementation, each map instance can support virtual characters to enter a map instance determined based on a second identifier from the current map instance. A trigger-based teleportation area can be deployed in the current map instance. When a virtual character enters the area, the server sends a loading instruction for the target map instance to it and controls it to complete the transfer.

[0183] In an optional implementation, each map instance allows virtual characters to move from the current map instance to a map instance determined based on the second identifier. This can be achieved by the server actively moving the virtual character from the current map instance to the target map instance determined based on the second identifier after the virtual character meets the preset game conditions, without the virtual character having to manually trigger a fixed scene teleportation point.

[0184] The system allows objects within each map instance to exit mid-game, providing a flexible exit mechanism that enables game objects to detach from the current map instance during runtime. This, combined with an independent operating architecture and forward entry capabilities, enables bidirectional dynamic instance member management. Another feasible solution allows virtual characters to exit the current instance and return to the lobby using a safe zone return item; allows virtual characters to exit the current instance due to disconnection while retaining their pre-disconnect state; and allows non-player-controlled objects to automatically destroy themselves and exit the current instance after completing a task.

[0185] In an optional implementation, each map instance supports objects leaving the current map instance midway. This can be achieved by having the server remove a virtual character from the player list of the current map instance after the virtual character triggers a specific interaction option in the current map instance, and release the computing and bandwidth resources occupied by the virtual character within the instance.

[0186] It should be noted that each map instance supports objects exiting the current map instance midway. This can be just one of the above implementation methods, such as only supporting virtual characters to actively trigger interaction options to exit; or it can be multiple of the above implementation methods at the same time, such as supporting both active interaction to exit and automatic offline exit when there is a network error, so as to ensure that objects can flexibly leave the current instance in various scenarios.

[0187] In one exemplary application of this embodiment, after a virtual character completes the final challenge of the current instance map, the client sends a redirection request carrying a first identifier to the server. The server resolves the first identifier to a second identifier based on the mapping relationship and locates the corresponding reward map instance. Subsequently, the target virtual character is transferred from the current instance map instance to the reward map instance. During this process, since the operating states of each map instance are independent, the current instance map instance will not interrupt the service to other team members due to the virtual character's departure. At the same time, external virtual characters can directly enter the reward map instance based on the second identifier, and virtual characters currently playing can also exit midway and return to the lobby map instance at any time through the interactive menu, thereby realizing flexible and isolated character transfer between multiple map instances.

[0188] In one embodiment of the application, a method for editing a game map, when the game map is in a draft state, controls the assignment of corresponding first identifiers to the multiple sub-levels included in the game map, including: Step S1110: When the game map is in draft state, respond to the level creation command, control the creation of sub-levels and assign a first identifier to the sub-levels; Step S1120: Control the display of the first identifier.

[0189] The method provided in this implementation allows for the automatic assignment and immediate display of stable first identifiers for newly created sub-levels during the draft stage of map engineering. This enables creators to obtain identity credentials that can be used for cross-level referencing early in the creation process, without having to wait for the publishing process to finish before querying and backfilling. This effectively reduces the creation threshold and operational burden of multi-level maps, improves the interactive efficiency of the editor and the richness of map content creation, and decouples draft-state identifier management from published-state instance addressing at the system architecture level.

[0190] The above plan will be explained in detail below.

[0191] In step S1110, specifically, when the map project is in an unpublished and editable state, the system receives a level addition request initiated by the creator, controls the generation of the corresponding sub-level data object, and calls the internal identification service to generate a unique first identifier for the sub-level.

[0192] Specifically, responding to level creation commands while the game map is in draft mode can be a triggering method during the editing phase when the map project is in an unpublished state, receiving requests from creators to add levels. Furthermore, this triggering method works in conjunction with an identifier allocation service, enabling the system to establish a stable identity foundation for newly added sub-levels during the level creation initiation phase. In addition, this triggering method can also be implemented by responding to voice input level creation commands, shortcut key input level creation commands, or batch import commands to generate multiple sub-levels while in draft mode. Moreover, this interactive operation can be implemented through click, swipe, long press, and / or other operations. Taking a click operation as an example, when the map project is in draft mode, the system detects a click operation performed by the creator on a new control in the level management interface and generates a level creation command in response to this click operation.

[0193] For example, when the map project is in draft mode, the creator can move the cursor to the level list area on the left and click the "Add" button at the bottom. The system will then receive the level creation instruction generated by the click event and create a new blank sub-level in draft mode.

[0194] Among these, controlling the creation of sub-levels and assigning a first identifier to them is the core processing action that allows the system to automatically initialize level data objects and bind stable identity identifiers during the map editing phase. Furthermore, this processing action, combined with the draft editing environment, provides a unified level identity benchmark for subsequent relationship configuration and mapping release. In addition, this processing action can also be implemented by loading templates from a preset template library to generate sub-levels and assign hash identifiers, creating new levels based on replicas of existing sub-level configuration copies and assigning sequence identifiers, or creating blank levels and generating composite identifiers containing timestamps and random codes.

[0195] In an optional implementation, controlling the creation of sub-levels and assigning a first identifier to them can involve the system, upon responding to a new creation request, calling a random character generation interface from a local identifier service to obtain a unique mixed string containing uppercase and lowercase letters and Arabic numerals as the level's identity identifier, and binding this identifier to the level's basic metadata. For example, after a creator triggers a new creation command, the system calls the identifier generation interface in the editor's background to generate a stable identifier string containing uppercase letters and numbers for the new sub-level, and writes this identifier string along with the level's metadata into the local configuration file of the map project. For example, if there are already three sub-levels in the map project, and the creator triggers a new creation operation again, the system reads the maximum sequence value among the existing identifiers and performs an increment operation to generate a new numeric or alphanumeric incrementing identifier, and assigns this incrementing identifier to the newly created fourth sub-level.

[0196] In one optional implementation, the first identifier is a system-generated identifier during the level editing stage, belonging to the map referencing parameters. After a map is published, navigation between different maps cannot be achieved directly by filling in this referencing parameter. After publication, if the author needs to link two different maps during further map creation, navigation between the maps must be achieved using the second identifier, i.e., the map ID, or a map sharing code.

[0197] In step S1120, specifically, after completing the creation of the sub-level and the assignment of the first identifier, the system presents the first identifier in a visual form in the editor interface for the creator to view or copy.

[0198] The control over displaying the first identifier can be an operation that outputs the system-generated level identity identifier in a visual form to the creator's visible interface. Furthermore, this display operation is closely integrated with the identifier allocation operation, allowing creators to immediately obtain identity credentials that can be used for cross-level referencing after level creation. In addition, this display operation can also be implemented by displaying the first identifier as a floating tooltip above the level node, rendering the first identifier in a read-only field of the attribute panel and providing a one-click copy control, or displaying it as a QR code graphic on the level details page.

[0199] In one optional implementation, the control for displaying the first identifier can be achieved by creating a fixed text area next to the name of each sub-level node in the persistent interface of the level management list. The system-assigned first identifier is rendered in this area as non-editable text, allowing creators to directly view and manually copy the unique identifier of each level when browsing the level hierarchy tree. For example, after a creator completes the creation of a sub-level, the system-assigned first identifier is automatically displayed to the right of the new level node in the level hierarchy tree on the left side of the editor. This identifier is displayed as gray text next to the level name, and the creator can directly select and copy the identifier text.

[0200] In other implementations, the system creates a dedicated display area in the read-only information area of ​​the attribute configuration panel to display the first identifier corresponding to the currently selected sub-level, and configures a one-click copy interactive control next to this area so that creators can quickly obtain the identifier content.

[0201] like Figure 3As shown in an exemplary application of this embodiment, the creator starts the map editor and opens a new map project in draft mode. In the level management panel, multiple sub-levels are created sequentially. Each time a sub-level is created, the system automatically assigns a level ID to the corresponding sub-level in the background and immediately renders the first identifier as gray text in the right area of ​​the level node name. After browsing these first identifiers, the creator can directly select and copy one of the identifiers and save it to the clipboard for use in subsequent creation stages. This completes the batch initialization and visualization configuration of multiple level identifiers in draft mode without publishing the map project.

[0202] In one embodiment of this application, a method for editing a game map further includes: Step S1210: Set the second identifier to be undisplayed in the author's side editor interface; the second identifier is only queried based on the first identifier on the runtime server side.

[0203] The method provided in this embodiment simplifies the interactive interface presented to the author by setting the second identifier to be invisible in the author's editor interface and limiting the query path of the second identifier to queries based on the first identifier on the runtime server side. The author only needs to complete the cross-level association configuration and chain design based on the stable first identifier, without having to pay attention to the dynamically allocated second identifier at runtime. This reduces the cognitive load and risk of misoperation during the creation process and improves the interactive experience. At the same time, since the runtime identifier is completely isolated from the author side, the management boundary of multi-level map projects is clearer. The author can more flexibly arrange large game maps with complex jump relationships, thereby improving the richness of the game. In addition, the second identifier is queried based on the first identifier within the server side, which effectively avoids the security risks caused by the direct exposure of the runtime instance identifier to the client or editor. It realizes the isolation of identifier permissions between the creation side and the runtime, and solves the access control and information leakage problems under the dual identifier system.

[0204] Specifically, after instantiating each sub-level into an independent map instance during the release phase, the system will hide the second identifier corresponding to the runtime instance in the author's interface view during runtime, preventing the author from directly observing or calling the second identifier during editing processes such as modeling, script writing, and attribute viewing. At the same time, the system establishes an internal mapping link from the first identifier to the second identifier and restricts the runtime instance identifier to be used only internally on the server side in response to a jump request, based on the first identifier it carries for reverse lookup and parsing. Neither the author's side nor the client directly participates in the reading process of the second identifier.

[0205] Setting the second identifier to be invisible in the author's editor interface can be a configuration strategy for masking the visibility of runtime map instance identifiers and filtering the interface on the author's side of the editor. Correspondingly, this configuration strategy works in conjunction with the first identifier system, ensuring that only the stable first identifier is exposed on the author's side, avoiding interference from runtime identifier changes in the creation process. Furthermore, the editor can add a global switch in preferences, allowing authors to choose whether to display runtime identifier information; alternatively, it can differentiate the display for author accounts with different permission levels, with ordinary editors unable to see the second identifier, while advanced administrators can see it in debug mode; or, the second identifier can be stored in a hidden field in the project configuration file, skipping the reading and display of this field during editor interface rendering.

[0206] Optionally, when loading level configuration data during the editor interface initialization phase, fields containing the second identifier can be filtered and rendered so that the second identifier content is not displayed in the author's level management panel, attribute bar, and script prompts.

[0207] Optionally, a storage record with a second identifier can be retained in the editor's local project data structure, but the field is marked as an internal system property, and the interface layer skips the textual display of the property and the generation of editable controls when constructing each edit view.

[0208] For example, when the author opens the level management interface to view the list of created sub-levels, only the string of the first identifier is displayed in the details card of each sub-level, and the numerical instance number automatically assigned by the platform is completely hidden in the editing view.

[0209] For example, when the development team is collaboratively editing a map project, all members can only see the stable reference code generated by the system when viewing level attributes in the editor client, while the numerical identifiers obtained by each map instance during the release phase are only stored in the server database.

[0210] The second identifier being queried only on the runtime server side based on the first identifier can be a server-side access control strategy that restricts query permissions and paths for runtime map instance identifiers to a single entry point. Furthermore, the query interface can be encapsulated in the client-side redirect script, allowing the client to only transmit the first identifier, with the server gateway uniformly executing the mapping query and routing to the target instance; alternatively, a multi-factor authentication mechanism can be established, rejecting any external redirection request directly carrying the second identifier, except for internal server queries; or, the query operation for the second identifier can be incorporated into the server-side authentication process, allowing parsing only when the requester has a valid session state.

[0211] In some embodiments, the second identifier is queried only on the runtime server side based on the first identifier. This can be achieved by the jump execution module querying the corresponding second identifier in the background through the mapping service maintained internally by the server after receiving a transmission request carrying the first identifier. Neither the author side nor the client participates in this parsing process.

[0212] In some embodiments, the second identifier can be queried only on the runtime server side based on the first identifier. This means that the query interface for the second identifier is only open to the runtime server. The editor side, client local scripts, and external developer tools do not have permission to directly call the mapping table to read or traverse the relevant records of the second identifier.

[0213] The second identifier being queried based on the first identifier only at runtime on the server side can be just one of the above implementation methods, or it can be multiple of the above implementation methods simultaneously. For example, the server can either execute background queries independently through an internal mapping service, or it can combine this with a permission isolation mechanism to restrict direct access to the second identifier by external systems, while the server internally completes the parsing from the first identifier to the second identifier in the redirection request processing flow.

[0214] In one embodiment of this application, a method for editing a game map further includes: Step S1410: After the association configuration information is configured, the first identifier is simulated in draft state to verify the validity of the cross-level association.

[0215] The method provided in this embodiment enables the simulated parsing of the first identifier in the draft state immediately after the association relationship is configured, thereby verifying the validity of the cross-level association relationship before the official release. This technical means allows creators to confirm the correctness of the cross-level jump logic during the editing stage without waiting for the game map to be released, significantly improving the interactive experience of the creation process. It enables complex jump relationships between multiple levels to be discovered and corrected as early as possible, thereby enriching the level design verification methods and content production depth of the game map. At the same time, it effectively solves the computer field problem in the prior art where the association relationship cannot be practiced in the draft state and the validity of the cross-level logic can only be verified after multiple releases and reflows.

[0216] Specifically, after the association configuration information is configured, a simulated parsing is performed on the first identifier in the draft state to verify the validity of the cross-level association.

[0217] The configuration of the relationship information can serve as a stage trigger condition to limit the timing of the verification operation and indicate that the cross-level jump relationship has been configured. Furthermore, it can be an automatic trigger state after the script editing module detects that all jump logic scripts have been compiled, a response condition after receiving a manual verification command, or a pre-ready state after the relationship configuration information is automatically saved.

[0218] For example, after the author enters the first identifier of the last target sub-level in the jump logic script and performs a save operation, the system determines that the association configuration information has been configured and automatically triggers the subsequent simulation parsing process. As another example, if a map project contains three sub-levels, and the author configures jump relationships from each sub-level to the other two sub-levels, and the system verifies that no references are omitted, it confirms that the association configuration information has been configured.

[0219] Specifically, simulating the parsing of the first identifier in draft mode can be a pre-rehearsed parsing and conversion operation performed on the stable identifier string allocated by the system in draft mode. It simulates the identifier mapping logic before official release to detect reference anomalies in advance. Furthermore, it can perform preview parsing of the first identifier in a visual debugging panel, simulate the mapping from the first identifier to a temporary instance identifier in a local sandbox environment, or pre-parse the first identifier based on a mapping snapshot cached locally by the editor.

[0220] In an optional implementation, simulating the parsing of the first identifier in draft mode can be a pre-visualized parsing of the first identifier in a visual debugging environment to output the corresponding simulated target instance information. For example, after the author triggers verification, the editor reads the first identifier in the jump logic script in the background and calls the simulated mapping service to output the temporary target instance identifier that the first identifier theoretically maps to, and displays the result in the debugging panel.

[0221] In an optional implementation, simulating the parsing of the first identifier in draft mode can be a static parsing deduction of the first identifier based on a temporary mapping snapshot maintained locally by the editor.

[0222] Verifying the validity of cross-level associations can serve as a preliminary check to confirm the correctness of cross-instance jump logic between multiple sub-levels. It identifies jump configuration errors in advance during the draft state to avoid runtime cross-instance transfer failures.

[0223] In an alternative implementation, verifying the validity of cross-level associations can be done by traversing each first identifier in the association configuration information and querying local level management data to determine whether the referenced sub-levels actually exist.

[0224] In an optional implementation, verifying the validity of cross-level associations can involve performing connectivity deduction on cross-level jump paths to confirm whether there is a valid jump link between the starting sub-level and the target sub-level.

[0225] In one exemplary application of this embodiment, for a map project containing multiple sub-levels, after the author completes the configuration of the jump relationship between each sub-level in the editor, he initiates a validity check. The system reads the first identifier in the association configuration information in the draft state and performs simulated parsing to check for the presence of invalid sub-level references. After confirming that the cross-level association relationships are all valid, the system provides feedback to the author on the verification result, enabling the author to complete the closed-loop confirmation of the cross-level jump logic before the game map is published.

[0226] One embodiment of the application provides a method for editing a game map, in response to a game map publishing command, controlling the generation of map instances corresponding to each sub-level includes: Step S1510: In response to the game map release command, control the uploading of the overall data of the game map. The overall data includes the level content data of each sub-level and the association configuration information. The first identifier in the association configuration information remains unchanged.

[0227] The method provided in this implementation avoids intrusive modifications and repeated backflow operations to the jump configuration during the publishing phase by uploading the entire data and maintaining the first identifier in the association configuration information unchanged during the upload process when responding to the game map release command. The cross-level jump logic configured by the creator in the draft state can be submitted to the platform at once with the entire data and take effect directly, without having to return to the editor to query or refill the runtime identifier after publishing. This significantly reduces the engineering complexity and operational threshold of publishing multi-level content. This simplification of the process allows creators to focus more on the design of the level association structure itself, and dare to try more complex multi-line connection and branch jump architecture, thereby improving the richness and playability of game content. At the same time, since the system can automatically complete the data upload and instance mapping after the release command is triggered, the interaction steps between the creator and the platform are greatly reduced, the interaction experience is optimized, and it also effectively solves computer field problems such as data inconsistency and version management chaos that may be caused by manual intervention to refill the identifier.

[0228] Specifically, upon receiving a release instruction for the game map, the system uploads the complete project data, including the content of each sub-level and cross-level jump association information, in one go. Among them, the level content data of each sub-level and the association configuration information are packaged together into the whole data, and the first identifier referenced in the association configuration information remains in its original state throughout the upload process without any replacement or modification, so as to ensure that when the platform generates map instances later, it can establish a mapping between the original association configuration information and the runtime identifier.

[0229] Among these features, the upload of the entire game map data in response to the game map's release command can be triggered and completed by the creator, enabling project-level data submission. For example, after completing the script for connecting three sub-levels, the creator can click the release option in the editor. The editor will compress and upload all level files and jump configurations from the project directory. Upon receiving the upload, the platform will create corresponding map instances for each level. Alternatively, the creator can mark the current version as a release candidate in the version management panel. The build tool will automatically detect this mark and call the upload interface to transmit the game map data package, containing all sub-level resources and logic, to the target server cluster.

[0230] The overall data, including the level content data of each sub-level, can be a component of the published data package containing the specific resources and logical content of each sub-level. This component, together with the associated configuration information, forms complete engineering data, supporting the platform in instantiating each sub-level. In one extended solution, the level content data may include static terrain meshes and material texture information; in another, it may include dynamic entity templates and script bytecode; and in yet another, it may include lighting baking data and pathfinding / navigation meshes.

[0231] In some optional implementations, the overall data, including the level content data of each sub-level, can be terrain resources, entity placement information, and interaction logic scripts organized by level directory in the uploaded data package. For example, a game map project may include forest and desert levels. When uploading the entire project, the scene files, NPC configuration tables, and combat logic scripts for both levels are packaged separately, and the platform generates independent runnable instances based on these.

[0232] In some alternative implementations, the overall data, including the level content data of each sub-level, can be serialized level snapshot data, which includes level geometry, material references, and dynamic object states. For example, if a creator places destructible cover and vehicle spawn points for sub-level A in the editor, this data can be uploaded as a serialized snapshot along with the overall data upon publication, for the target server to load and restore.

[0233] The overall data, including the relationship configuration information, can be structured relationship data describing the cross-level jump logic between multiple sub-levels. This structured relationship data is uploaded together with the level content data, ensuring that the platform maintains the preset cross-level jump link after instantiation. In one extended solution, the relationship configuration information can record jump nodes and conditions in JSON format; in another solution, the relationship configuration information can be embedded in the project as script source code; and in yet another solution, the relationship configuration information can be stored in the form of visual data.

[0234] In an optional implementation, the overall data, including the association configuration information, can be directed graph structure data organized by jump source level and target level, wherein the first identifier corresponding to each node is recorded.

[0235] In an optional implementation, the overall data, including the association configuration information, can be a set of jump rules embedded in the map project configuration table, with each rule recording the source identifier, target identifier, and triggering conditions.

[0236] It should be noted that the overall data, including the relationship configuration information, may be only one of the above implementation methods, or it may be multiple of the above implementation methods simultaneously. For example, the relationship configuration information may include both the directed graph structure and the rule configuration table, or one of them may be selected for use in different applications.

[0237] Maintaining the original identifier in the association configuration information serves as a constraint to preserve the originality of the level reference identifier throughout the map data upload and platform instantiation process. This constraint, combined with the dynamic mapping mechanism, prevents creators from having to rework and modify the redirection logic after publication due to identifier changes. In one extended solution, the system can ignore the automatic replacement of the first identifier in the configuration information during the upload phase; in another solution, the first identifier can be maintained as the internal index key during the platform registration phase; and in yet another solution, the system can retain the first identifier from the historical association configuration during version rollback.

[0238] In one specific application, the creator completes an open-world map project containing five sub-levels in the editor, with each level interconnected via jump scripts. The creator clicks the publish button in the editor interface. In response, the system uploads all data, including the content data for the five levels and the association configuration information described by the first identifier, all at once. Upon receiving the overall data, the platform server generates corresponding map instances for each of the five sub-levels. The first identifier in the jump configuration remains unchanged, and the platform internally establishes a mapping relationship with the second identifier. This allows each sub-level to jump across instances based on the original association configuration information after going live, without requiring the creator to return to the editor to modify or re-fill the identifiers after publishing.

[0239] In a game map editing method provided in one embodiment of this application, establishing and maintaining the mapping relationship between a first identifier and a second identifier includes: Step S1610: Maintain the mapping data table; the table entries of the mapping data table include the first identifier of the sub-level and the second identifier assigned to the corresponding map instance.

[0240] The method provided in this implementation allows authors to maintain the mapping data table only once in the draft state, enabling automatic association between the first and second identifiers. This avoids manually modifying the addressing parameters in the jump script after each release or update, thus improving the interactive experience and making the logical design of multi-level connections smoother. Simultaneously, maintaining the mapping data table allows each sub-level to be flexibly organized as an independent map instance, enriching the combination and gameplay dimensions of game levels. Furthermore, using a structured mapping data table to manage the identifier mapping relationships required at runtime effectively solves the identifier resolution consistency problem in multi-instance dynamic addressing in the computer field, ensuring that cross-level jump requests accurately hit the target map instance.

[0241] Specifically, when establishing and maintaining the mapping relationship between the first identifier and the second identifier, the system uses a mapping data table as a record carrier. Each item in the mapping data table contains both the first identifier of the sub-level and the second identifier assigned to the map instance corresponding to the sub-level when it is published, thereby realizing a structured association between stable identifiers and runtime dynamic identifiers.

[0242] Maintaining the mapping data table can be a structured data recording mechanism that establishes and maintains the identifier mapping relationship within the system. Based on this, the mechanism works in conjunction with the first and second identifiers to associate and store the stable identity of the checkpoint with the dynamic instance address. Furthermore, the above mapping relationship can also be implemented through key-value databases, distributed caching services, or relational tables in relational databases.

[0243] In an alternative implementation, maintaining the mapping data table can involve the system automatically generating a first identifier and the platform-assigned second identifier as a key-value pair when a new level is released, and then returning the currently valid second identifier in subsequent queries.

[0244] In an optional implementation, maintaining the mapping data table can also ensure that when a released level is updated and re-released, the system maintains the original correspondence between the first identifier and the second identifier of the level in the mapping data table, thus avoiding mapping failure due to version iteration.

[0245] In a specific application, after the author completes the design of a multi-level map in the game editor and triggers the release command, the release module registers each map instance with the platform and obtains the second identifier returned by the platform. The mapping maintenance module then establishes a mapping data table, recording the pairing relationship between the first identifier and the corresponding second identifier for each sub-level in the table entries. Subsequently, when a player triggers a cross-level jump during runtime, the server receives the jump request carrying the first identifier, queries the mapping data table, resolves the first identifier to the currently effective second identifier, and then locates the target map instance to complete the teleportation.

[0246] In a game map editing method provided in one embodiment, during runtime, resolving a first identifier carried in a jump request to a corresponding second identifier according to a mapping relationship includes: Step S1710: Receive a redirection request and query the mapping relationship to obtain the currently effective second identifier; Step S1720: Locate the corresponding map instance based on the second identifier.

[0247] The method provided in this implementation allows the runtime server to dynamically obtain the currently effective second identifier by querying the mapping relationship after receiving a jump request carrying the first identifier, thereby locating the corresponding map instance. This achieves automatic conversion between the draft state stable identifier and the runtime instance identifier. Players do not need to perceive the differences in the underlying identifier system during cross-level jumps, thus obtaining a continuous and seamless game jump experience and improving the interactive experience. At the same time, the complex connection relationship of multiple sub-levels based on independent map instances can be accurately parsed and executed at runtime, expanding the flexibility of map editing and the richness of game content. In addition, the runtime dynamic parsing mechanism eliminates the identifier connection dependency caused by the publication of multiple sub-levels as independent map instances under the state synchronization architecture, avoiding multiple reflows and edits after publication, and significantly improving the development efficiency and system compatibility of multi-level game content.

[0248] The above plan will be explained in detail below.

[0249] In step S1710, the server receives a jump request from the game client or other service modules. The request carries the first identifier of the target sub-level. The server queries the established and maintained mapping relationship to obtain the effective second identifier corresponding to the first identifier.

[0250] Receiving redirection requests can be the entry point for runtime processing of cross-level redirection requests. This operation, cascaded with mapping queries and instance location, forms a dynamic resolution chain. Specifically, receiving redirection requests can be triggered by internal server logic, initiated by the client based on changes in virtual character status, or automatically generated in response to platform timed events.

[0251] Among them, querying the mapping relationship to obtain the currently effective second identifier can be the core query operation that converts the first identifier into the second identifier based on the pre-stored mapping data at runtime. Specifically, querying the mapping relationship to obtain the currently effective second identifier can be done by querying the memory hash mapping table, by querying the mapping record in the distributed cache, or by querying the mapping table entry in the relational database.

[0252] In one optional implementation, querying the mapping relationship to obtain the currently effective second identifier can be a query call initiated by the jump execution module to the mapping maintenance module, and receiving the latest map identifier corresponding to the first identifier. For example, when the server receives a jump request carrying the first identifier, the jump execution module requests a query from the internal mapping maintenance module, and the mapping maintenance module returns the currently effective map identifier as the second identifier to respond to the addressing request.

[0253] In one optional implementation, querying the mapping relationship to obtain the currently effective second identifier can be a process of retrieving the identifier mapping data table based on the first identifier and extracting the corresponding map instance identifier. For example, the server maintains a mapping data table containing the correspondence between checkpoint reference codes and map identifiers. Upon receiving a query request, the server retrieves the table using the first identifier as an index, extracts the currently effective second identifier, and passes it to the instance positioning module.

[0254] In a specific application, the runtime server-side jump execution module receives a cross-level teleportation request triggered by a virtual character in the current map instance. This request carries the first identifier of the target sub-level. The module initiates a query call to the mapping maintenance module, which retrieves the internal mapping data table based on the first identifier and returns the currently effective second identifier to the jump execution module.

[0255] In step S1720, the server determines and locates the corresponding map running instance in the runtime addressing system based on the parsed second identifier.

[0256] In a specific application, after obtaining the second identifier, the server-side jump execution module locates the map instance B corresponding to the second identifier through the platform addressing service, and then transmits the virtual character that initiates the cross-level teleportation from map instance A to the runtime environment of map instance B.

[0257] In one embodiment of this application, a method for editing a game map further includes: Step S1810: Synchronize the object from the state of the current map instance to the target map instance. State synchronization includes at least one of the object's position state and attribute state.

[0258] The method provided in this embodiment, after locating the target map instance based on the second identifier, synchronizes the object's state from the current map instance to the target map instance. This allows the object's position and attribute states to be reproduced after cross-map instance transfer, thus avoiding the problem of character position reset or attribute loss when players switch scenes, significantly improving the continuity and immersive experience of game interaction. At the same time, since object states can flow and be inherited between different map instances, game designers can construct more complex and interconnected multi-map worlds, enriching the gameplay layers and content diversity. In addition, this state synchronization process achieves the continuity guarantee of object states across independently running instances under the state synchronization architecture, effectively solving the technical problem of object state migration in a distributed map instance environment.

[0259] Specifically, after locating the target map instance, the operation of synchronizing the object from the current map instance to the target map instance is performed to ensure the continuity of the object's operation in a cross-instance environment.

[0260] Synchronizing an object's state from the current map instance to the target map instance can be a data transfer process that migrates the object's runtime context between independently running map instances while maintaining the continuity of the object's state. After locating the target map instance based on the second identifier, the object's current data is transferred to the target instance to reproduce its original runtime state. This can be a full snapshot migration method, an incremental field synchronization method, or a forwarding method based on an independent state relay service.

[0261] In an alternative implementation, synchronizing an object from the state of the current map instance to the target map instance can be achieved by extracting all current runtime state information of the object and generating a state snapshot before the object leaves the current map instance, which is then sent by the system to the target map instance for restoration.

[0262] In an optional implementation, synchronizing an object's state from the current map instance to the target map instance can be achieved by having the server query the object's latest authority status in the current map instance before the object enters the target map instance, and then writing the query result to the object manager of the target map instance. For example, after a player character triggers cross-map teleportation, the server queries the current forest map instance for the character's real-time status and synchronizes that status to the character manager of the target snowfield map instance.

[0263] State synchronization includes the cross-instance migration process that records and reproduces the object's position state, which can be the coordinates and orientation information of the object in the three-dimensional virtual space. This can be achieved through direct mapping of absolute coordinates, relative offset calculation based on the entry point, or alignment of navigation mesh nodes.

[0264] In an optional implementation, state synchronization includes the object's positional state. During state synchronization, the spatial transformation information of the object in the current map instance, including three-dimensional coordinates and orientation angle, can be prioritized for migration to reconstruct the object's spatial occupancy in the target map instance. For example, when a character is transferred from a plaza map instance to an indoor map instance, the system synchronizes its three-dimensional coordinates and orientation in the plaza to the indoor instance, so that the character appears at the corresponding entrance position indoors and maintains the same orientation.

[0265] In an optional implementation, state synchronization includes converting the object's position state into a relative entrance offset corresponding to the level, based on the level design of the target map instance, and then writing it into the target instance. For example, when a character is teleported from an open-world map instance to a copy map instance, the system converts its absolute coordinates into offset coordinates relative to the copy entrance, causing the character to appear at a preset spawn point inside the copy entrance.

[0266] State synchronization includes the process of inheriting and reconstructing configurable parameter information generated during the object's runtime across map instances. Internal capability data is carried during state synchronization, allowing the object to maintain its existing level, equipment, and skill configuration in the target map instance. This can be achieved through equipment and level data synchronization, skill cooldown and duration synchronization, or quest progress marker synchronization.

[0267] In an optional implementation, state synchronization may include migrating the object’s attribute state to the target map instance as the main content of the state package during the state synchronization process, using the object’s currently held configurable attribute data, including level, experience and equipment parameters.

[0268] In an optional implementation, state synchronization includes the object's attribute state, which can be a time-sensitive attribute state. During synchronization, a timestamp or remaining duration information of the state's effective date is appended, so that the target map instance can continue the state effect according to the original progress.

[0269] It should be noted that state synchronization, including the object's attribute state, can be just one of the above implementation methods, or it can be multiple of the above implementation methods simultaneously. For example, when synchronizing object attributes, only equipment data can be synchronized; or, equipment data and skill state can be synchronized simultaneously to fully preserve the object's current ability configuration.

[0270] refer to Figure 4As shown, this disclosure provides a game map editing device 400, including: an allocation module 410 configured to, when the game map is in a draft state, control the allocation of corresponding first identifiers to multiple sub-levels included in the game map; a configuration module 420 configured to, in response to an association configuration instruction, determine association configuration information, wherein the association configuration information is configured based on the first identifier and is used to describe the cross-level jump relationship between multiple sub-levels; a publishing module 430 configured to, in response to a game map publishing instruction, control the generation of map instances corresponding to each sub-level, wherein each map instance is allocated a corresponding second identifier, the second identifier being used to locate the corresponding map instance during runtime; an establishment module 440 configured to, establish a mapping relationship between the first identifier and the second identifier; and a running module 450 configured to, when the game map is in a running state, parse the first identifier carried in the jump request into the corresponding second identifier according to the mapping relationship, and locate the corresponding map instance based on the determined second identifier.

[0271] The apparatus provided in this disclosure has the following technical effects: This allows for the complete design of multiple levels in the draft state by assigning a corresponding first identifier to each sub-level in the draft state and configuring cross-level jump relationships based on this first identifier. This eliminates the need for any sub-level to be pre-released during the creation phase, enabling the decoupling of logical creation from platform release and reducing the number of release re-fillings. Simultaneously, based on the mapping relationship between the first and second identifiers, the first identifier in the jump request is parsed at runtime to locate the corresponding map instance, ensuring accurate execution of cross-map instance jumps and improving the interactive experience. The draft state can fully configure the multi-level connection logic, enhancing the organizational flexibility and level association depth of multi-level content under the state synchronization architecture, thus increasing game richness. Furthermore, by establishing and maintaining the mapping relationship between the first and second identifiers, effective isolation between the draft state identifier system and the runtime identifier system is achieved, solving the computer science problem of process coupling and high iteration costs caused by the mixing of creation and runtime identifiers during game map editing.

[0272] The specific details of each part of the above-mentioned device have been described in detail in the method section of the implementation plan. For any undisclosed details, please refer to the implementation plan of the method section, and therefore will not be repeated here.

[0273] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to exemplary embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0274] Exemplary embodiments of this disclosure also provide a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the methods described above.

[0275] Implementing the above method steps using a computer program has the following technical effects: This allows for the complete design of multiple levels in the draft state by assigning a corresponding first identifier to each sub-level in the draft state and configuring cross-level jump relationships based on this first identifier. This eliminates the need for any sub-level to be pre-released during the creation phase, enabling the decoupling of logical creation from platform release and reducing the number of release re-fillings. Simultaneously, based on the mapping relationship between the first and second identifiers, the first identifier in the jump request is parsed at runtime to locate the corresponding map instance, ensuring accurate execution of cross-map instance jumps and improving the interactive experience. The draft state can fully configure the multi-level connection logic, enhancing the organizational flexibility and level association depth of multi-level content under the state synchronization architecture, thus increasing game richness. Furthermore, by establishing and maintaining the mapping relationship between the first and second identifiers, effective isolation between the draft state identifier system and the runtime identifier system is achieved, solving the computer science problem of process coupling and high iteration costs caused by the mixing of creation and runtime identifiers during game map editing.

[0276] In one implementation, the computer program product can be a tangible product, such as a computer-readable storage medium storing a computer program. The readable storage medium can be based on electrical, magnetic, optical, electromagnetic, infrared, or other signals, and includes, but is not limited to: random access memory (RAM), read-only memory (ROM), magnetic tape, floppy disk, flash memory, hard disk drive (HDD), solid-state drive (SSD), etc. For example, the computer program product can be a non-volatile storage medium storing a computer program, such as read-only memory, NAND flash memory, etc.

[0277] In one implementation, the computer program product can be an intangible product. For example, the computer program product can be a virtual digital product, such as an executable file or installation package containing a computer program.

[0278] Computer program code can be written in one or more programming languages. Examples of programming languages ​​include C, Java, and C++. Program code can execute entirely on the user's computing device, partially on the user's computing device, or as a standalone software package. It can also execute partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, such as a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via an internet connection provided by a mobile network operator).

[0279] Computer programs can be carried or transmitted via signals such as electrical, magnetic, optical, electromagnetic, and infrared rays. Electronic devices can convert signals carrying computer programs into digital signals, thereby running the computer programs. When a computer program runs on an electronic device, its code is used to cause the electronic device to execute (more specifically, to be executed by the processor of the electronic device) the method steps of various embodiments of this disclosure.

[0280] Exemplary embodiments of this disclosure also provide an electronic device, which may be the first client 110, the second client 120, or the server 130 described above. The electronic device includes a processor and a memory. The memory stores executable instructions for the processor, such as computer programs. The processor executes these executable instructions to perform the method steps of various exemplary embodiments of this disclosure.

[0281] Implementing the above method steps using electronic devices has the following technical advantages: This allows for the complete design of multiple levels in the draft state by assigning a corresponding first identifier to each sub-level in the draft state and configuring cross-level jump relationships based on this first identifier. This eliminates the need for any sub-level to be pre-released during the creation phase, enabling the decoupling of logical creation from platform release and reducing the number of release re-fillings. Simultaneously, based on the mapping relationship between the first and second identifiers, the first identifier in the jump request is parsed at runtime to locate the corresponding map instance, ensuring accurate execution of cross-map instance jumps and improving the interactive experience. The draft state can fully configure the multi-level connection logic, enhancing the organizational flexibility and level association depth of multi-level content under the state synchronization architecture, thus increasing game richness. Furthermore, by establishing and maintaining the mapping relationship between the first and second identifiers, effective isolation between the draft state identifier system and the runtime identifier system is achieved, solving the computer science problem of process coupling and high iteration costs caused by the mixing of creation and runtime identifiers during game map editing.

[0282] The following is for reference. Figure 5The electronic device is illustrated by way of a general-purpose computing device. It should be understood that... Figure 5 The electronic device 1100 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.

[0283] like Figure 5 As shown, the electronic device 1100 may include: a processor 1110, a memory 1120, a bus 1130, an I / O (input / output) interface 1140, and a network adapter 1150.

[0284] Memory 1120 may include volatile memory, such as RAM 1121 and cache unit 1122, and may also include non-volatile memory, such as ROM 1123. Memory 1120 may also include one or more program modules 1124, such program modules 1124 including, but not limited to: operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. For example, program module 1124 may include the modules in the above-described apparatus.

[0285] The processor 1110 may include one or more processing units, such as an AP (Application Processor), a modem processor, a GPU (Graphics Processing Unit), an ISP (Image Signal Processor), a controller, an encoder, a decoder, a DSP (Digital Signal Processor), a baseband processor, and / or an NPU (Neural-Network Processing Unit).

[0286] The processor 1110 can be used to execute executable instructions stored in the memory 1120 to perform method steps of various embodiments of the present disclosure.

[0287] Bus 1130 is used to connect different components of electronic device 1100 and may include a data bus, an address bus and a control bus.

[0288] Electronic device 1100 can communicate with one or more external devices 1200 (such as keyboard, mouse, external controller, etc.) through I / O interface 1140.

[0289] Electronic device 1100 can communicate with one or more networks via network adapter 1150. For example, network adapter 1150 can provide mobile communication solutions such as 3G / 4G / 5G, or wireless communication solutions such as wireless LAN, Bluetooth, and near-field communication. Network adapter 1150 can communicate with other modules of electronic device 1100 via bus 1130.

[0290] In one embodiment, the electronic device 1100 further includes a display for displaying a graphical user interface.

[0291] although Figure 5 As not shown in the diagram, other hardware and / or software modules may also be configured in the electronic device 1100, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID (Redundant Arrays of Independent Disks) systems, tape drives, and data backup storage systems.

[0292] As can be seen from the above, the technical solutions disclosed herein can be implemented as methods, apparatus, systems, computer program products, storage media, electronic devices, etc. Those skilled in the art will understand that various aspects of this disclosure can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or an implementation combining hardware and software aspects, which may be referred to as "circuit," "module," or "system," respectively.

[0293] It should be understood that this disclosure is not limited to the specific methods, steps, or structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. Those skilled in the art will readily conceive of other embodiments based on the specific implementations provided in this disclosure. Therefore, the specific implementations provided in this disclosure are merely exemplary, and the scope and spirit of this disclosure are indicated by the claims, and should cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary technical means in the art not disclosed in this disclosure.

Claims

1. A method for editing a game map, characterized in that, The method includes: When the game map is in a draft state, the control assigns a corresponding first identifier to each of the multiple sub-levels included in the game map; In response to the association configuration instruction, association configuration information is determined, wherein the association configuration information is configured based on the first identifier and is used to describe the cross-level jump relationship between the multiple sub-levels; In response to the game map release command, control the generation of map instances corresponding to each of the sub-levels, wherein each of the map instances is assigned a corresponding second identifier, which is used to locate the corresponding map instance at runtime; Establish a mapping relationship between the first identifier and the second identifier; When the game map is in running state, the first identifier carried in the jump request is parsed into the corresponding second identifier according to the mapping relationship, and the corresponding map instance is located according to the determined second identifier.

2. The method according to claim 1, characterized in that, The step of determining the association configuration information in response to the association configuration instruction includes: The control determines the jump logic script, wherein the jump logic script is used to describe the jump relationship across sub-levels; In response to a configuration instruction, the first identifier is configured in the jump logic script so that the jump logic script directly references the first identifier.

3. The method according to claim 3, characterized in that, The jump logic script is configured to the complete state of cross-sub-level jump relationships when the game map is in draft state, wherein the configuration is not contingent on the release of any sub-level.

4. The method according to claim 1, characterized in that, The step of establishing the mapping relationship between the first identifier and the second identifier includes: During the release process, a mapping relationship is established between the first identifier of each sub-level and the second identifier assigned to the corresponding map instance; When updating and publishing a sub-level, the mapping relationship between the first identifier and the second identifier of the published sub-level before the update and publication is maintained.

5. The method according to claim 1, characterized in that, The method further includes: During the release process, the first identifier in the association configuration information is maintained, and the replacement of the first identifier with the second identifier is prohibited.

6. The method according to claim 1, characterized in that, After locating the corresponding map instance based on the parsed second identifier, the method further includes: The target virtual character in the game map is transferred from the current map instance to the map instance corresponding to the second identifier; wherein, the running state of each map instance is independent of each other, and each map instance supports the virtual character to enter the map instance determined based on the second identifier from the current map instance; or, each map instance supports the object to exit from the current map instance midway.

7. The method according to claim 1, characterized in that, The step of assigning corresponding first identifiers to the multiple sub-levels included in the game map when the game map is in a draft state includes: When the game map is in a draft state, in response to a level creation command, control the creation of sub-levels and assign the first identifier to the sub-levels; Control the display of the first identifier.

8. The method according to claim 1, characterized in that, The step of controlling the generation of map instances corresponding to each sub-level in response to the game map release command includes: In response to the game map release command, control the uploading of the overall data of the game map, wherein the overall data includes the level content data of each sub-level and the association configuration information, and the first identifier in the association configuration information remains unchanged; Create a map instance corresponding to each sub-level based on the level content data of each sub-level and / or the association configuration information.

9. The method according to claim 1, characterized in that, During runtime, the process of resolving the first identifier carried in the redirection request into the corresponding second identifier according to the mapping relationship includes: Upon receiving the redirection request, query the mapping relationship to obtain the currently effective second identifier; The corresponding map instance is located based on the second identifier.

10. The method according to claim 1, characterized in that, After locating the corresponding map instance based on the parsed second identifier, the method further includes: Synchronize the state of the object from the current map instance to the target map instance; wherein, the state synchronization includes at least one of the object's position state and attribute state.

11. A computer program product storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1 to 10.

Images