A method and device for hot updating game configuration table data

Abstract

The present application relates to the field of game development technology, and discloses a method and device for hot updating of game configuration table data, comprising: during the operation of multiple game services, monitoring whether the key value of the distributed key-value storage database etcd has changed; if so, initiating a change event to the multiple game services, the change event including the latest version number of the key value in etcd and the latest configuration table data; if the latest version number is greater than the current version number of the key value in the currently loaded etcd, determining the latest index type related to the game service corresponding to the latest configuration table data in the Java field manager, and determining the specific configuration field corresponding to the latest index type; creating a corresponding latest configuration index instance for the latest index type; loading the latest configuration table data into the latest configuration index instance, and replacing the latest configuration index instance with the specific configuration field, so that the game service can implement hot update of the corresponding game configuration by using the specific configuration field.

Description

Technical Field

[0001] This specification relates to the field of game development technology, and in particular to a method and device for hot updating game configuration table data. Background Art

[0002] In modern online game development, game function configuration parameters are typically edited and maintained by planners using Excel spreadsheets. This has been a fundamental workflow used in the gaming industry for over a decade. With the evolution of technological architecture, mainstream game projects no longer directly load native Excel files, but instead use format conversion mechanisms to convert them into structured data.

[0003] Precompiling Excel configuration spreadsheets into code files in a strongly typed language (such as Java) has a significant drawback: every configuration update requires recompiling the server-side program and restarting the server. For online players, server restarts can lead to serious user experience issues, such as game interruptions and data rollbacks. To minimize the impact, operators often perform updates in the early morning hours. This not only disrupts the work schedule of operations and maintenance personnel (long-term nighttime work poses health risks) but also reduces work efficiency the following day, creating a vicious cycle. Summary of the Invention

[0004] One or more embodiments of this specification provide a method and device for hot updating of game configuration table data, which are used to solve the technical problems raised by the background technology.

[0005] One or more embodiments of this specification adopt the following technical solutions:

[0006] One or more embodiments of this specification provide a method for hot updating game configuration table data, the method comprising:

[0007] During the operation of multiple game services, monitor whether the key values ​​of the distributed key-value storage database etcd have changed;

[0008] If so, a change event is initiated to the plurality of game services, wherein the change event includes the latest version number of the key value in etcd and the latest configuration table data;

[0009] If the latest version number is greater than the current version number of the key value in the currently loaded etcd, then determine the latest index type related to the game service corresponding to the latest configuration table data in the Java field manager, and determine the specific configuration field corresponding to the latest index type;

[0010] Creating a corresponding latest configuration index instance for the latest index type;

[0011] The latest configuration table data is loaded into the latest configuration index instance, and the latest configuration index instance is replaced with the specific configuration field, so that the game service implements a hot update of the corresponding game configuration by using the specific configuration field.

[0012] It should be noted that, when a version number update is detected, the present invention uses the Java field manager to parse the index type and specific configuration field corresponding to the configuration table, and realizes type-safe loading in the Java language environment by dynamically creating a configuration index instance and replacing the original field object.

[0013] Furthermore, the method further comprises:

[0014] When the plurality of game services are started for the first time, corresponding configuration table data is obtained in the etcd through a preset key value;

[0015] Automatically scan the configuration fields in the Java field manager through a reflection mechanism to determine the index type of the configuration table data corresponding to the configuration fields;

[0016] Create a corresponding configuration index instance for the index type;

[0017] The configuration table data is loaded into the latest configuration index instance, and the latest configuration index instance is replaced with the relevant configuration field, so that the plurality of game services can start corresponding game configurations by using the relevant configuration fields.

[0018] It should be noted that the present invention builds a closed loop of configuration management for the entire life cycle by introducing an automated configuration loading process based on a reflection mechanism during the service startup phase: when the game service is started for the first time, the system automatically obtains the configuration table data corresponding to the key value from etcd, uses reflection technology to scan the configuration fields in the Java field manager and dynamically parses its index type, and then creates a matching configuration index instance to complete data loading and field replacement. This process converts the configuration field binding operations that require manual maintenance in traditional solutions into automated runtime behaviors, so that multiple service nodes do not need to predefine configuration loading logic or manually adjust code when starting, eliminating the risk of field type mismatches caused by manual coding omissions and ensuring that the initial configuration states of all service instances in a distributed environment are strictly consistent; at the same time, the initialization mechanism shares the same set of type parsing and instance replacement logic with the runtime hot update process, forming a unified architecture for configuration loading and updating, fundamentally avoiding the data state conflicts caused by the separation of initialization static loading and dynamic update logic in traditional solutions, and significantly improving system robustness and operation and maintenance efficiency.

[0019] Furthermore, after loading the configuration table data into the latest configuration index instance, the method further includes:

[0020] Record the version number of the key value in etcd to track the configuration table data update.

[0021] It should be noted that this technical solution establishes a closed-loop verification mechanism for version number tracking, and synchronously records the current version number of the etcd key value after the configuration is loaded, so that all game service nodes in the distributed system form a globally consistent reference benchmark for the update status of the configuration data. This design uses the version number as the only trusted traceability identifier for configuration data changes. In the subsequent hot update process, the version number comparison can accurately determine whether each node needs to perform an update operation, completely avoiding the risks of incorrect updates and missed updates caused by timestamp drift, file hash calculation errors, or manual marking omissions in traditional solutions; at the same time, the atomicity and real-time nature of the version number record ensure strong consistency of the configuration status between multiple nodes. Even in abnormal scenarios such as network fluctuations, the system can still quickly restore synchronization based on the persistently stored version number, thereby achieving accurate convergence and self-healing of the configuration status of the entire cluster without business perception.

[0022] Furthermore, before initiating the change event to the plurality of game services, the method further includes:

[0023] Receive the latest Excel files edited by update personnel;

[0024] Convert the latest Excel file into a protobuf byte array, and store the protobuf byte array into a byte[] file;

[0025] Upload the byte[] file to the etcd to obtain the latest configuration table data used by the game service for hot updating game configuration.

[0026] This technical solution establishes a standardized configuration data preprocessing pipeline, converting Excel files edited by planners into highly compatible byte streams via protobuf serialization and persisting them to etcd. This ensures both type safety and efficient transmission at the data source. Protobuf's strong contractual nature ensures a strict mapping between Excel data structures and Java server fields, eliminating parsing errors caused by loose type matching when converting between traditional text formats such as JSON / XML. Furthermore, the byte stream storage format not only reduces etcd's read and write overhead, but also provides a unified data interface for multi-language microservice architectures through the cross-platform support of protocol buffers. This preprocessing mechanism, deeply integrated with the distributed key-value store, allows planners to simply maintain Excel files according to predefined rules, automatically triggering subsequent hot updates. This streamlines the previously manual configuration release, format verification, and version management processes into a standardized, streamlined process. This eliminates online failures caused by human error and reduces the time required to implement a configuration change to online compliance to minutes. This improves development and maintenance collaboration efficiency while providing solid technical support for dynamic game tuning.

[0027] Furthermore, the key value includes a configuration file name, and loading the latest configuration table data into the latest configuration index instance includes:

[0028] Acquire the name of the latest configuration file in the latest configuration table data by calling the preset method of the latest configuration index instance;

[0029] The latest configuration file name is loaded into the latest configuration index instance.

[0030] It should be noted that this technical solution builds a strong verification link between configuration identifiers and data entities by embedding the configuration file name into the key-value system and deeply binding it to the loading logic of the index instance: when loading the latest configuration table data, the system automatically extracts the latest configuration file name contained in it through the configuration index instance, and synchronously injects the name into the latest configuration index instance. This design makes the configuration name no longer dependent on manually maintained string constants or external mapping tables, but is dynamically verified as a native attribute of the configuration data, fundamentally eliminating the logical anomalies caused by spelling errors in the configuration name, historical version residues, or cross-table reference mismatches in traditional solutions; at the same time, the strict correspondence between the configuration name and the key-value storage path ensures that any configuration update operation can be accurately routed to the target Java object, avoiding the performance loss caused by full scanning or fuzzy matching, thereby providing high-reliability hot update support for large-scale, multi-configuration table game systems while ensuring the accuracy of configuration loading.

[0031] Furthermore, the key value also includes a preset group name identifier, and the method further includes:

[0032] The game services corresponding to the key values ​​are determined based on the group name identifier, so that the game services can determine the corresponding key values ​​when implementing hot updates of the corresponding game configurations.

[0033] It should be noted that this technical solution deeply couples distributed configuration management with service grouping topology by introducing a logical layering dimension, group name identifiers, into the key-value system. During hot updates, the system dynamically associates key values ​​with target game service groups based on group name identifiers, enabling precise isolation and targeted push of configuration updates for different functional modules (such as the combat system and social system) or business partitions (such as the telecommunications zone and network communication zone) within the same physical cluster. This design breaks away from the crude model of traditional global broadcast updates by limiting the impact of configuration changes to the pre-set service group boundaries. This not only avoids unnecessary resource consumption by irrelevant service nodes due to receiving redundant data, but also prevents systemic risks caused by cross-module configuration contamination due to misoperation. Furthermore, the explicit declaration mechanism of group name identifiers enables operations and maintenance personnel to manage configuration based on business semantics rather than physical addresses. As service instances dynamically scale up and down, they automatically inherit group attributes, achieving seamless adaptation of configuration policies and infrastructure elasticity, significantly improving the operational controllability and fault isolation efficiency of large-scale distributed game architectures.

[0034] Furthermore, the method further comprises:

[0035] In the hot updates of the game configurations corresponding to the plurality of game services, determining the hot update type of each game configuration;

[0036] triggering a hot update of multiple game configurations simultaneously during the running of multiple game services for a specified user, and determining a game running scenario and a hot update type of the multiple game configurations;

[0037] Based on the game running scenario and the hot update types of the multiple game configurations, an update strategy for the hot update of the multiple game configurations is determined, so that the game service implements the hot update of the multiple game configurations based on the update strategy.

[0038] It should be noted that this technical solution transforms previously unordered concurrent update requests into a logically self-consistent scheduling sequence: when multiple configurations need to be hot-updated simultaneously, the system first analyzes the update type of each configuration (such as combat value corrections, activity rule changes, combat scene skill special effect configurations, character equipment appearance configurations, etc.), synchronously captures the current game scene (such as the player is in a dungeon battle or socializing in the main city), and then dynamically generates an update strategy (such as immediate effect, delayed loading, or batch execution) based on the correlation between the type and the scene. This mechanism allows key updates such as core combat parameters to take effect silently when the player is in a non-combat scenario, while interface updates dynamically select an execution window based on the scene load. This not only avoids service lag caused by resource competition in the traditional full update mode, but also eliminates temporary data inconsistencies caused by cross-configuration logical coupling. Ultimately, multi-configuration hot updates achieve zero-perceived intrusion on the game process, ensuring business continuity while maintaining the integrity of the player's immersive experience.

[0039] Furthermore, the hot update type of the game configuration includes battle scene skill special effect configuration and character equipment appearance configuration; the game running scene includes battle scene and non-battle scene;

[0040] The step of determining an update strategy for the hot update of the plurality of game configurations based on the game running scenario and the hot update type of the plurality of game configurations includes:

[0041] If the game running scene is a battle scene, hot update the appearance configuration of the character equipment to reduce the running resources of the battle scene skill special effects, and hot update the battle scene skill special effects configuration in the non-combat scene;

[0042] If the game running scene is a non-combat scene, the character equipment appearance configuration and the combat scene skill special effect configuration are simultaneously subjected to hot update processing.

[0043] It should be noted that this technical solution deeply couples hot update operations with players' real-time experience needs by establishing a scene-sensitive update strategy layering mechanism: in combat scenes, priority is given to appearance configuration updates with low resource consumption, and skill special effects updates with high computing loads are temporarily suspended. In non-combat scenes, a full update window is opened, allowing the system to intelligently allocate resources based on the player's situation, avoiding frame rate fluctuations or operation delays caused by overloading of special effects resources at critical moments of combat, and utilizing the low-pressure environment of the non-combat stage to efficiently complete full configuration synchronization. This allows for a dynamic balance between hot update operations and real-time game resource usage while maintaining the continuity of the player's immersive experience, ultimately achieving dual optimization of business demand response and user experience assurance.

[0044] Furthermore, if the non-combat scene is an item extraction process, the method further includes:

[0045] The character equipment appearance configuration and the battle scene skill special effect configuration are simultaneously subjected to hot update processing, and a hidden reward sending special effect is triggered during the item extraction process to replace the game delay caused by the hot update processing.

[0046] It should be noted that this technical solution deeply integrates hot update operations with the game's positive feedback mechanism. At specific interactive nodes in non-combat scenarios (such as item extraction), the system simultaneously executes multi-configuration hot updates and triggers hidden reward effects, allowing players to perceptually transform brief update delays into surprising experiences. While players focus on the joyful anticipation of reward acquisition, the background hot update resource loading process is cleverly transformed into a visual effect presentation vehicle. This not only utilizes the natural shift in players' psychological attention to achieve a seamless update, but also compensates for potential experience gaps caused by technical operations through the immediate delivery of hidden rewards. This ensures the timeliness of hot updates while transforming original technical limitations into emotional touchpoints that enhance user retention and activity, achieving a positive cycle of enhanced technical operations and player experience.

[0047] One or more embodiments of this specification provide a device for hot updating game configuration table data, including:

[0048] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to:

[0049] During the operation of multiple game services, monitor whether the key value of the distributed key-value storage database etcd has changed; if so, initiate a change event to the multiple game services, and the change event includes the latest version number of the key value in the etcd and the latest configuration table data; if the latest version number is greater than the current version number of the key value in the currently loaded etcd, determine the latest index type related to the game service corresponding to the latest configuration table data in the Java field manager, and determine the specific configuration field corresponding to the latest index type; create a corresponding latest configuration index instance for the latest index type; load the latest configuration table data into the latest configuration index instance, and replace the latest configuration index instance with the specific configuration field, so that the game service can achieve hot update of the corresponding game configuration by using the specific configuration field.

[0050] At least one of the above technical solutions adopted in the embodiments of this specification can achieve the following beneficial effects:

[0051] When a version number update is detected, the present invention uses a Java field manager to parse the index type and specific configuration field corresponding to the configuration table, and realizes type-safe loading in the Java language environment by dynamically creating a configuration index instance and replacing the original field object. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for the embodiments or the description of the prior art. Obviously, the drawings described below are only some of the embodiments described in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without inventive work. In the drawings:

[0053] Figure 1 This is an application environment diagram of a method for hot updating game configuration table data provided by one or more embodiments of this specification;

[0054] Figure 2 A flowchart of a method for hot updating configuration table data of a game provided in one or more embodiments of this specification;

[0055] Figure 3 A flowchart of the first startup of a game service provided in one or more embodiments of this specification;

[0056] Figure 4 A schematic diagram of the process of uploading an Excel file to etcd provided in one or more embodiments of this specification;

[0057] Figure 5 Data flow diagrams provided by embodiments of this specification for one or more embodiments of this specification;

[0058] Figure 6 A schematic diagram of pulling configurations from etcd for the gaming service provided in one or more embodiments of this specification;

[0059] Figure 7 A schematic diagram of a configuration table data update notification provided for one or more embodiments of this specification;

[0060] Figure 8 A schematic diagram of the structure of a device for hot updating configuration table data of a game provided in one or more embodiments of this specification;

[0061] Figure 9 This is a schematic diagram of the structure of a game configuration table data hot update device provided in one or more embodiments of this specification. DETAILED DESCRIPTION

[0062] The embodiments of this specification provide a method and device for hot updating configuration table data of a game.

[0063] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this specification without creative work should fall within the scope of protection of this specification.

[0064] In modern online game development, game function configuration parameters are typically edited and maintained by planners using Excel spreadsheets. This has been a fundamental workflow used in the gaming industry for over a decade. With the evolution of technological architecture, mainstream game projects no longer directly load native Excel files, but instead use format conversion mechanisms to convert them into structured data.

[0065] Precompiling Excel configuration spreadsheets into code files in a strongly typed language (such as Java) has a significant drawback: every configuration update requires recompiling the server-side program and restarting the server. For online players, server restarts can lead to serious user experience issues, such as game interruptions and data rollbacks. To minimize the impact, operators often perform updates in the early morning hours. This not only disrupts the work schedule of operations and maintenance personnel (long-term nighttime work poses health risks) but also reduces work efficiency the following day, creating a vicious cycle.

[0066] The solution of the present application can be applied in the scenario of hot updating of configuration table data of a game terminal. Figure 1 FIG. 1 shows an application environment diagram of a method for hot updating configuration table data of a game provided by an embodiment of the present application, such as Figure 1As shown, the terminal 102 communicates with the server 103 via the network. The data storage system 101 can store data that the server 103 needs to process. The data storage system 101 can be integrated on the server 103, or placed on the cloud or other network servers. The terminal 102 can obtain the user's historical behavior data in different operation scenarios and the operating status of the MR device; extract the user's common behavior information from the user's historical behavior data in each operation scenario; extract the MR device's state common information from the MR device's operating status in each operation scenario; combine the behavior common information and the state common information to generate the device habit state of the MR device in the operation scenario; associate the operation scenario with the device habit state to obtain a behavior habit label. Alternatively, the above-mentioned label construction process is placed in the server 103 for execution, that is, the server obtains the user's historical behavior data in different operation scenarios and the operating status of the MR device; extracts the user's common behavior information from the user's historical behavior data in each operation scenario; extracts the common status information of the MR device from the operating status of the MR device in each operation scenario; combines the common behavior information and the common status information to generate the device habit status of the MR device in the operation scenario; associates the operation scenario with the device habit status to obtain a behavior habit label.

[0067] Specifically, gaming terminals may include smartphones, smart home appliances, tablets, virtual reality headsets (VR headsets), augmented reality glasses (AR glasses), electronic display screens, and mixed reality (MR) devices. MR devices may include MR glasses, MR helmets, and MR cameras. In-vehicle systems may include in-vehicle chipsets, in-vehicle devices (such as vehicle computers, in-vehicle computers, and sensors with voice recognition capabilities).

[0068] Figure 2 This is a flowchart of a method for hot updating game configuration table data provided by one or more embodiments of this specification. This process can be executed by a game configuration table data hot update system. Certain input parameters or intermediate results in the process can be manually adjusted to help improve accuracy.

[0069] The method steps of the embodiment of this specification are as follows:

[0070] S201, during the operation of multiple game services, monitor whether the key value of the distributed key-value storage database etcd changes.

[0071] In the embodiment of this specification, when the game service is started, the distributed key-value storage database etcd is deployed, and the monitoring rules of the key values ​​in the configuration table data in etcd are defined. For example, the monitoring rules are based on the change events of the corresponding filename suffix in the key value / config / {group} / filename.

[0072] S202: If yes, initiate a change event to the plurality of game services, wherein the change event includes the latest version number of the key value in etcd and the latest configuration table data.

[0073] In this embodiment of the present specification, based on the / config / {group} / filename key structure defined in S201, when a key value change is detected, a hierarchical topic publish-subscribe model can be used to push the change event only to multiple game services. The change event can include the global latest version number of the key value generated by etcd and the latest configuration table data (which can be binary configuration data serialized in Protobuf). If not, the process returns to S201.

[0074] S203: If the latest version number is greater than the current version number of the key value in the currently loaded etcd, determine the latest index type related to the game service corresponding to the latest configuration table data in the Java field manager, and determine the specific configuration field corresponding to the latest index type.

[0075] In the examples of this specification, the following specific implementation schemes can be used:

[0076] Dynamic binding of index type: Each configuration file name (such as item.bytes) must correspond to a Java class (such as ItemIndex) that implements the IConfigIndex interface. This interface defines the load(protoData) method for loading Protobuf into memory.

[0077] The ConfigManager maintains a file-index type mapping table. When the service starts, it scans all classes that implement IConfigIndex. The IConfigIndex interface defines a String configFileName() method to represent the file name of the current index type. When an S202 event carries a file name (such as item.bytes), the corresponding ItemIndex class is retrieved from the mapping table.

[0078] S204: Create a corresponding latest configuration index instance for the latest index type.

[0079] In the examples of this specification, the following specific implementation schemes can be used:

[0080] Dynamic instance creation: Through the Java reflection mechanism, call the no-argument constructor of the index class (such as ItemIndex) to create a new instance.

[0081] Call the load(protoData) method: input the Protobuf object in the S202 event to generate a complete configuration object (such as all prop attribute data after ItemIndex is instantiated).

[0082] Dependency pre-verification: Check the integrity of the new instance: for example, verify whether the required fields in ItemIndex (such as prop ID and name) are not empty. If the verification fails, terminate the process and issue an alarm.

[0083] S205: Load the latest configuration table data into the latest configuration index instance, and replace the latest configuration index instance with the specific configuration field, so that the game service implements hot update of the corresponding game configuration by using the specific configuration field.

[0084] In the examples of this specification, the following specific implementation schemes can be used:

[0085] Resource recovery and notification: After the old instance is dereferenced, the JVM garbage collection mechanism automatically releases the memory.

[0086] Trigger callback notification: notify related modules (such as cache system, combat logic) through event bus (such as EventBus) to reload dependent configurations to ensure global state consistency.

[0087] It should be noted that, when a version number update is detected, the present invention uses the Java field manager to parse the index type and specific configuration field corresponding to the configuration table, and realizes type-safe loading in the Java language environment by dynamically creating a configuration index instance and replacing the original field object.

[0088] Furthermore, if multiple game services are started for the first time, see Figure 3 A flowchart showing the first startup of a game service is shown.

[0089] S301, obtain corresponding configuration table data through pre-set key values ​​in the etcd.

[0090] S302: Automatically scan the configuration fields in the Java field manager through a reflection mechanism to determine the index type of the configuration table data corresponding to the configuration fields.

[0091] S303: Create a corresponding configuration index instance for the index type.

[0092] S304: Load the configuration table data into the latest configuration index instance, and replace the latest configuration index instance with the relevant configuration field, so that the plurality of game services can start corresponding game configurations by using the relevant configuration fields.

[0093] In the embodiments of this specification, for the first start of the above-mentioned game service, the following specific implementation scheme can be adopted:

[0094] 1. Initialize configuration pull

[0095] Predefined key-value path rules: When the service starts, a single query request is sent to etcd based on the preset / config / {group} / filename key structure (such as / config / {group} / Item.bytes) to pull the Protobuf binary data of all currently active configuration files.

[0096] {group} is the server group. For example, the example corresponding to prod_3.5.12 is:

[0097] / config / prod_3.5.12 / Item.bytes, / config / prod_3.5.12 / Skill.bytes.

[0098] 2. Automated index type discovery and mapping

[0099] Interface constraints and class scanning: All index types (such as ItemIndex) must implement the unified interface IConfigIndex, which defines the load (protoData) method for data loading. When the service starts, it uses reflection to scan the ConfigManager package path, identify all classes implementing this interface, and create a mapping table from filename to index class (for example, Item.bytes corresponds to ItemIndex.class).

[0100] Field-configuration association binding: Declare a field for each index type in ConfigManager (such as publicItemIndex ITEM).

[0101] 3. Dynamic Instantiation and Data Loading Pipeline

[0102] Reflection instance creation: According to the mapping table, call the no-argument constructor for the index class (such as ItemIndex) corresponding to each configuration file to create an empty instance.

[0103] Protobuf data deserialization: Call the parseFrom(byte[] data) method of the Java class generated by Protobuf (such as ItemProto) to convert the binary data pulled by etcd into a memory object.

[0104] Index instance initialization: Take the Protobuf object as a parameter and call the load (protoData) method of the index instance to complete business customization processing (such as building an in-memory index and cache optimization). If initialization fails, the fallback mechanism is triggered, retaining the default configuration and issuing an alarm.

[0105] 4. Atomic Field Injection and State Synchronization

[0106] Thread-safe field replacement: Use the Java reflection API (such as Field.set()) to inject the initialized index instance into the ConfigManager field (such as ITEM). Use AtomicReference or double-checked locking to ensure the atomicity of the replacement in a multi-threaded environment and avoid dirty reads.

[0107] It should be noted that the present invention builds a closed loop of configuration management for the entire life cycle by introducing an automated configuration loading process based on a reflection mechanism during the service startup phase: when the game service is started for the first time, the system automatically obtains the configuration table data corresponding to the key value from etcd, uses reflection technology to scan the configuration fields in the Java field manager and dynamically parses its index type, and then creates a matching configuration index instance to complete data loading and field replacement. This process converts the configuration field binding operations that require manual maintenance in traditional solutions into automated runtime behaviors, so that multiple service nodes do not need to predefine configuration loading logic or manually adjust code when starting, eliminating the risk of field type mismatches caused by manual coding omissions and ensuring that the initial configuration states of all service instances in a distributed environment are strictly consistent; at the same time, the initialization mechanism shares the same set of type parsing and instance replacement logic with the runtime hot update process, forming a unified architecture for configuration loading and updating, fundamentally avoiding the data state conflicts caused by the separation of initialization static loading and dynamic update logic in traditional solutions, and significantly improving system robustness and operation and maintenance efficiency.

[0108] Furthermore, after the configuration table data is loaded into the latest configuration index instance, the version number of the key value in etcd is recorded to track the update of the configuration table data.

[0109] In the examples of this specification, the following specific implementation schemes can be used:

[0110] 1. Cluster state synchronization

[0111] etcd status tree write: After recording the version number locally, write the service instance's unique identifier (such as the IP address) and version number to the / status / {service_id} / versions path of etcd to form a cluster-level version snapshot.

[0112] It should be noted that this technical solution establishes a closed-loop verification mechanism for version number tracking, and synchronously records the current version number of the etcd key value after the configuration is loaded, so that all game service nodes in the distributed system form a globally consistent reference benchmark for the update status of the configuration data. This design uses the version number as the only trusted traceability identifier for configuration data changes. In the subsequent hot update process, the version number comparison can accurately determine whether each node needs to perform an update operation, completely avoiding the risks of incorrect updates and missed updates caused by timestamp drift, file hash calculation errors, or manual marking omissions in traditional solutions; at the same time, the atomicity and real-time nature of the version number record ensure strong consistency of the configuration status between multiple nodes. Even in abnormal scenarios such as network fluctuations, the system can still quickly restore synchronization based on the persistently stored version number, thereby achieving accurate convergence and self-healing of the configuration status of the entire cluster without business perception.

[0113] Furthermore, before initiating a change event to the multiple game services, the latest Excel file edited by the update personnel is received. The update personnel can be game developers such as planners and operations personnel; the latest Excel file is converted into a protobuf byte array, and the protobuf byte array is stored in a byte[] file; the byte[] file is uploaded to the etcd to obtain the latest configuration table data used by the game service for hot updating game configuration.

[0114] In the examples of this specification, see Figure 4The following diagram illustrates the process of uploading an Excel file to etcd. Planners can edit the Excel file to implement their desired functional values. They then submit the Excel file to SVN (Subversion). Developers then pull the latest Excel file from SVN. They can use the JavaExcelTools conversion tool to convert the Excel data into a protobuf byte array and then save the protobuf byte array to a file, resulting in a byte[] file. The etcdctl command can be used to upload byte[] files to etcd. Alternatively, shell scripts can be written to perform batch uploads. When operations personnel edit activity data in the admin dashboard, Excel files are also generated. Planners can also use the admin dashboard to upload Excel files. Within the admin dashboard, Excel files are continuously converted into byte[] files and uploaded to etcd.

[0115] This technical solution establishes a standardized configuration data preprocessing pipeline, converting Excel files edited by planners into highly compatible byte streams via protobuf serialization and persisting them to etcd. This ensures both type safety and efficient transmission at the data source. Protobuf's strong contractual nature ensures a strict mapping between Excel data structures and Java server fields, eliminating parsing errors caused by loose type matching when converting between traditional text formats such as JSON / XML. Furthermore, the byte stream storage format not only reduces etcd's read and write overhead, but also provides a unified data interface for multi-language microservice architectures through the cross-platform support of protocol buffers. This preprocessing mechanism, deeply integrated with the distributed key-value store, allows planners to simply maintain Excel files according to predefined rules, automatically triggering subsequent hot updates. This streamlines the previously manual configuration release, format verification, and version management processes into a standardized, streamlined process. This eliminates online failures caused by human error and reduces the time required to implement a configuration change to online compliance to minutes. This improves development and maintenance collaboration efficiency while providing solid technical support for dynamic game tuning.

[0116] Furthermore, the key value includes a configuration file name. When the latest configuration table data is loaded into the latest configuration index instance, the latest configuration file name in the latest configuration table data can be obtained by calling a preset method of the latest configuration index instance. The latest configuration index instance can be ConfigItemIndex, and the preset method can be the configFileName() method; the latest configuration file name is loaded into the latest configuration index instance. For example, the latest configuration file name can be ItemTable.bytes.

[0117] In the examples of this specification, the following specific implementation schemes can be used:

[0118] 1. Interface standardization and file name declaration binding

[0119] Unified interface definition: Define the configFileName() abstract method in the Java index interface (IConfigIndex), forcing all subclasses to implement this method to return the bound file name (such as ItemTable.bytes).

[0120] 2. File name dynamic injection process

[0121] Key-value path parsing: Extract the filename field (i.e., ItemTable.bytes) from the key path monitored by etcd (such as / config / {group} / ItemTable.bytes) as the benchmark value for subsequent verification.

[0122] Verification after instantiation: After creating an index instance (such as ConfigItemIndex), immediately call its configFileName() method to obtain the return value.

[0123] Compare the return value with the filename in the key path. If they match, continue loading. Otherwise, throw FileNameMismatchException, terminate the process, and issue an alert.

[0124] 3. Filename metadata persistence

[0125] Object status record: A fileName attribute is built into the index instance. During initialization, ItemTable.bytes is injected into this attribute so that business logic can directly access the file name through the instance (such as log printing and monitoring reporting).

[0126] It should be noted that this technical solution builds a strong verification link between configuration identifiers and data entities by embedding the configuration file name into the key-value system and deeply binding it to the loading logic of the index instance: when loading the latest configuration table data, the system automatically extracts the latest configuration file name contained in it through the configuration index instance, and synchronously injects the name into the latest configuration index instance. This design makes the configuration name no longer dependent on manually maintained string constants or external mapping tables, but is dynamically verified as a native attribute of the configuration data, fundamentally eliminating the logical anomalies caused by spelling errors in the configuration name, historical version residues, or cross-table reference mismatches in traditional solutions; at the same time, the strict correspondence between the configuration name and the key-value storage path ensures that any configuration update operation can be accurately routed to the target Java object, avoiding the performance loss caused by full scanning or fuzzy matching, thereby providing high-reliability hot update support for large-scale, multi-configuration table game systems while ensuring the accuracy of configuration loading.

[0127] Furthermore, the key value also includes a preset group name identifier, and the game service corresponding to each key value is determined based on the group name identifier, so that the game service can determine the corresponding key value when implementing a hot update of the corresponding game configuration.

[0128] In the embodiments of this specification, {group} is a server group. For example, the example corresponding to prod_3.5.12 is:

[0129] / config / prod_3.5.12 / Item.bytes, / config / prod_3.5.12 / Skill.bytes.

[0130] It should be noted that this technical solution deeply couples distributed configuration management with service grouping topology by introducing a logical layering dimension, group name identifiers, into the key-value system. During hot updates, the system dynamically associates key values ​​with target game service groups based on group name identifiers, enabling precise isolation and targeted push of configuration updates for different functional modules (such as the combat system and social system) or business partitions (such as the telecommunications zone and network communication zone) within the same physical cluster. This design breaks away from the crude model of traditional global broadcast updates by limiting the impact of configuration changes to the pre-set service group boundaries. This not only avoids unnecessary resource consumption by irrelevant service nodes due to receiving redundant data, but also prevents systemic risks caused by cross-module configuration contamination due to misoperation. Furthermore, the explicit declaration mechanism of group name identifiers enables operations and maintenance personnel to manage configuration based on business semantics rather than physical addresses. As service instances dynamically scale up and down, they automatically inherit group attributes, achieving seamless adaptation of configuration policies and infrastructure elasticity, significantly improving the operational controllability and fault isolation efficiency of large-scale distributed game architectures.

[0131] Furthermore, the embodiments of this specification determine the hot update type of each game configuration during the hot update of the corresponding game configurations of multiple game services; simultaneously trigger the hot update of multiple game configurations during the operation of multiple game services for a specified user, and determine the game operation scenario and the hot update type of the multiple game configurations; based on the game operation scenario and the hot update type of the multiple game configurations, determine the update strategy for the hot update of the multiple game configurations, so that the game service can implement the hot update of the multiple game configurations based on the update strategy.

[0132] In the examples of this specification, the following specific implementation schemes can be used:

[0133] 1. Classification and identification of hot update types

[0134] Type definition standardization:

[0135] Core business type: Configurations that directly affect the player's core experience (such as combat values ​​and economic rules) must be enforced immediately.

[0136] Resource-dependent: Configurations involving large amounts of memory or computing resources (such as special effects resources and scene models) need to be loaded in stages.

[0137] Non-critical: Configurations with low real-time requirements (such as interface text and activity descriptions) allow for delayed or batch updates.

[0138] Metadata tagging: Add an update_type field (such as critical, resource, low_priority) to the configuration file, or implicitly identify it through file name rules (such as battle_*.bytes is classified as core business type by default).

[0139] 2. Dynamic recognition of game scenes

[0140] Scene Perception Engine:

[0141] Player behavior analysis: Real-time collection of player status (such as in battle, trading, in the main city), operation frequency, and current task progress.

[0142] Service health monitoring: Node load levels are determined through indicators (CPU usage, memory usage, and request latency), and are classified into high, medium, and low load states.

[0143] Scenario labeling: Convert dynamic data into scenario labels (such as high_load_battle and idle_social) as the basis for strategic decision-making.

[0144] 3. Dynamic Strategy Decision-Making and Distribution

[0145] Policy rule base:

[0146] Core business type: takes effect immediately in any scenario, but limits the number of concurrent threads under high load (such as single-threaded serial updates).

[0147] Resource-dependent: Full loading is triggered only in low-load scenarios (idle tags), and only necessary resources (such as basic models) are loaded under high load.

[0148] Non-critical: Delay batch updates until the player goes offline or the scene changes (such as when a battle ends).

[0149] Policy priority arbitration:

[0150] When multiple configuration updates conflict, they are sorted by type priority (core business type > resource-dependent type > non-critical type).

[0151] Within the same priority level, configuration dependencies are topologically sorted (for example, if configuration A depends on configuration B, then B is updated first).

[0152] 4. Multi-configuration collaborative update execution

[0153] Transactional update coordination:

[0154] Distributed lock control: Through etcd's distributed lock, the atomicity of multiple configuration updates within the same service group is ensured to avoid version overlap.

[0155] Phased submission: Split high-resource-consuming configurations into two phases: "preloading" (background data loading) and "effective switching" (atomic pointer replacement), reducing main thread blocking.

[0156] Players switch unconsciously:

[0157] Resource replacement is triggered when the player is in a non-interactive period (such as cutscenes and loading interfaces), and seamless switching is achieved through double buffering technology.

[0158] The configuration of delayed updates will automatically take effect the next time the player triggers the relevant function (such as refreshing the item description when opening the backpack).

[0159] It should be noted that this technical solution transforms previously unordered concurrent update requests into a logically self-consistent scheduling sequence: when multiple configurations need to be hot-updated simultaneously, the system first analyzes the update type of each configuration (such as combat value corrections, activity rule changes, combat scene skill special effect configurations, character equipment appearance configurations, etc.), synchronously captures the current game scene (such as the player is in a dungeon battle or socializing in the main city), and then dynamically generates an update strategy (such as immediate effect, delayed loading, or batch execution) based on the correlation between the type and the scene. This mechanism allows key updates such as core combat parameters to take effect silently when the player is in a non-combat scenario, while interface updates dynamically select an execution window based on the scene load. This not only avoids service lag caused by resource competition in the traditional full update mode, but also eliminates temporary data inconsistencies caused by cross-configuration logical coupling. Ultimately, multi-configuration hot updates achieve zero-perceived intrusion on the game process, ensuring business continuity while maintaining the integrity of the player's immersive experience.

[0160] Furthermore, the hot update type of the game configuration includes battle scene skill special effects configuration and character equipment appearance configuration; the game running scene includes battle scene and non-combat scene; when determining the update strategy of the hot update of multiple game configurations based on the game running scene and the hot update type of multiple game configurations, if the game running scene is a battle scene, the character equipment appearance configuration is hot updated to reduce the running resources of the battle scene skill special effects, and the battle scene skill special effects configuration is hot updated in the non-combat scene; if the game running scene is a non-combat scene, the character equipment appearance configuration and the battle scene skill special effects configuration are hot updated at the same time.

[0161] In the examples of this specification, the following specific implementation schemes can be used:

[0162] 1. Configuration Type and Scenario Classification Definition

[0163] Hot update type identifier:

[0164] Battle scene skill special effects configuration: core resources that affect the real-time performance of battles (such as skill particle effects and damage value calculation rules).

[0165] Character equipment appearance configuration: appearance resources not related to combat logic (such as equipment models, skin textures).

[0166] Operation scenario classification:

[0167] Battle scene: Players are in combat (such as dungeon boss battles, PVP confrontations).

[0168] Non-combat scenarios: Players are in non-confrontational environments such as the main city, social, and menu interfaces.

[0169] 2. Real-time scene state perception and event triggering

[0170] Battle scene judgment:

[0171] Player behavior monitoring: Dynamically mark players as in combat through the game event system (such as entering combat, releasing skills).

[0172] Scene stress detection: Combines frame rate, network latency, and other indicators to quantify combat intensity (such as high-intensity combo periods and low-intensity movement periods).

[0173] Non-combat scene judgment: When the player exits the battle, opens the backpack or enters the main city, the scene switching event is triggered.

[0174] 3. Scenario-driven hot update strategy execution

[0175] Scene: Battle scene;

[0176] Character equipment appearance update:

[0177] Effective immediately: Double-buffering is used to preload new appearance data into a backup memory area, and the reference pointer is atomically switched to ensure that players see the new equipment in real time.

[0178] Resource Priority Adjustment: Reduce the rendering accuracy of equipment models (such as LOD levels) to free up GPU resources for combat logic.

[0179] Skill effect update suppression:

[0180] Resource Limitation: Pause the loading of high-consumption special effects (such as full-screen particle effects) and keep the current special effect version running.

[0181] Delay Queue Mark: Add the skill effect configuration to be updated to the delay queue and bind it to the "Exit Combat" event trigger.

[0182] Scene: Non-combat scene;

[0183] Batch hot update execution:

[0184] Skill special effects update: Extract the configuration to be updated from the delay queue, load all resources (such as high-definition particles and physical simulation parameters), and replace the old version.

[0185] Supplemental cosmetic update: Restored high-precision rendering and applied the latest configuration to models that were degraded during battle due to resource limitations.

[0186] Seamless switching guarantee: Resource replacement is completed during the scene switching transition period (such as the loading interface) without the player's perception.

[0187] 4. Dynamic resource control and abnormal circuit breaking

[0188] Resource management during combat period:

[0189] CPU / GPU quota allocation: Set resource caps (such as the maximum number of cores occupied) for skill special effects threads to ensure a stable combat logic frame rate.

[0190] Downgrade backup plan: If the new appearance configuration fails to load, it will automatically roll back to the last available version to avoid missing character models.

[0191] Fault tolerance mechanism during non-combat period:

[0192] Shard loading: Split large skill special effect resources into multiple shards and load them on demand to prevent sudden memory surges.

[0193] Version consistency check: After updating, the skill special effect version number is compared with the configuration center data, and a retry is triggered if there is any inconsistency.

[0194] It should be noted that this technical solution deeply couples hot update operations with players' real-time experience needs by establishing a scene-sensitive update strategy layering mechanism: in combat scenes, priority is given to appearance configuration updates with low resource consumption, and skill special effects updates with high computing loads are temporarily suspended. In non-combat scenes, a full update window is opened, allowing the system to intelligently allocate resources based on the player's situation - avoiding frame rate fluctuations or operation delays caused by overloading of special effects resources at critical moments in combat, and utilizing the low-pressure environment of the non-combat stage to efficiently complete full configuration synchronization, thereby maintaining the continuity of the player's immersive experience while achieving a dynamic balance between hot update operations and real-time game resource usage, ultimately achieving dual optimization of business demand response and user experience assurance.

[0195] Furthermore, if the non-combat scene is an item extraction process, the embodiment of this specification can simultaneously perform hot update processing on the character equipment appearance configuration and the combat scene skill special effect configuration, and trigger hidden reward sending special effects during the item extraction process to replace the game delay caused by the hot update processing.

[0196] In the examples of this specification, the following specific implementation schemes can be used:

[0197] 1. Non-combat scene determination and event triggering

[0198] Item extraction scene recognition:

[0199] Player behavior monitoring: When a player triggers an item extraction operation (such as opening a treasure chest or interacting with the card extraction interface), the system marks the current state as "item extraction process".

[0200] Scene state persistence: Record scene tags (such as loot_animation) in the player session data to ensure that subsequent operations are strongly associated with the scene.

[0201] 2. Parallel hot updates and special effects triggering

[0202] Dual configuration hot update execution:

[0203] Resource preloading: Before the item extraction animation starts, the background preloads the updated data of the character equipment appearance and skill effects into the memory buffer.

[0204] Atomic switching: During the extraction animation playback, two configurations are simultaneously effective through lock-free pointer replacement (such as double buffering technology), ensuring that the logic layer is unaware.

[0205] Hidden reward effects intervention:

[0206] Timing synchronization: At the moment the hot update is completed (for example, within 1 frame after the data is replaced), hidden reward special effects (such as full-screen golden light, rare item floating display) are automatically triggered, shifting players' attention from potential lag to visual feedback.

[0207] Dynamic adaptation: Adjust the duration of special effects based on the update time. If the update is fast, shorten the special effect display; if the delay is high, extend the special effect animation and add interactive elements (such as click to reveal rewards).

[0208] 3. Resource Scheduling and Experience Guarantee

[0209] Update resource priority management:

[0210] Appearance Configuration: Prioritize loading low-precision resources (such as equipment icons and thumbnails) to ensure instant display.

[0211] Skill Effects: Asynchronously load high-precision resources (such as particle effects and physics simulation data) in the background, and delay until the battle scene preload is complete.

[0212] Performance guarantee strategy:

[0213] Downgraded rendering: If a frame rate drop is detected during the update, the quality of special effects will be automatically reduced (such as reducing the number of particles and disabling physics simulation) to maintain smoothness.

[0214] Timeout circuit breaker: Set the maximum allowed update time (such as 3 seconds). After the timeout, the update will be forcibly interrupted and rolled back to the old version. Players will be compensated by resending rewards via email.

[0215] It should be noted that this technical solution deeply binds the hot update operation with the positive feedback mechanism within the game. In specific interactive nodes in non-combat scenarios (such as item extraction), the system synchronously executes multi-configuration hot updates and triggers hidden reward effects, allowing players to transform short update delays into surprising experiences at the perceptual level. When players focus on the pleasant anticipation of reward acquisition, the resource loading process of the background hot update is cleverly transformed into a presentation carrier for visual effects. It not only utilizes the natural offset window of the player's psychological attention to complete the update without a sense of touch, but also compensates for the potential experience gap caused by the technical operation through the immediate delivery of hidden rewards. While ensuring the timeliness of the hot update, the original technical limitations are transformed into emotional touchpoints that improve user retention and activity, thereby achieving a positive cycle enhancement of technical operation and maintenance and player experience.

[0216] It should be noted that, in combination with the above technical features, the following specific technical problems can be further solved:

[0217] In game development, functional configuration parameters are typically edited by developers using Excel. With the advent of technology, few projects directly load Excel files; instead, they convert Excel data into another data format. Options include converting to code data or converting to pure data formats (JSON / XML / ...). Converting to code often requires restarting the game server or using dynamic language code to dynamically modify data. Restarting services severely impacts the online player experience, so game companies often resort to midnight restarts, which severely impacts the health of developers and the next day's work efficiency. Using dynamic languages ​​to process configuration data requires writing logic in dynamic languages, which are not very efficient, making it difficult to identify bugs. Solutions using pure data often require writing an intermediate server to provide services to other servers. This significantly increases the complexity of the development process and can also affect collaborative development efficiency due to downtime and maintenance releases from the intermediate server.

[0218] To this end, this solution can solve the problem of requiring service downtime for updates and avoid the various costs (development costs, communication costs, and maintenance costs) caused by intermediate servers. The following is an overview of this solution:

[0219] This solution is a scalable, low-cost technical solution for game configuration data. Its overall architecture includes N (>=1) game services, etcd, and its associated toolset. This solution converts Excel spreadsheet data into Protobuf data, then uploads the Protobuf data to etcd for use by the game services. This solution uses Java to write game services and leverages Java's reflection mechanism to replace class properties at runtime, enabling hot updates of configuration data.

[0220] This solution allows configurations to be made without restarting the service. Java boasts higher development and execution efficiency than dynamic languages. This solution offers a high degree of decoupling. etcd runs as an independent service and requires no maintenance or updates unless it has security vulnerabilities. It generally does not experience downtime. The byte array of the protobuf converted from Excel is permanently stored in etcd. Configuration table uploads can be performed regardless of whether the game service is enabled or disabled. The admin service or etcdctl tool that uploads the configuration table does not need to be aware of the status of the game service.

[0221] In the early stages of development, developers can use the etcdctl command line to upload configuration tables. Admin backend projects are typically developed later in the project, saving early development costs and enabling faster verification of gameplay. After the admin project is launched, you can still consider using etcdctl to debug it, or as a backup, upload configuration tables if issues arise.

[0222] etcd is a KV database. We can play around with the key so that we can use one etcd to drive multiple sets of game services. For example, by using the format / config / {group} / filename and using different identifiers for the group, we can implement one etcd to serve multiple sets of game services at the same time. This approach is more cost-effective for rolling service deployment, debugging, and development. etcd will mark each key with a version number. Every time the value corresponding to the key changes, the version number will be increased by 1. At the same time, etcd has a key listening event, and the game service listens for the key change event. When the key changes, it will automatically pull the latest key information, and then compare the version number. If the version number becomes larger, the configuration data will be pulled again. The development cost and computing cost of this mechanism are relatively low, and at the same time, it will use automated operations to avoid errors that may occur due to manual operations. Figure 5The data flow diagram provided in the embodiment of this specification includes multiple game services, namely game service 1, game service 2 and game service 3. Game services can be player, platformy and fight. Planning, operation and development upload the latest configuration table data to etcd through admin and etcdctl, and then etcd sends it to game service 1, game service 2 and game service 3.

[0223] Furthermore, for the above technical solution, the examples of this specification also provide the following specific implementation plans:

[0224] When the game service starts, it first retrieves the configuration table data from etcd, which is the contents of the previous byte[] file. The game service uses a key of the form / config / {group} / filename to retrieve the configuration file data, where group is a variable and can be any custom group name. filename is a very specific file name, such as Item.bytes. The same naming convention is used in the previous upload step. In the current design, a corresponding Java index type, such as ItemIndex, is written for each file. This class is responsible for preprocessing the contents of item.bytes. Each filename in the previous entry requires a corresponding index type. These index types must implement a common Java interface; otherwise, they cannot be managed.

[0225] A Java ConfigManager is required to manage all index types. All index types are fields on the ConfigManager. Loading and hot updates are performed using the following method.

[0226] 1. Use reflection to generate instances of index types.

[0227] 2. Reflection is called on the protobufJava type (Excel also generates proto files, which can be used to generate protobufJava types) to convert the binary data obtained from etcd into a usable Java object.

[0228] 3. Call the initialization method of the instance obtained in the first step, and the parameter is the result obtained in the second step. After the initialization is successful, record the current etcdkey version number.

[0229] 4. After successful initialization, use Java reflection technology to set the instance of the first step as the property of ConfigManager.

[0230] 1. Initialization process

[0231] When the application starts, ConfigManager uses the singleton mode to ensure that there is only one configuration manager in the world. The initialization process includes the following steps:

[0232] 1. Automatic discovery of configuration items: The system automatically scans all fields in the ConfigManager class through reflection and identifies fields that implement the IConfigIndex interface (such as ConfigDressUpIndex, ConfigSceneIndex, and ConfigItemIndex).

[0233] 2. Prepare configuration loading: Store the discovered configuration fields in the allFields list in preparation for subsequent unified loading.

[0234] 3. Error handling mechanism setting: Receive an exception callback function, which is used when an error occurs in configuration loading.

[0235] 4. Start configuration loading: load configuration data from ETCD.

[0236] 2. Configuration loading process

[0237] Configuration loading is the core of the entire system. The specific process is as follows:

[0238] 1. Loop through each configuration item: The system iterates through all previously discovered configuration fields.

[0239] 2. Create a configuration index object: Create a corresponding configuration index instance (such as ConfigItemIndex) for each configuration field.

[0240] 3. Get the configuration file name: Get the corresponding configuration file name (such as "ItemTable.bytes") by calling the configFileName() method of the configuration index.

[0241] 4. Parse configuration data: Use the parseFrom method of the configuration class specified by the configuration index (such as the ItemTable class, generated by protobuf) to parse the data in the input stream.

[0242] 5. Load into index object: Call the load method of the configured index to load the parsed data into the index object for preprocessing.

[0243] 6. Set the modified version number: record the modified version number of the configuration data to track configuration updates.

[0244] 7. Inject the index object into the manager: Set the loaded configuration index object to the corresponding field of ConfigManager.

[0245] 3. Advantages of Data Preprocessing in Improving Query Efficiency

[0246] Taking ConfigItemIndex as an example, this article demonstrates how data preprocessing improves query efficiency:

[0247] 1. Build ID map: After loading the data, immediately build the mapping relationship from ID to Item object (buildMapById method), so that querying items by ID becomes an O(1) time complexity operation without traversing the entire list each time.

[0248] 2. Special attribute index: For certain types of items (such as fireworks), the system pre-extracts their special parameters (extParam) and constructs a dedicated map (extParamsFireworksMap) to facilitate quick query of special attributes such as the life cycle of fireworks.

[0249] 3. Immutable mapping: After construction is completed, use ImmutableMap to encapsulate the mapping relationship, which not only ensures thread safety but also improves query performance.

[0250] 4. Dedicated query methods: Provide dedicated query methods such as getFireworkLifeTime to obtain data directly from pre-built maps without parsing strings or performing complex calculations at runtime.

[0251] This preprocessing mechanism allows the configuration system to pay a one-time processing cost during loading, but achieves significant performance improvements in all subsequent query operations. It is particularly suitable for configuration data scenarios that are frequently read and rarely updated.

[0252] It's worth noting that this configuration management system addresses the challenges of managing configuration data within applications through technologies like automatic discovery and loading of configuration items, data preprocessing, and efficient indexing. It not only simplifies the configuration loading process but also significantly improves data query efficiency by pre-building mapping relationships, while maintaining excellent scalability and maintainability.

[0253] Figure 6 A schematic diagram of pulling configurations from etcd for the game services provided in one or more embodiments of this specification, in which game services 1, 2, and 3 respectively make requests and respond to etcd.

[0254] Figure 7This is a schematic diagram of configuration table data update notification provided in one or more embodiments of this specification, where key change notifications are sent between etcd and game service 1, game service 2, and game service 3.

[0255] Figure 8 A schematic structural diagram of a game configuration table data hot update device provided in one or more embodiments of this specification includes: a monitoring unit 801, an event initiating unit 802, a determining unit 803, a creating unit 804 and a replacing unit 805.

[0256] The monitoring unit 801 monitors whether the key value of the distributed key-value storage database etcd changes during the operation of multiple game services;

[0257] Event initiating unit 802, if yes, initiates a change event to the plurality of game services, the change event including the latest version number of the key value in etcd and the latest configuration table data;

[0258] Determining unit 803, if the latest version number is greater than the current version number of the key value in the currently loaded etcd, determines in the Java field manager the latest index type related to the game service corresponding to the latest configuration table data, and determines the specific configuration field corresponding to the latest index type;

[0259] A creating unit 804 creates a corresponding latest configuration index instance for the latest index type;

[0260] The replacement unit 805 loads the latest configuration table data into the latest configuration index instance, and replaces the latest configuration index instance with the specific configuration field, so that the game service implements hot update of the corresponding game configuration by using the specific configuration field.

[0261] Figure 9 A schematic diagram of a device for hot updating game configuration table data provided in one or more embodiments of this specification includes:

[0262] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to:

[0263] During the operation of multiple game services, monitor whether the key value of the distributed key-value storage database etcd has changed; if so, initiate a change event to the multiple game services, and the change event includes the latest version number of the key value in the etcd and the latest configuration table data; if the latest version number is greater than the current version number of the key value in the currently loaded etcd, determine the latest index type related to the game service corresponding to the latest configuration table data in the Java field manager, and determine the specific configuration field corresponding to the latest index type; create a corresponding latest configuration index instance for the latest index type; load the latest configuration table data into the latest configuration index instance, and replace the latest configuration index instance with the specific configuration field, so that the game service can achieve hot update of the corresponding game configuration by using the specific configuration field.

[0264] The various embodiments in this specification are described in a progressive manner. Similar portions between the various embodiments can be referenced to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the device, apparatus, and non-volatile computer storage medium embodiments are generally similar to the method embodiments, so their descriptions are relatively simplified. For relevant details, refer to the descriptions of the method embodiments.

[0265] The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences from other embodiments. In particular, the device embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

[0266] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0267] In the embodiments provided in this application, it should be understood that the disclosed devices / network equipment and methods can be implemented in other ways. For example, the device / network equipment embodiments described above are merely illustrative. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

[0269] In addition, the functional units in the various embodiments of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above units may be implemented in the form of hardware or software.

[0270] If the integrated module / unit is implemented as a software functional unit and sold or used as a standalone product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application can implement all or part of the process steps in the above-mentioned method embodiments by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When executed by a processor, the computer program can implement the steps of each of the above-mentioned method embodiments. The computer program includes computer program code, which can be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal, and software distribution medium. It should be noted that the content of the computer-readable medium can be appropriately increased or decreased based on the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media does not include electric carrier signals and telecommunication signals.

[0271] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A method for hot updating game configuration table data, characterized in that: The method comprises: During the operation of multiple game services, monitor whether the key values ​​of the distributed key-value storage database etcd have changed; If so, a change event is initiated to the plurality of game services, wherein the change event includes the latest version number of the key value in etcd and the latest configuration table data; If the latest version number is greater than the current version number of the key value in the currently loaded etcd, then determine the latest index type related to the game service corresponding to the latest configuration table data in the Java field manager, and determine the specific configuration field corresponding to the latest index type; Creating a corresponding latest configuration index instance for the latest index type; The latest configuration table data is loaded into the latest configuration index instance, and the latest configuration index instance is replaced with the specific configuration field, so that the game service implements a hot update of the corresponding game configuration by using the specific configuration field.

2. The method according to claim 1, characterized in that The method further comprises: When the plurality of game services are started for the first time, corresponding configuration table data is obtained in the etcd through a preset key value; Automatically scan the configuration fields in the Java field manager through a reflection mechanism to determine the index type of the configuration table data corresponding to the configuration fields; Create a corresponding configuration index instance for the index type; The configuration table data is loaded into the configuration index instance, and the configuration index instance is replaced with the relevant configuration field, so that the plurality of game services can start corresponding game configurations by using the relevant configuration fields.

3. The method according to claim 2, characterized in that After loading the configuration table data into the configuration index instance, the method further includes: Record the version number of the key value in etcd to track the configuration table data update.

4. The method according to claim 1, wherein Before initiating a change event to the plurality of game services, the method further includes: Receive the latest Excel files edited by update personnel; Convert the latest Excel file into a protobuf byte array, and store the protobuf byte array into a byte[] file; Upload the byte[] file to the etcd to obtain the latest configuration table data used by the game service for hot updating game configuration.

5. The method according to claim 1, wherein The key value includes a configuration file name, and loading the latest configuration table data into the latest configuration index instance includes: Acquire the name of the latest configuration file in the latest configuration table data by calling the preset method of the latest configuration index instance; The latest configuration file name is loaded into the latest configuration index instance.

6. The method according to claim 5, characterized in that The key value also includes a preset group name identifier, and the method further includes: The game services corresponding to the key values ​​are determined based on the group name identifier, so that the game services can determine the corresponding key values ​​when implementing hot updates of the corresponding game configurations.

7. The method according to claim 1, characterized in that The method further comprises: In the hot updates of the game configurations corresponding to the plurality of game services, determining a hot update level of each game configuration; triggering a hot update of multiple game configurations simultaneously during the running of multiple game services for a specified user, and determining a game running scenario and a hot update level of the multiple game configurations; Based on the game running scenario and the hot update levels of the multiple game configurations, an update strategy for the hot update of the multiple game configurations is determined, so that the game service implements the hot update of the multiple game configurations based on the update strategy.

8. The method according to claim 7, characterized in that The game configuration includes battle scene skill special effect configuration and character equipment appearance configuration; the game running scene includes battle scene and non-battle scene; The step of determining the update strategy for the hot update of the plurality of game configurations based on the game running scenario and the hot update levels of the plurality of game configurations includes: If the game running scene is a battle scene, hot update the appearance configuration of the character equipment to reduce the running resources of the battle scene skill special effects, and hot update the battle scene skill special effects configuration in the non-combat scene; If the game running scene is a non-combat scene, the character equipment appearance configuration and the combat scene skill special effect configuration are simultaneously subjected to hot update processing.

9. The method according to claim 8, characterized in that If the non-combat scene is an item extraction process, the method further includes: The character equipment appearance configuration and the battle scene skill special effect configuration are simultaneously subjected to hot update processing, and a hidden reward sending special effect is triggered during the item extraction process to replace the game delay caused by the hot update processing.

10. A device for hot updating game configuration table data, characterized in that: include: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to: During the operation of multiple game services, monitor whether the key values ​​of the distributed key-value storage database etcd have changed; If so, a change event is initiated to the plurality of game services, wherein the change event includes the latest version number of the key value in etcd and the latest configuration table data; If the latest version number is greater than the current version number of the key value in the currently loaded etcd, then determine the latest index type related to the game service corresponding to the latest configuration table data in the Java field manager, and determine the specific configuration field corresponding to the latest index type; Creating a corresponding latest configuration index instance for the latest index type; The latest configuration table data is loaded into the latest configuration index instance, and the latest configuration index instance is replaced with the specific configuration field, so that the game service implements a hot update of the corresponding game configuration by using the specific configuration field.

Images