Game configuration table data hot updating method and device

Abstract

The invention relates to the technical field of game development, and discloses a game configuration table data hot updating method and device, and the method comprises the steps: monitoring whether the key value of a distributed key value storage database etcd is changed or not in the operation process of a plurality of game services; if yes, a change event is initiated to multiple game services, and the change event comprises the newest version number of the key value in the etcd and newest configuration table data; if the newest version number is greater than the current version number of the key value in the currently loaded etcd, determining a newest index type related to the game service corresponding to the newest configuration table data in a Java field manager, and determining a specific configuration field corresponding to the newest index type; creating a corresponding newest configuration index instance for the newest index type; and loading the latest configuration table data to the latest configuration index instance, and replacing the latest configuration index instance to the specific configuration field, so that the game service realizes hot update of the corresponding game configuration by using the specific configuration field.

Description

Technical Field

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

[0002] In modern online game development, game function configuration parameters are usually edited and maintained by planners through Excel spreadsheets, which is a basic workflow that has been followed in the game industry for more than a decade. With the evolution of the technical architecture, current mainstream game projects no longer directly load native Excel files, but convert them into a structured data form through a format conversion mechanism.

[0003] Pre-compiling the Excel configuration table into a code file in a strongly typed language (such as Java) has significant drawbacks. That is, every time the configuration is updated, the server-side program must be recompiled and the server restarted. For online players, server restart will cause serious experience problems such as game process interruption and data rollback. To reduce the impact, operators usually choose to perform updates during the early morning hours, which not only disrupts the work and rest of the operation and maintenance personnel (long-term night work causes health hazards), but also leads to a decline in work efficiency the next day, forming a vicious cycle. Summary of the Invention

[0004] One or more embodiments of this specification provide a method and device for hot updating configuration table data of a game to solve the technical problems raised in the background art.

[0005] One or more embodiments of this specification adopt the following technical solutions: A method for hot updating configuration table data of a game provided by one or more embodiments of this specification, the method comprising: During the operation of multiple game services, monitoring whether the key-value of the distributed key-value storage database etcd changes; If so, initiating a change event to multiple said 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 fields 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 into the specific configuration fields, so that the game service can achieve hot updating of the corresponding game configuration by using the specific configuration fields.

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

[0007] Furthermore, the method further includes: When multiple game services are started for the first time, obtain the corresponding configuration table data in the etcd through a preset key value; Through the reflection mechanism, automatically scan the configuration fields in the Java field manager 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; Load the configuration table data into the latest configuration index instance, and replace the latest configuration index instance into the relevant configuration fields, so that multiple game services can start the corresponding game configuration by using the relevant configuration fields.

[0008] It should be noted that the present invention constructs a full-life cycle configuration management closed-loop by introducing an automated configuration loading process based on the reflection mechanism at the service startup stage: when the game service is started for the first time, the system automatically obtains the configuration table data corresponding to the key value from the etcd, uses the reflection technology to scan the configuration fields in the Java field manager and dynamically parses their index types, and then creates a matching configuration index instance to complete data loading and field replacement. This process transforms the configuration field binding operation that needs to be manually maintained in the traditional solution into an automated runtime behavior, so that multiple service nodes do not need to predefine the configuration loading logic or manually adjust the code when starting up, which not only eliminates the risk of field type mismatch caused by manual coding omissions, but also ensures that the initial configuration states of all service instances in the distributed environment are strictly consistent; at the same time, this 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 conflict caused by the separation of the initialization static loading and dynamic update logic in the traditional solution, and significantly improving the system robustness and operation and maintenance efficiency.

[0009] Furthermore, after loading the configuration table data into the latest configuration index instance, the method further includes: Record the version number of the key value in the etcd for tracking the update of the configuration table data.

[0010] It should be noted that through the establishment of a closed-loop verification mechanism for version number tracking, the current version number of etcd key values is synchronously recorded after configuration loading in this technical solution, enabling all game service nodes in the distributed system to form a globally consistent reference benchmark for the update status of configuration data. This design uses the version number as the only reliable traceability identifier for configuration data changes. In the subsequent hot update process, it is possible to accurately determine whether each node needs to perform an update operation by comparing version numbers, completely avoiding the risks of incorrect updates and missed updates caused by timestamp drift, file hash calculation errors, or manual marking omissions in the traditional solution. At the same time, the atomicity and real-time nature of version number recording ensure strong consistency of configuration states among multiple nodes. Even in abnormal scenarios such as network fluctuations, the system can still quickly resume synchronization based on the version numbers stored persistently, thus achieving accurate convergence and self-healing of the configuration states of the entire cluster without the business being aware.

[0011] Further, before sending change events to the multiple game services, the method further includes: Receiving the latest Excel file edited by the update personnel; Converting the latest Excel file into a protobuf byte array and storing the protobuf byte array in a byte[] file; Uploading the byte[] file to the etcd to obtain the latest configuration table data for the game services to perform hot updates on game configurations.

[0012] It should be noted that through the construction of a standardized configuration data preprocessing channel, the Excel file edited by the planners is serialized and converted into a highly compatible byte stream via protobuf and persisted to the etcd, establishing double guarantees of type safety and transmission efficiency at the data source: the strong contract feature of protobuf ensures a strict mapping between the Excel data structure and the Java server-side fields, eliminating parsing errors caused by loose type matching during the conversion of traditional text formats (such as JSON / XML); at the same time, the storage form of the byte stream not only reduces the read and write overhead of the etcd, but also provides a unified data interface for the multi-language microservice architecture through the cross-platform support ability of the protocol buffer. The deep integration of this preprocessing mechanism with the distributed key-value storage enables the planners to only need to maintain the Excel file according to the established rules to automatically trigger the subsequent hot update process, transforming the originally manual intervention-dependent configuration release, format verification, version management, and other links into a standardized pipeline operation, not only eliminating online failures caused by human operation errors, but also reducing the full-link time-consuming from configuration modification to online effectiveness to the minute level, thus improving the development and operation and maintenance collaboration efficiency while providing solid technical support for game dynamic optimization.

[0013] Further, the key value includes a configuration file name, and the loading of 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.

[0014] 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 rely 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.

[0015] Furthermore, 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.

[0016] It should be noted that this technical solution deeply couples distributed configuration management with service group topology by introducing the logical hierarchical dimension of group name identification in the key-value system: during the hot update process, the system dynamically associates the key value with the target game service group based on the group name identification, so that the configuration updates of different functional modules (such as combat system, social system) or business partitions (such as telecommunications area, Netcom area) in the same physical cluster can be accurately isolated and directed. This design breaks through the extensive mode of traditional global broadcast updates and controls the impact scope of configuration changes within the preset service group boundaries, which not only avoids unnecessary resource consumption of irrelevant service nodes due to receiving redundant data, but also prevents systemic risks caused by cross-module configuration pollution due to misoperation; at the same time, the explicit declaration mechanism of group name identification enables operation and maintenance personnel to perform configuration management based on business semantics rather than physical addresses, and automatically inherits group attributes when service instances are dynamically expanded and reduced, thereby achieving seamless adaptation of configuration strategies and infrastructure elasticity, significantly improving the operation and maintenance controllability and fault isolation efficiency of large-scale distributed game architectures.

[0017] Further, the method further includes: During the hot update of the corresponding game configurations of multiple game services, determining the hot update types of each game configuration; During the operation of multiple game services for a specified user, triggering the hot update of multiple game configurations simultaneously, and determining the game running scenario and the hot update types of multiple game configurations; Based on the game running scenario and the hot update types of multiple game configurations, determining the update strategy for the hot update of multiple game configurations, so that the game service can implement the hot update of multiple game configurations based on the update strategy.

[0018] It should be noted that this technical solution converts the originally disordered concurrent update requests into a logically self-consistent scheduling sequence: when multiple configurations need to be hot updated simultaneously, the system first parses the update types of each configuration (such as combat numerical correction, activity rule change, combat scene skill special effect configuration, character equipment appearance configuration, etc.), synchronously captures the current game scene (such as the player is in a dungeon battle or main city social interaction), and then dynamically generates an update strategy based on the relevance between the type and the scene (such as immediate effect, deferred loading, or batch execution). This mechanism enables key updates such as core combat parameters to take effect silently when the player is in a non-confrontational scene, while interface updates dynamically select the execution window according to the scene load, avoiding both service lags caused by resource contention in the traditional full-scale update mode and temporary data contradictions caused by cross-configuration logical coupling, and ultimately achieving zero-perception intrusion of the multi-configuration hot update on the game process, while ensuring business continuity and maintaining the integrity of the player's immersive experience.

[0019] Further, the hot update types of the game configuration include combat scene skill special effect configuration and character equipment appearance configuration; the game running scenarios include combat scenes and non-combat scenes; The determining the update strategy for the hot update of multiple game configurations based on the game running scenario and the hot update types of multiple game configurations includes: If the game running scenario is a combat scene, then perform a hot update on the character equipment appearance configuration, reduce the running resources of the combat scene skill special effects, and perform a hot update process on the combat scene skill special effect configuration in the non-combat scene; If the game running scenario is a non-combat scene, then perform a hot update process on the character equipment appearance configuration and the combat scene skill special effect configuration simultaneously.

[0020] It should be noted that, by establishing a hierarchical mechanism for scene-sensitive update strategies, this technical solution deeply couples the hot update operation with the real-time experience requirements of players: in the combat scene, it preferentially processes the update of appearance configurations with low resource consumption and defers the update of skill special effects with high computational loads. In non-combat scenes, a full-update window is opened, enabling the system to intelligently allocate resources according to the situation where the player is located. This not only avoids frame rate fluctuations or operation delays caused by the heavy loading of special effect resources at critical moments in combat but also efficiently completes the full configuration synchronization using the low-pressure environment during non-combat phases. Thus, while maintaining the continuity of the player's immersive experience, it achieves a dynamic balance between hot update operations and the real-time resource occupancy of the game, ultimately achieving a dual optimization of business requirement response and user experience guarantee.

[0021] Further, if the non-combat scene is the item extraction process, the method further includes: Performing hot update processing on both the appearance configuration of the character's equipment and the skill special effect configuration in the combat scene, and triggering a hidden reward sending special effect during the item extraction process to replace the game delay caused by the hot update processing.

[0022] It should be noted that, by deeply binding the hot update operation with the positive feedback mechanism in the game, in specific interaction nodes (such as item extraction) in non-combat scenes, the system synchronously performs multi-configuration hot updates and triggers hidden reward special effects, enabling players to transform the short update delay into a surprising experience at the perceptual level. When players are focused on the pleasant anticipation of obtaining rewards, the resource loading process of the background hot update is cleverly transformed into the presentation carrier of visual special effects. This not only completes the seamless update using the natural deviation window of the players' psychological attention but also compensates for the potential experience gap caused by technical operations through the immediate delivery of hidden rewards. Thus, while ensuring the timeliness of the hot update, it transforms the original technical limitations into emotional touchpoints for enhancing user retention and activity, achieving a positive cycle enhancement of technical operation and player experience.

[0023] A configuration table data hot update device for a game provided by one or more embodiments of this specification includes: 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, and when the instructions are executed by the at least one processor, the at least one processor is enabled to: During the operation of multiple game services, monitor whether the key-value in the distributed key-value storage database etcd changes; if so, initiate a change event to the multiple game services, where 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, 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 fields 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 into the specific configuration fields, so that the game service can achieve hot update of the corresponding game configuration by using the specific configuration fields.

[0024] The above at least one technical solution adopted in the embodiments of the present specification can achieve the following beneficial effects: Under the condition of detecting version number update, the present invention uses the Java field manager to parse the index type and specific configuration fields 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. Description of the Drawings

[0025] In order to more clearly illustrate the technical solutions in the embodiments of the present specification or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments recorded in the present specification. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained according to these drawings. In the drawings: Figure 1 It is an application environment diagram of a method for hot updating configuration table data of a game provided by one or more embodiments of the present specification; Figure 2 It is a flow diagram of a method for hot updating configuration table data of a game provided by one or more embodiments of the present specification; Figure 3 It is a flow diagram of the first startup of a game service provided by one or more embodiments of the present specification; Figure 4 It is a flow diagram of uploading an Excel file to etcd provided by one or more embodiments of the present specification; Figure 5 It is a data flow diagram provided by one or more embodiments of the present specification; Figure 6 It is a schematic diagram of a game service pulling configuration from etcd provided by one or more embodiments of the present specification; Figure 7 Schematic diagram of configuration table data update notification provided for one or more embodiments of this specification; Figure 8 Schematic diagram of the structure of a hot update device for configuration table data of a game provided for one or more embodiments of this specification; Figure 9 Schematic diagram of the structure of a hot update device for configuration table data of a game provided for one or more embodiments of this specification. Detailed implementation manners

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

[0027] In order to enable those skilled in the art to better understand the technical solutions in this specification, the following will clearly and completely describe the technical solutions in the embodiments of this specification with reference to the accompanying drawings in the embodiments of this specification. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all the embodiments. Based on the embodiments of this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of this specification.

[0028] In modern online game development, game function configuration parameters are usually edited and maintained by planners through Excel tables, which is a basic workflow that has been followed in the game industry for more than a decade. With the evolution of the technical architecture, current mainstream game projects no longer directly load native Excel files, but convert them into a structured data form through a format conversion mechanism.

[0029] Pre-compiling the Excel configuration table into a code file in a strongly typed language (such as Java), this mode has significant defects, that is, every time the configuration is updated, the server-side program must be recompiled and the server must be restarted. For online players, server restart will cause serious experience problems such as game process interruption and data rollback. To reduce the impact, operators usually choose to perform updates during the early morning hours, which not only disrupts the work and rest of operation and maintenance personnel (long-term night work causes health hazards), but also leads to a decline in work efficiency the next day, forming a vicious cycle.

[0030] The solution of this application can be applied to the scenario of hot updating configuration table data of game terminals. Figure 1 Shows an application environment diagram of a method for hot updating configuration table data of a game provided by an embodiment of this application, as Figure 1As shown, the terminal 102 communicates with the server 103 via the network. The data storage system 101 can store the data that the server 103 needs to process. The data storage system 101 can be integrated on the server 103, or placed in the cloud or on other network servers. The terminal 102 can obtain the historical behavior data of the user in different operation scenarios and the running status of the MR device; extract the common behavior information of the user from the historical behavior data of the user in each operation scenario; extract the common status information of the MR device from the running status of the MR device in each operation scenario; generate the device habitual status of the MR device in the operation scenario by combining the common behavior information and the common status information; associate the operation scenario with the device habitual status to obtain the behavior habit label. Or the above process of constructing the label is executed in the server 103, that is, the server obtains the historical behavior data of the user in different operation scenarios and the running status of the MR device; extracts the common behavior information of the user from the historical behavior data of the user in each operation scenario; extracts the common status information of the MR device from the running status of the MR device in each operation scenario; generates the device habitual status of the MR device in the operation scenario by combining the common behavior information and the common status information; associates the operation scenario with the device habitual status to obtain the behavior habit label.

[0031] Among them, the game terminal can specifically include a smart phone, smart home appliances, a tablet computer, a virtual reality headset (Virtual Reality Headset, VR headset), augmented reality glasses (Augmented Reality Glasses, AR glasses), an electronic display screen, and a mixed reality (Mixed Reality, MR) device, etc. Among them, the MR device can be an MR glasses, an MR helmet, an MR camera, etc. The vehicle-mounted system can be a vehicle-mounted chip, a vehicle-mounted device (such as a car computer, a vehicle-mounted computer, a sensor with voice recognition function, etc.).

[0032] Figure 2 It is a schematic flowchart of a method for hot updating configuration table data of a game provided by one or more embodiments of this specification. This process can be executed by a game configuration table data hot update system. Some input parameters or intermediate results in the process allow manual intervention and adjustment to help improve accuracy.

[0033] The method process steps of the embodiments of this specification are as follows: S201, during the operation of multiple game services, monitor whether the key values in the distributed key-value storage database etcd change.

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

[0035] S202, if so, send a change event to the multiple game services, where the change event includes the latest version number of the key-value in etcd and the latest configuration table data.

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

[0037] 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 fields corresponding to the latest index type.

[0038] In the embodiments of this specification, the following specific implementation solutions can be adopted: Dynamic binding of index types: Each configuration file filename (such as item.bytes) needs to correspond to a Java class (such as ItemIndex) that implements the IConfigIndex interface, and this interface defines the load(protoData) method for loading Protobuf into memory.

[0039] Maintain a file-index type mapping table in ConfigManager: When the service is started, by scanning all classes that implement IConfigIndex, the IConfigIndex interface defines the String configFileName() method to represent the file name concerned by the current index type. When the S202 event carries the file name (such as item.bytes), obtain the corresponding ItemIndex class through the mapping table.

[0040] S204, create a corresponding latest configuration index instance for the latest index type.

[0041] In the embodiments of this specification, the following specific implementation solutions can be adopted: 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.

[0042] Call the load(protoData) method: Input the Protobuf object in the S202 event to generate a complete configuration object (for example, after instantiating ItemIndex, it contains all item property data).

[0043] Dependency pre-check: Check the integrity of the new instance: For example, verify that the required fields in ItemIndex (such as item ID, name) are not empty. If the check fails, terminate the process and give an alarm.

[0044] In S205, load the latest configuration table data into the latest configuration index instance, and replace the latest configuration index instance into the specific configuration field, so that the game service can achieve hot update of the corresponding game configuration by using the specific configuration field.

[0045] In the embodiments of this specification, the following specific implementation methods can be adopted: Resource recycling and notification: After the old instance is dereferenced, the memory is automatically released by the JVM garbage collection mechanism.

[0046] Trigger callback notification: Notify relevant modules (such as cache system, combat logic) to reload the dependent configuration through the event bus (such as EventBus) to ensure global state consistency.

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

[0048] Further, if multiple game services are started for the first time, refer to Figure 3 The schematic flow diagram of the first startup of the game service shown.

[0049] In S301, obtain the corresponding configuration table data through the preset key value in the etcd.

[0050] In S302, through the reflection mechanism, automatically scan the configuration fields in the Java field manager to determine the index type of the configuration table data corresponding to the configuration fields.

[0051] In S303, create a corresponding configuration index instance for the index type.

[0052] S304. Load the configuration table data into the latest configuration index instance and replace the latest configuration index instance in the relevant configuration fields, so that multiple game services can start the corresponding game configurations by using the relevant configuration fields.

[0053] In the embodiments of this specification, for the first startup of the above game service, the following specific implementation solutions can be adopted: 1. Initialize configuration pulling Predefine key-value path rules: When the service starts, according to the preset key structure of / config / {group} / filename (such as / config / {group} / Item.bytes), send a single query request to etcd to pull the Protobuf binary data of all current active configuration files.

[0054] {group} is the server group. For example, the corresponding example for prod_3.5.12 is: / config / prod_3.5.12 / Item.bytes, / config / prod_3.5.12 / Skill.bytes.

[0055] 2. Automatic index type discovery and mapping Interface constraints and class scanning: All index types (such as ItemIndex) need to implement the unified interface IConfigIndex, and this interface defines the load(protoData) method for data loading. When the service starts, scan the package path where ConfigManager is located through reflection, identify all classes that implement this interface, and establish a mapping table of filename → index class (such as Item.bytes corresponding to ItemIndex.class).

[0056] Field-configuration association binding: Declare fields for each index type in ConfigManager (such as public ItemIndex ITEM).

[0057] 3. Dynamic instantiation and data loading pipeline Reflection instance creation: According to the mapping table, call the parameterless constructor of the index class corresponding to each configuration file (such as ItemIndex) to create an empty instance.

[0058] 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 from etcd into a memory object.

[0059] Index instance initialization: Taking the Protobuf object as a parameter, call the load(protoData) method of the index instance to complete business customization processing (such as building an in-memory index, cache optimization). If the initialization fails, trigger a fallback mechanism to retain the default configuration and issue an alarm.

[0060] 4. Atomic field injection and state synchronization Thread-safe field replacement: Inject the initialized index instance into the field (such as ITEM) of the ConfigManager through the Java reflection API (such as Field.set()). Use AtomicReference or double-checked locking to ensure the atomicity of replacement in a multi-threaded environment and avoid dirty reads. It should be noted that the present invention introduces an automated configuration loading process based on the reflection mechanism in the service startup phase to build a closed-loop configuration management throughout the life cycle: When the game service is started for the first time, the system automatically obtains the configuration table data corresponding to the key-value pair from etcd, scans the configuration fields in the Java field manager using reflection technology and dynamically parses their index types, and then creates a matching configuration index instance to complete data loading and field replacement. This process transforms the configuration field binding operation that needs to be manually maintained in the traditional solution into an automated runtime behavior, so that multiple service nodes do not need to pre-define the configuration loading logic or manually adjust the code when starting up, which not only eliminates the risk of field type mismatch caused by manual coding omissions, but also ensures that the initial configuration states of all service instances in the distributed environment are strictly consistent; at the same time, this 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 the initialization static loading and dynamic update logics in the traditional solution, and significantly improving the system robustness and operation and maintenance efficiency.

[0061] Further, after loading the configuration table data into the latest configuration index instance, record the version number of the key-value pair in etcd for tracking the update of the configuration table data.

[0062] In the embodiments of this specification, the following specific implementation solutions can be adopted: 1. Cluster state synchronization etcd status tree writing: After recording the version number locally, write the unique identifier (such as IP) of the service instance and the version number to the / status / {service_id} / versions path in etcd to form a cluster-level version snapshot.

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

[0064] Furthermore, before sending change events 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 operators. 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 for the game services to perform hot updates on the game configuration.

[0065] In the embodiments of this specification, referring to Figure 4 the schematic diagram of the process of uploading an Excel file to the etcd shown, the planner can edit the Excel file to achieve the desired function values. The planner submits the Excel file to the svn (Subversion, version control system). The developer pulls the latest Excel file from the svn. The developer can use the conversion tool JavaExcelTools to convert the Excel data into a protobuf byte array, and then store the protobuf byte array in a file to obtain a byte[] file. The etcdctl can be used to upload the byte[] file to the etcd. At the same time, some shell scripts can also be written to perform batch upload operations. When the operator edits some activity data on the admin management background, an Excel file will also be generated. The planner can also use the admin management background to upload the Excel file. The Excel file will continuously perform the operations of converting into a byte[] file and uploading to the etcd inside the admin management background.

[0066] It should be noted that in this technical solution, by constructing a standardized configuration data preprocessing channel, the Excel file edited by the planner is serialized and converted into a highly compatible byte stream via protobuf and persisted to etcd, establishing a dual guarantee of type safety and transmission efficiency at the data source: the strong contract feature of protobuf ensures a strict mapping between the Excel data structure and the Java server-side fields, eliminating parsing errors caused by loose type matching during the conversion of traditional text formats (such as JSON / XML); at the same time, the storage form of the byte stream not only reduces the read and write overhead of etcd, but also provides a unified data interface for the multi-language microservice architecture through the cross-platform support ability of the protocol buffer. The deep integration of this preprocessing mechanism with the distributed key-value storage enables the planner to only need to maintain the Excel file according to the established rules to automatically trigger the subsequent hot update process, transforming the originally manual intervention-dependent configuration release, format verification, version management and other links into a standardized pipeline operation, which not only eliminates online failures caused by human operation errors, but also compresses the full-link time-consuming from configuration modification to online effectiveness of business requirements to the minute level, thus improving the development and operation and maintenance collaboration efficiency while providing solid technical support for game dynamic optimization.

[0067] Further, the key value includes the configuration file name. When loading the latest configuration table data 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; loading the latest configuration file name into the latest configuration index instance. For example, the latest configuration file name can be ItemTable.bytes.

[0068] In the embodiments of this specification, the following specific implementation solutions can be adopted: 1. Interface standardization is bound to file name declaration Unified interface definition: Define the configFileName() abstract method in the Java index interface (IConfigIndex), and force all subclasses to implement this method to return the file name (such as ItemTable.bytes) bound to it. 2. File name dynamic injection process Key value path parsing: Extract the filename field (i.e., ItemTable.bytes) from the key path (such as / config / {group} / ItemTable.bytes) monitored by etcd as the reference value for subsequent verification.

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

[0070] Compare the return value with the filename in the key path. If they are the same, continue loading; otherwise, throw a FileNameMismatchException, terminate the process, and issue an alert.

[0071] 3. Persistence of file name metadata Object status record: In the index instance, build in the fileName attribute. When initializing, inject ItemTable.bytes into this attribute so that the business logic can directly access the file name through the instance (such as for log printing and monitoring reporting).

[0072] It should be noted that in this technical solution, by embedding the configuration file name into the key - value system and deeply binding it to the loading logic of the index instance, a strong verification link between the configuration identifier and the data entity is constructed: when loading the data of the latest configuration table, the system automatically extracts the latest configuration file name contained in it through the configuration index instance, and synchronously injects this name into the latest configuration index instance. This design makes the configuration name no longer rely 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 exceptions caused by misspelled configuration names, residual historical versions, or mismatches in cross - table references in the traditional solution; 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 - scale scanning or fuzzy matching. Thus, on the premise of ensuring the accuracy of configuration loading, it provides high - reliability hot update support for large - scale, multi - configuration - table game systems.

[0073] Furthermore, the key - value further includes a pre - set group name identifier. Based on the group name identifier, determine the game services corresponding to each key - value, so that when the game service realizes the hot update of the corresponding game configuration, it can determine the belonging key - value.

[0074] In the embodiments of this specification, {group} is a server group. For example, the examples corresponding to prod_3.5.12 are: / config / prod_3.5.12 / Item.bytes, / config / prod_3.5.12 / Skill.bytes.

[0075] It should be noted that this technical solution deeply couples distributed configuration management with service group topology by introducing the logical hierarchical dimension of group name identification in the key-value system: during the hot update process, the system dynamically associates the key value with the target game service group based on the group name identification, so that the configuration updates of different functional modules (such as combat system, social system) or business partitions (such as telecommunications area, Netcom area) in the same physical cluster can be accurately isolated and directed. This design breaks through the extensive mode of traditional global broadcast updates and controls the impact scope of configuration changes within the preset service group boundaries, which not only avoids unnecessary resource consumption of irrelevant service nodes due to receiving redundant data, but also prevents systemic risks caused by cross-module configuration pollution due to misoperation; at the same time, the explicit declaration mechanism of group name identification enables operation and maintenance personnel to perform configuration management based on business semantics rather than physical addresses, and automatically inherits group attributes when service instances are dynamically expanded and reduced, thereby achieving seamless adaptation of configuration strategies and infrastructure elasticity, significantly improving the operation and maintenance controllability and fault isolation efficiency of large-scale distributed game architectures.

[0076] Furthermore, the embodiments of the present specification determine the hot update type of each game configuration in the hot update of the corresponding game configurations of the multiple game services; simultaneously trigger the hot update of the 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.

[0077] In the examples of this specification, the following specific implementation schemes can be used: 1. Classification and identification of hot update types Type definition standardization: Core business type: Configurations that directly affect the player's core experience (such as combat values and economic rules) must be enforced immediately.

[0078] 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.

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

[0080] 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).

[0081] 2. Dynamic Recognition of Game Scenarios Scene Perception Engine: Player Behavior Analysis: Real-time collection of player status (such as in battle, in a transaction, in the main city), operation frequency, and current task progress.

[0082] Service Health Monitoring: Determine the node load level through metrics (CPU usage, memory occupancy, request latency), and classify it into high / medium / low load states.

[0083] Scene Tagging: Convert dynamic data into scene tags (such as high_load_battle, idle_social) as the basis for policy decision-making.

[0084] 3. Dynamic Policy Decision-making and Distribution Policy Rule Library: Core Business Type: Takes effect immediately in any scene, but limits the number of concurrent threads under high load (such as single-threaded serial update).

[0085] Resource Dependent Type: Triggers full loading only in low-load scenarios (idle tag), and only loads necessary resources (such as the basic model) under high load.

[0086] Non-critical Type: Delayed for batch update until the player goes offline or the scene changes (such as after the battle ends).

[0087] Policy Priority Arbitration: When there are conflicts in multi-configuration updates, sort by type priority (Core Business Type > Resource Dependent Type > Non-critical Type).

[0088] Within the same priority, sort topologically according to the configuration dependency relationship (such as if Configuration A depends on Configuration B, then update B first).

[0089] 4. Multi-configuration Collaborative Update Execution Transactional Update Coordination: Distributed Lock Control: Use the distributed lock of etcd to ensure the atomicity of multiple configuration updates within the same service group and avoid version crossing.

[0090] Phased Submission: Split high-resource-consuming configurations into two phases: "preloading" (loading data in the background) and "effective switching" (atomically replacing pointers) to reduce main thread blocking.

[0091] Player Transparent Switching: Trigger resource replacement when the player is in a non-interactive period (such as cutscenes, loading screens), and achieve seamless switching through double-buffering technology.

[0092] For configurations with delayed updates, they will take effect automatically when the player triggers the relevant function next time (such as refreshing item descriptions when opening the backpack).

[0093] It should be noted that this technical solution transforms the originally disordered concurrent update requests into a logically self - consistent scheduling sequence: when multiple configurations need to be hot - updated simultaneously, the system first parses the update types of each configuration (such as combat numerical correction, activity rule change, combat scene skill special effect configuration, character equipment appearance configuration, etc.), synchronously captures the current game scene (such as when the player is in a dungeon battle or in the main city for social interaction), and then dynamically generates an update strategy based on the relevance between the type and the scene (such as immediate effect, deferred loading, or batch execution). This mechanism enables key updates such as core combat parameters to take effect silently when the player is in a non - adversarial scene, while interface - type updates dynamically select the execution window according to the scene load. It not only avoids service lags caused by resource contention in the traditional full - volume update mode but also eliminates temporary data contradictions caused by cross - configuration logical coupling, ultimately achieving zero - perception intrusion of multi - configuration hot - updates into the game process, while ensuring business continuity and maintaining the integrity of the player's immersive experience.

[0094] Furthermore, the hot - update types of the game configurations include combat scene skill special effect configuration and character equipment appearance configuration; the game running scenes include combat scenes and non - combat scenes; when determining the update strategies for the hot - updates of multiple game configurations based on the game running scenes and the hot - update types of multiple game configurations, if the game running scene is a combat scene, then perform a hot - update on the character equipment appearance configuration, reduce the running resources of the combat scene skill special effects, and perform a hot - update process on the combat scene skill special effect configuration in the non - combat scene; if the game running scene is a non - combat scene, then perform a hot - update process on both the character equipment appearance configuration and the combat scene skill special effect configuration simultaneously.

[0095] In the embodiments of this specification, the following specific implementation schemes can be adopted: 1. Definition of Configuration Types and Scene Classification Hot - update type identification: Combat scene skill special effect configuration: Core resources affecting real - time combat performance (such as skill particle effects, damage value calculation rules).

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

[0097] Running scene classification: Combat scene: The player is in a combat state (such as dungeon Boss battle, PVP confrontation).

[0098] Non - combat scene: The player is in a non - adversarial environment such as the main city, social interaction, or menu interface.

[0099] 2. Real - time Scene State Perception and Event Triggering Combat scene determination: Player Behavior Monitoring: Dynamically mark players as in combat state through the game event system (such as entering combat, releasing skills).

[0100] Scene Stress Detection: Quantify the combat intensity by combining indicators such as frame rate and network latency (such as high-intensity combo periods, low-intensity movement periods).

[0101] Non-Combat Scene Judgment: When the player exits combat, opens the backpack, or enters the main city, trigger a scene switching event.

[0102] 3. Execution of Scene-Driven Hot Update Strategy Scene: Combat scene; Update of Character Equipment Appearance: Take effect immediately: Preload the new appearance data into the standby memory area through double-buffering technology, and atomically switch the reference pointer to ensure that players can see the new equipment in real time.

[0103] Adjustment of Resource Priority: Reduce the rendering precision of the equipment model (such as LOD level) to free up GPU resources for combat logic.

[0104] Suppression of Skill Special Effect Update: Resource Limitation: Pause the loading of high-consumption special effects (such as full-screen particle effects) and maintain the current special effect version.

[0105] Mark in Delay Queue: Add the skill special effect configuration to be updated to the delay queue and bind it to the "exit combat" event trigger.

[0106] Scene: Non-combat scene; Batch Hot Update Execution: Update of Skill Special Effects: Extract the configuration to be updated from the delay queue, load all resources (such as high-definition particles, physical simulation parameters), and replace the old version.

[0107] Supplementary Update of Appearance Configuration: For models degraded due to resource limitations during combat, restore high-precision rendering and apply the latest configuration.

[0108] Guarantee of Seamless Switching: Complete resource replacement during the scene switching transition period (such as the loading interface) without the player noticing.

[0109] 4. Dynamic Resource Regulation and Abnormal Circuit Breaker Resource Management during Combat: CPU / GPU Quota Allocation: Set resource limits (such as the maximum number of occupied cores) for the skill special effect thread to ensure stable frame rate of combat logic.

[0110] Fallback Solution for Degradation: If the loading of the new appearance configuration fails, automatically roll back to the previous available version to avoid the absence of the character model.

[0111] Fault Tolerance Mechanism during Non - combat Period: Fragmented Loading: Split large - scale skill special effect resources into multiple fragments and load them as needed to prevent sudden memory increase.

[0112] Version Consistency Check: After the update, compare the version number of the skill special effects with the data in the configuration center. When they are inconsistent, trigger a retry.

[0113] It should be noted that this technical solution deeply couples the hot update operation with the real - time experience needs of players by establishing a scenario - sensitive update strategy hierarchical mechanism: in the combat scenario, it preferentially processes the appearance configuration updates with low resource consumption and suspends the skill special effect updates with high computational load. In the non - combat scenario, it opens a full - volume update window, enabling the system to intelligently allocate resources according to the player's situation - avoiding frame rate fluctuations or operation delays caused by the heavy loading of special effect resources at critical moments of combat and efficiently completing the full configuration synchronization using the low - pressure environment in the non - combat stage. Thus, while maintaining the continuity of the player's immersive experience, it achieves the dynamic balance between the hot update operation and the real - time resource occupancy of the game, and finally achieves the dual optimization of business requirement response and user experience guarantee.

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

[0115] In the embodiments of this specification, the following specific implementation schemes can be adopted: 1. Non - combat Scenario Judgment and Event Trigger Item Extraction Scenario Recognition: Player Behavior Monitoring: When the player triggers an item extraction operation (such as opening a treasure chest, interacting with the gacha interface), the system marks the current state as "item extraction process".

[0116] Scene State Persistence: Record the scene label (such as loot_animation) in the player's session data to ensure strong association with the scene for subsequent operations.

[0117] 2. Parallel Hot Update and Special Effect Co - triggering Dual - Configuration Hot Update Execution: Resource Pre - loading: Before the item extraction animation starts, the background pre - loads the update data of the character equipment appearance and skill special effects into the memory buffer.

[0118] Atomic Switching: During the extraction animation playback, make both configurations take effect simultaneously through lock - free pointer replacement (such as double - buffer technology) to ensure that the logic layer is unaware.

[0119] Intervention of Hidden Reward Special Effect: Timing synchronization: At the moment when the hot update is completed (within 1 frame after data replacement, for example), automatically trigger hidden reward special effects (such as full-screen golden light, floating display of rare items), shifting the player's attention from potential lag to visual feedback.

[0120] Dynamic adaptation: Adjust the special effect duration according to 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 clicking to reveal the reward).

[0121] 3. Resource Scheduling and Experience Assurance Update Resource Priority Management: Appearance configuration: Prioritize loading low-precision resources (such as equipment icons, thumbnails) to ensure immediate display.

[0122] Skill special effects: Asynchronously load high-precision resources in the background (such as particle effects, physical simulation data), and delay until the preloading of the combat scene is completed.

[0123] Performance fallback strategy: Degraded rendering: If a frame rate drop is detected during the update process, automatically reduce the special effect image quality (such as reducing the number of particles, disabling physical simulation) to maintain smoothness.

[0124] Timeout fuse: Set the maximum allowable update duration (such as 3 seconds). After the timeout, forcibly interrupt the update and roll back to the previous version, and compensate the player with rewards sent by email.

[0125] It should be noted that by deeply binding the hot update operation with the positive feedback mechanism in the game, at specific interaction nodes in non-combat scenarios (such as item extraction), the system synchronously executes multi-configuration hot updates and triggers hidden reward special effects, enabling players to transform the short update delay into a surprising experience at the perceptual level - when players are focused on the pleasant anticipation of reward acquisition, the background resource loading process of the hot update is cleverly transformed into the carrier of visual special effects, not only completing the imperceptible update by taking advantage of the natural deviation window of the player's mental attention, but also compensating for the potential experience gap brought by technical operations through the immediate delivery of hidden rewards. Thus, while ensuring the timeliness of the hot update, the original technical limitations are transformed into emotional touchpoints for enhancing user retention and activity, realizing the positive cycle enhancement of technical operation and player experience.

[0126] It should be noted that, combined with the above technical features, the following specific technical problems can be further solved: The parameters of the function configuration in game development are all edited by planners using Excel. After the technological evolution, there are few projects that directly load Excel files. Instead, the Excel files are converted into another data form. The options include converting them into code data or pure data forms (JSON / XML, etc.). Converting to code often requires restarting the game server or using the code of a dynamic language to dynamically modify the data. Restarting the service seriously affects the experience of online players. Therefore, game companies often adopt the method of restarting at midnight. However, this method seriously affects the physical health of the execution personnel and the work efficiency of the next day. Using a dynamic language to process configuration data means that logic needs to be written in a dynamic language, and the development efficiency of dynamic languages is not high. It is relatively difficult to determine problems when bugs occur. Using the pure data solution often requires writing an intermediate server by oneself to provide services to other servers. This greatly increases the complexity of the development process and also affects the efficiency of collaborative development due to the downtime and maintenance and release of the intermediate server.

[0127] Therefore, this solution can solve the problem of needing to stop the service for updating and avoid various costs (development cost, communication cost, maintenance cost) caused by the intermediate server. The following is an overview of this solution: This solution is an extensible and low-cost technical solution for game configuration data. The overall structure of this solution includes N (>=1) sets of game services, etcd and its attached tool set. This solution converts the Excel table data into the form of protobuf data, and then uploads the protobuf data to etcd for use by game services. This solution uses the Java language to write game services and uses the reflection mechanism of Java to replace class attributes at runtime to achieve the hot update operation of configuration data.

[0128] Under this solution, the configuration can be updated without restarting the service. The development efficiency and execution efficiency of Java are higher than those of dynamic languages. The decoupling of this solution is very high. etcd runs as an independent service. If there are no security vulnerabilities in this service, it does not need to be maintained and updated. Generally, it will not crash. The byte array of protobuf converted from Excel is always stored in etcd. Whether the game service is started or not, the operation of uploading the configuration table can be executed. The admin service or etcdctl tool for uploading the configuration table does not need to care about the status of the game service.

[0129] In the early development stage, developers can use the etcdctl command line to upload the configuration table. The admin backend project is generally developed in the middle and late stages of the project, which can save the early development cost and verify the rationality of the game play faster. After the admin project is developed and launched, etcdctl can still be considered for debugging the admin project, or as an alternative, it can be used to upload the configuration table when the admin project has problems.

[0130] Etcd is a key-value database. We can make use of the keys, so that one etcd can drive multiple sets of game services. For example, in the format of / config / {group} / filename, by using different identifiers for the group, one etcd can serve multiple sets of game services simultaneously. This approach is more cost-effective for rolling server deployment, debugging, and development. Etcd will assign a version number tag to each key. Each time the value corresponding to the key changes, the version number will be incremented by 1. At the same time, etcd has key monitoring events. The game service monitors the key change events. After the key changes, it will automatically pull the latest key information, and then compare the version numbers. If the version number increases, it will re-pull the configuration data. The development cost and computing cost of this mechanism are relatively small, and it can also avoid errors that may be caused by manual operations through automated operations. Figure 5 The data flow diagram provided for the embodiments of this specification. There are multiple game services, Game Service 1, Game Service 2, and Game Service 3. The game services can be player, platformy, and fight. The planner, operator, and developer 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.

[0131] Furthermore, for the above technical solutions, the embodiments of this specification also provide the following specific implementation plans: When the game service starts, it will first pull the configuration table data content from etcd, which is the content of the previous byte[] file. The game service will use the key in the form of / config / {group} / filename to pull 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 rule should also be adopted in the previous upload step. In the current design, a corresponding Java index type will be written for each file, such as ItemIndex. The role of this class is to be responsible for preprocessing the content of item.bytes. Each previous filename requires a corresponding index type. These index types all need to implement a common Java interface, otherwise they cannot be managed.

[0132] A Java type ConfigManager that manages all index types is required. All index types are fields on ConfigManager, and the following methods are used for loading and hot updating.

[0133] 1. Generate an instance of the index type using reflection.

[0134] 2. Invoke reflection on the protobuf Java type (Excel will also generate proto files, and these proto files can be used to generate protobuf Java types). The purpose is to convert the binary data obtained from etcd into a usable Java object.

[0135] 3. Invoke the initialization method of the instance obtained in the first step, with the result obtained in the second step as the parameter. After successful initialization, record the version number of the current etcd key.

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

[0137] I. Initialization process When the application starts, ConfigManager adopts the singleton pattern to ensure that there is only one configuration manager globally. The initialization process includes the following steps: 1. Automatically discover configuration items: The system uses the reflection mechanism to automatically scan all fields in the ConfigManager class and identify fields that implement the IConfigIndex interface (such as ConfigDressUpIndex, ConfigSceneIndex, ConfigItemIndex, etc.).

[0138] 2. Prepare configuration loading: Store the discovered configuration fields in the allFields list to prepare for subsequent unified loading.

[0139] 3. Set up error handling mechanism: Receive an exception callback function to be used when there is an error in configuration loading.

[0140] 4. Start configuration loading: Load configuration data from ETCD.

[0141] II. Configuration loading process Configuration loading is the core part of the entire system, and the specific process is as follows: 1. Process each configuration item in a loop: The system traverses all the configuration fields discovered previously.

[0142] 2. Create configuration index objects: Create corresponding configuration index instances (such as ConfigItemIndex, etc.) for each configuration field.

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

[0144] 4. Parse the 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.

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

[0146] 6. Set the modification version number: Record the modification version number of the configuration data for tracking configuration updates.

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

[0148] III. Advantages of data preprocessing in improving query efficiency Taking ConfigItemIndex as an example, it shows how data preprocessing improves query efficiency: 1. Build ID mapping: After loading the data, immediately build the mapping relationship from ID to Item object (buildMapById method), making the operation of querying items by ID become an operation with O(1) time complexity, instead of traversing the entire list every time.

[0149] 2. Special Attribute Index: For specific types of items (such as fireworks), the system pre-extracts their special parameters (extParam) and constructs a dedicated mapping (extParamsFireworksMap) to facilitate quick query of special attributes such as the life cycle of fireworks.

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

[0151] 4. Dedicated Query Method: Provide dedicated query methods such as getFireworkLifeTime to directly obtain data from the pre-constructed mapping without the need to parse strings or perform complex calculations at runtime.

[0152] This preprocessing mechanism enables the configuration system to incur a one-time processing cost during loading, but achieve significant performance improvement in all subsequent query operations, especially suitable for scenarios of configuration data that are frequently read and rarely updated.

[0153] It should be noted that this configuration management system solves the problem of configuration data management in application programs through technologies such as automatic discovery and loading of configuration items, data preprocessing, and efficient indexing. It not only simplifies the configuration loading process but also greatly improves the data query efficiency through pre-constructed mapping relationships, while maintaining good scalability and maintainability.

[0154] Figure 6 Schematic diagram of the game service pulling configuration from etcd provided for one or more embodiments of this specification. In the figure, Game Service 1, Game Service 2, and Game Service 3 respectively make requests and receive responses from etcd.

[0155] Figure 7 Schematic diagram of the configuration table data update notification provided for one or more embodiments of this specification. etcd sends key change notifications to Game Service 1, Game Service 2, and Game Service 3.

[0156] Figure 8 Schematic diagram of the structure of a configuration table data hot update device for a game provided for one or more embodiments of this specification, including: a monitoring unit 801, an event initiation unit 802, a determination unit 803, a creation unit 804, and a replacement unit 805.

[0157] The monitoring unit 801 monitors whether the key values in the distributed key-value storage database etcd change during the operation of multiple game services; The event initiation unit 802, if so, initiates a change event to the multiple game services, and the change event includes the latest version number of the key value in etcd and the latest configuration table data; Determination unit 803, 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; Creation unit 804, create a corresponding latest configuration index instance for the latest index type; Replacement unit 805, load the latest configuration table data into the latest configuration index instance, and replace the latest configuration index instance into the specific configuration field, so that the game service can implement the hot update of the corresponding game configuration by using the specific configuration field.

[0158] Figure 9 A schematic structural diagram of a device for hot updating configuration table data of a game provided by one or more embodiments of this specification, including: 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, and the instructions are executed by the at least one processor so that the at least one processor can: During the operation of multiple game services, monitor whether the key-value of the distributed key-value storage database etcd changes; if so, initiate a change event to the multiple game services, the change event including 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 into the specific configuration field, so that the game service can implement the hot update of the corresponding game configuration by using the specific configuration field.

[0159] Each embodiment in this specification is described in a progressive manner. The same or similar parts among the embodiments can be referred to each other, and the differences between each embodiment and other embodiments are emphasized. In particular, for the embodiments of the device, equipment, and non-volatile computer storage medium, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0160] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other, and the differences between each embodiment and other embodiments are emphasized. In particular, for the apparatus embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and reference can be made to the relevant parts of the method embodiments for the relevant content.

[0161] Those of ordinary skill in the art can realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in hardware or software depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0162] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network device and method can be implemented in other ways. For example, the apparatus / network device embodiments described above are merely illustrative. For example, the division of the modules or units is only a logical function division, and there may be other division methods in actual implementation. For example, 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 displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of the devices or units can be in electrical, mechanical or other forms.

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

[0164] In addition, the functional units in each embodiment of this application can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above units can be implemented in the form of hardware or software.

[0165] When the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, to implement all or part of the processes in the above-described embodiment methods of this application, it can also be completed by a computer program instructing relevant hardware. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the steps of the above various method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in the form of source code, object code, executable file, or some intermediate form, etc. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electrical carrier signal, telecommunication signal, and software distribution medium, etc. It should be noted that the content included in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0166] The above-described embodiments are only used to illustrate the technical solutions of this application, rather than to limit them; although this application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the various embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for hot updating configuration table data of a game, characterized in that The method includes: During the operation of multiple game services, listening for whether the key - value in the distributed key - value storage database etcd changes; If so, initiating a change event to multiple said game services, where 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, 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 fields 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 into the specific configuration fields, so that the game service can achieve hot update of the corresponding game configuration by using the specific configuration fields.

2. The method according to claim 1, wherein The method further includes: When multiple said game services are started for the first time, obtaining the corresponding configuration table data in etcd through a preset key - value; Through the reflection mechanism, automatically scanning the configuration fields in the Java field manager to determine the index type of the configuration table data corresponding to the configuration fields; Creating a corresponding configuration index instance for the index type; Loading the configuration table data into the configuration index instance, and replacing the configuration index instance into the relevant configuration fields, so that multiple said game services can achieve the startup of the corresponding game configuration by using the relevant configuration fields.

3. The method according to claim 2, wherein After loading the configuration table data into the configuration index instance, the method further includes: Recording the version number of the key - value in etcd for tracking the update of the configuration table data.

4. The method according to claim 1, wherein Before initiating a change event to multiple said game services, the method further includes: Receiving the latest Excel file edited by an update person; Converting the latest Excel file into a protobuf byte array, and storing the protobuf byte array into a byte[] file; Uploading the byte[] file to etcd to obtain the latest configuration table data for the game service to hot - update the game configuration.

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

6. The method according to claim 5, wherein The key - value further includes a preset group name identifier, and the method further includes: Determining the game services corresponding to each key - value based on the group name identifier, so that the game service can determine the belonging key - value when achieving hot update of the corresponding game configuration.

7. The method according to claim 1, characterized in that, The method further includes: During the hot update of the corresponding game configurations of multiple said game services, determining the hot - update levels of each game configuration; When triggering the hot update of multiple game configurations simultaneously during the operation of multiple game services for a specified user, determining the game operation scenario and the hot - update levels of multiple said game configurations. Determine the update strategies for the hot updates of multiple game configurations based on the game running scenarios and the hot update levels of the multiple game configurations, so that the game service can implement the hot updates of the multiple game configurations based on the update strategies.

8. The method according to claim 7, wherein The game configurations include combat scenario skill special effect configurations and character equipment appearance configurations; the game running scenarios include combat scenarios and non-combat scenarios; The determining of the update strategies for the hot updates of multiple game configurations based on the game running scenarios and the hot update levels of the multiple game configurations includes: If the game running scenario is a combat scenario, perform a hot update on the character equipment appearance configuration, reduce the running resources of the combat scenario skill special effects, and perform a hot update process on the combat scenario skill special effect configurations in the non-combat scenario; If the game running scenario is a non-combat scenario, perform a hot update process on both the character equipment appearance configuration and the combat scenario skill special effect configurations simultaneously.

9. The method according to claim 8, wherein If the non-combat scenario is an item extraction process, the method further includes: Perform a hot update process on both the character equipment appearance configuration and the combat scenario skill special effect configurations simultaneously, and trigger a hidden reward sending special effect during the item extraction process to replace the game delay caused by the hot update process.

10. A device for hot updating configuration table data of a game, characterized in that, Includes: 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, and the instructions are executed by the at least one processor so that the at least one processor can: During the running of multiple game services, monitor whether the key values in the distributed key-value storage database etcd change; If so, initiate a change event to multiple game services, and the change event includes the latest version number of the key values in etcd and the latest configuration table data; If the latest version number is greater than the current version number of the key values 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 fields 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 into the specific configuration fields, so that the game service can implement the hot update of the corresponding game configuration by using the specific configuration fields.

Images