Game configuration management background system and game configuration data processing method executed by same

Abstract

The invention relates to the technical field of game development, in particular to a game configuration management background system and a game configuration data processing method executed by the game configuration management background system, the game configuration management background system comprises a front end subsystem and a rear end subsystem, the front end is based on a Vue framework, and a service configuration module customization unit divides modules according to game service scenes; the business authority control unit designs a routing structure according to modules and realizes role-based authority control; the business oriented interaction unit customizes interface and page interaction rules; the business adaptation tool unit provides a tool function; configuring a synchronization unit design component interaction process; the back end is based on a Spring Boot framework, and a business code generation unit generates an adaptive code according to a scene; the business data storage unit designs a database table structure according to modules; the interface implementation unit driven by the business logic splits corresponding business operation of the interface; the dynamic business rule unit dynamically stores parameters to adjust rules. According to the method, the game configuration management efficiency and safety are improved.

Description

Technical Field

[0001] This application relates to the field of game development technology, and in particular to a game configuration management backend system and a method for processing game configuration data thereon. Background Technology

[0002] With the rapid development of the gaming industry, in-game business scenarios are becoming increasingly diverse. Configuration data (covering item attributes, gift pack benefits, achievement conditions, activity thresholds, etc.) exhibits significant characteristics such as strong business relevance, high update frequency, and prominent personalized needs. However, traditional game configuration management methods have many drawbacks: excessively high coupling between the front-end and back-end, with configuration logic deeply bound to the code, means that when game business scenarios change (such as adding new holiday activities or adjusting item balance), the front-end and back-end code must be modified simultaneously, resulting in extremely low iteration efficiency and difficulty in meeting the needs of rapid business iteration; configuration management lacks business-oriented design, mostly using generalized data storage without customized adaptation for game business scenarios, leading to confusion between configuration items and business logic, and easily causing configuration errors or redundancy.

[0003] Furthermore, traditional configuration centers require service nodes to synchronize configurations via HTTP polling, which may affect the normal operation of game services; code generation and configuration maintenance processes are cumbersome, and traditional configuration centers have low relevance to business operations, with configuration methods being relatively simple and not intuitive; configuration adjustments rely on the intervention of technical personnel, and business personnel cannot operate independently, resulting in high communication costs; permission management is not deeply integrated with business scenarios, and it is impossible to accurately allocate configuration operation permissions based on business roles (such as operations, planning, and development), posing potential risks to business data security. Summary of the Invention

[0004] To overcome the shortcomings of existing technologies, this invention provides a game configuration management backend system and a game configuration data processing method thereof, which improves the efficiency and security of game configuration management.

[0005] A first aspect of this application provides a game configuration management backend system, the system comprising: Front terminal system and rear terminal system; The front-end subsystem is based on the Vue framework and includes a business configuration module customization unit, a business-oriented permission control unit, a business-oriented interaction unit, a business adaptation tool unit, and a configuration synchronization unit. The business configuration module customization unit divides the game's business scenarios into corresponding business configuration modules. The business-oriented permission control unit designs the routing structure according to the business configuration modules and uses permission.ts to implement role-based routing permission control. The business-oriented interaction unit customizes interface interaction rules and page interaction logic according to the business configuration modules, with the interface request parameters and response formats corresponding to the configuration items of the corresponding game business scenario. The business adaptation tool unit provides utility functions corresponding to the game's business scenarios. The configuration synchronization unit designs the page component interaction flow according to the game's business scenarios. The backend subsystem is based on the Spring Boot framework and includes a business logic code generation unit, a business data storage unit, a business logic-driven interface implementation unit, and a dynamic business rule unit. The business logic code generation unit generates adaptive code according to the game's business scenario. The business data storage unit designs the database table structure according to the business configuration module. The business logic-driven interface implementation unit splits interfaces according to the business configuration module's customization unit, with each interface corresponding to a specific game business operation. The dynamic business rule unit dynamically stores business rule parameters through configuration files or a database and adjusts business rules using these parameters.

[0006] In one optional implementation, the game business scenario includes at least one of item configuration, gift pack management, achievement system, and event configuration; the business configuration module includes an item configuration module, a gift pack management module, an achievement system module, and an event configuration module; in the business-oriented permission control unit, the operation role only has operation permissions for the item configuration module and the gift pack management module; the planning role only has operation permissions for the achievement system module and the event configuration module; and the development role has operation permissions for the business configuration module.

[0007] In one optional implementation, the business rule parameters in the dynamic business rule unit include at least three of the following: configuration item upper limit value, business logic conflict judgment condition, configuration effective scope rule, and data verification rule; the configuration file is the application.yml file of the Spring Boot framework, and the database stores the business rule table of the business rule parameters.

[0008] In an optional implementation, the interface interaction rules in the business-oriented interaction unit satisfy the following: the interface request parameters only contain business configuration fields, and the response data includes business status identifiers, business prompt information, and business result data. The business status identifiers include configuration success, verification failure, and data anomaly.

[0009] In an optional implementation, the generation rules for the adaptation code in the business code generation unit are configurable generation rules, which include code output paths, class naming rules, primary key generation strategies, and field mapping rules. The code output paths are divided according to the business configuration modules so that the code files of different business configuration modules are stored independently.

[0010] A second aspect of this application provides a method for processing game configuration data, the method comprising: Based on the user's business role, authorized business configuration modules are allocated and unauthorized modules are blocked through the business-oriented permission control unit; the unauthorized modules are unauthorized business configuration modules. The system receives service configuration data filled in by the user in the authorized service configuration module, and the service configuration data corresponds one-to-one with the configuration items of the corresponding game service. The business configuration data is sent to the back-end subsystem through the business-oriented interaction unit according to the pre-defined interface interaction rules. The interface request carries the business status identifier and configuration parameters. The back-end subsystem obtains the business rule parameters corresponding to the target game service through the dynamic business rule unit, and performs business rule verification on the business configuration data. The business rule verification includes configuration item legality, business logic conflict, and configuration limit verification. The target game service can be any type of game service. If the verification result of the business rule is successful, the business configuration data is stored in the dedicated data table of the corresponding business configuration module through the business data storage unit; if the verification result of the business rule is unsuccessful, response data containing verification failure information is returned. The back-end subsystem returns response data containing a service status identifier, and the front-end subsystem displays the corresponding service feedback information based on the service status identifier. The configuration synchronization unit pushes the business configuration data stored in the dedicated data table to the game server, and receives the synchronization results from the game server and feeds them back to the user, thus completing the closed loop of configuration data processing.

[0011] In one optional implementation, the business rule verification is configured in real time through the dynamic business rule unit; when it is determined to adjust the verification standard of the business rule verification, the business rule parameters in the configuration file or database are modified.

[0012] In one optional implementation, the configuration synchronization unit supports both batch synchronization and single-line synchronization modes; the synchronization result includes three states: synchronization successful, synchronization failed, and synchronization in progress; when the synchronization result is determined to be a synchronization failure, a failure reason prompt and retry function are provided.

[0013] In an optional implementation, before assigning accessible authorized service configuration modules and blocking unauthorized modules through the service-oriented permission control unit based on the user's service role, the method further includes: The business code generation unit receives the business configuration module name and database table name corresponding to the target business configuration module input by the user; the target business configuration module can be any type of business configuration module. The system automatically queries the primary key and structure information of the database tables to generate entity class files, data access interfaces, and data mapping files that match the business configuration module.

[0014] In one optional implementation, the entity class field names in the entity class file are consistent with the business configuration item names; the data access interface includes the query, add, modify, and delete operation methods required by the business configuration module.

[0015] In summary, the game configuration management backend system and the game configuration data processing method implemented by the present application have at least one of the following beneficial effects: 1. The front-end subsystem is built on the Vue framework, with customized business configuration modules. These modules are divided according to the game's business scenarios, ensuring close integration between the front-end configuration and the specific business context, rather than deep binding with the code. When the game's business scenario changes, adjustments are only needed in the corresponding front-end business configuration module, without requiring simultaneous modifications to the back-end code, thus reducing front-end / back-end coupling. Similarly, the back-end subsystem is based on the Spring Boot framework, with a business logic code generation unit generating adaptation code based on the game's business scenarios. This ensures that the back-end code is also generated based on the business scenario, corresponding to the front-end business configuration modules, rather than being deeply coupled with the front-end code. When the business scenario changes, the back-end responds by generating new adaptation code, without requiring large-scale modifications to the original code, further reducing front-end / back-end coupling, improving iteration efficiency, and meeting the needs of rapid business iteration. 2. In the front-end subsystem, the business configuration module customization unit divides business configuration modules according to game business scenarios, providing a business-oriented foundation for configuration management. The business-oriented interaction unit customizes interface interaction rules and page interaction logic according to the business configuration modules. The interface request parameters and response formats correspond to the configuration items of the corresponding game business scenarios, ensuring a clear correspondence between configuration items and business logic and avoiding confusion between configuration items and business logic. In the back-end subsystem, the business data storage unit designs the database table structure according to the business configuration modules, tightly integrating data storage with business scenarios and customizing adaptations for game business scenarios, avoiding configuration errors or redundancy caused by generic data storage. The business logic-driven interface implementation unit splits interfaces according to the business configuration module customization unit, with each interface corresponding to a specific game business operation, ensuring a clear division of business logic at the interface level and enhancing the business orientation of configuration management. 3. In the front-end subsystem, the business-oriented interaction unit customized interface interaction rules, clarifying the interface request parameters and response formats during the query, update, and synchronization processes of configuration data. This ensures a unified standard for data interaction and reduces the occurrence of data inconsistencies. In the back-end subsystem, the business logic-driven interface implementation unit splits interfaces according to business configuration modules. Each interface corresponds to a specific game business operation, ensuring the relevance and standardization of the interfaces. The dynamic business rule unit dynamically stores business rule parameters through configuration files or a database. Adjusting business rules based on these parameters ensures that adjustments are also made within a standardized data interaction process, further guaranteeing the standardization of data interaction and preventing disruptions to the normal operation of the game business. 4. In the front-end subsystem, the business adaptation tool unit provides utility functions corresponding to game business scenarios, reducing the workload of manually writing repetitive code. The business configuration module customization unit divides modules according to business scenarios, allowing configuration adjustments to be made within modules, reducing reliance on technical personnel. Business personnel can perform a certain degree of independent operation in the corresponding business configuration modules, reducing communication costs. In the back-end subsystem, the business code generation unit generates adaptation code according to game business scenarios, avoiding the need to manually write a large amount of repetitive code for the configuration requirements of different business configuration modules, improving code generation efficiency, and reducing the tedium of configuration maintenance. 5. In the front-end subsystem, the business-oriented permission control unit designs a routing structure based on business configuration modules and uses permission.ts to implement role-based routing permission control. This allows for precise allocation of routing permissions for corresponding business configuration modules based on different business roles, deeply integrating permission management with business scenarios and ensuring business data security. Attached Figure Description

[0016] Figure 1This is a schematic diagram of the structure of a game configuration management backend system shown in an embodiment of this application; Figure 2 This is a flowchart illustrating a game configuration data processing method according to an embodiment of this application; Figure 3 This is a schematic diagram of a business package configuration page as shown in an embodiment of this application; Figure 4 This is a flowchart illustrating the architecture and operation of a game configuration management system as shown in an embodiment of this application. Detailed Implementation

[0017] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0018] The following will clearly and completely describe the concept, specific structure, and technical effects of the present invention in conjunction with embodiments and accompanying drawings, so as to fully understand the purpose, features, and effects of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are all within the scope of protection of the present invention. Furthermore, all connections / linkages involved in the patent do not simply refer to direct contact between components, but rather to the ability to form a better connection structure by adding or reducing connecting accessories according to specific implementation conditions. The various technical features in this invention can be combined interactively without contradicting each other.

[0019] Reference Figure 1 The diagram shown is a structural schematic of a game configuration management backend system according to an embodiment of this application. The game configuration management backend system adopts a front-end / back-end separation architecture, including a front-end subsystem and a back-end subsystem, achieving full-process adaptation of configuration management around game business scenarios. The front-end and back-end subsystems are described in detail below.

[0020] The front-end subsystem is based on the Vue framework and includes a business configuration module customization unit, a business-oriented permission control unit, a business-oriented interaction unit, a business adaptation tool unit, and a configuration synchronization unit.

[0021] In the process of game development and management, in order to meet the needs of different business roles to efficiently and accurately complete various core business configuration tasks, improve the efficiency and accuracy of business configuration, and reduce operational complexity, a business-scenario-based front-end subsystem is built based on the Vue framework.

[0022] By rationally dividing business modules, configuring routes, encapsulating interfaces, providing utility functions, and designing configuration interactions, the front-end subsystem is tightly integrated with the core game business scenarios. This ensures that different business roles can conveniently and securely operate authorized business modules, improving the overall business configuration experience. The front-end subsystem, based on the Vue framework, can include a business configuration module customization unit, a business-oriented permission control unit, a business-oriented interaction unit, a business adaptation tool unit, and a configuration synchronization unit.

[0023] The business configuration module customization unit divides the corresponding business configuration modules according to the game business scenario.

[0024] In the game development and management process, to meet the diverse configuration needs of different core game business scenarios, improve the efficiency and accuracy of business configuration, and ensure that page functions are closely aligned with business logic, a customized business configuration module unit was designed and implemented. Based on the core game business scenarios, dedicated configuration modules are precisely divided, ensuring that each module focuses on the specific configuration requirements of its corresponding business. This guarantees that the operation flow of the configuration module is consistent with the actual business operation flow, achieving efficient and accurate business configuration management. These game business scenarios include at least one of the following: item configuration, gift pack management, achievement system, and event configuration.

[0025] Specifically, the business configuration module customization unit plans and divides modules under the project's views folder based on the characteristics and configuration requirements of the business scenario. For example, for the item configuration business scenario, an itemConfig module is planned to be created under the views folder; for the gift pack management business scenario, a gameGift module is planned to be created; the achievement system corresponds to the achievementSystem module; and the activity configuration corresponds to the activityConfig module, etc. Through this planning, it is ensured that each business scenario has an independent and dedicated configuration module corresponding to it.

[0026] For the item configuration module (views / itemConfig), create a new folder named itemConfig under the views folder and create relevant page files within it, such as itemConfig.html (for page display), itemConfig.js (for handling page interaction logic), and itemConfig.css (for defining page styles). This item configuration module focuses on item configuration business, providing functions for entering and editing basic item information (such as name, icon, type, etc.), supporting the setting of item attributes (such as attack power, defense power, health points, etc.), and configuring item acquisition methods (such as quest rewards, store purchase, drops, etc.). All functions revolve around the item configuration business, ensuring a high degree of matching between page functions and item configuration business logic. The operation process is designed according to the actual item configuration business process. The gift pack management module focuses on gift pack management business, providing functions such as gift pack creation, editing, and deletion. Users can set information such as gift pack name, validity period, included items or currency, etc. in this module, and can also modify and delete existing gift packs. For the achievement system module (views / achievementSystem), create an achievementSystem folder under the views folder and create the corresponding page files. This achievement system module focuses on achievement system business, supporting functions such as achievement creation, classification management, and achievement condition setting. Users can define different types of achievements (such as task achievements, exploration achievements, social achievements, etc.), set specific achievement conditions for each achievement (such as completing a specific task, reaching a certain level, number of interactions with friends, etc.), and configure achievement rewards. The page functions are designed entirely around the business needs of the achievement system, ensuring a high degree of adaptation to business logic. For the activity configuration module (views / activityConfig), create an activityConfig folder under the views folder and related page files. This activity configuration module focuses on activity configuration business, providing functions such as activity creation, activity rule setting, activity scheduling, and activity reward configuration. Users can create various types of activities in this module (such as holiday activities, limited-time activities, competitive activities, etc.), set the participation rules, time range, and activity reward content. Next, the various business configuration modules (itemConfig, gameGift, achievementSystem, activityConfig, etc., also known as business modules) are integrated into the overall framework of the project to ensure compatibility and collaborative working capabilities between modules.

[0027] By implementing customized business configuration modules, dedicated configuration modules were successfully created based on the core business scenarios of the game. Each module focuses on the specific configuration requirements of its corresponding business, and the operation process of the configuration modules is consistent with the actual business operation process. This achieved a high degree of matching between page functionality and business logic, improved the efficiency and accuracy of business configuration, reduced the difficulty of user operation, and provided strong support for the game's business management.

[0028] The business-oriented permission control unit designs the routing structure according to the business configuration module and uses permission.ts to implement routing permission control based on business roles.

[0029] In the game business management system, different business roles bear different responsibilities and have different access and operation requirements for various business configuration modules. To ensure system security and data accuracy, and to prevent unauthorized operations, a business-oriented permission control unit is constructed to achieve precise permission management for different business roles. Based on the user's business role (operations, planning, development), the business-oriented permission control unit dynamically assigns access permissions and operation permissions for configuration modules, ensuring that different business roles can only operate authorized business modules, thus guaranteeing the secure and orderly operation of the system.

[0030] Specifically, the business-oriented permission control unit has a carefully designed routing structure in the project's `router / index.ts` file, based on the business configuration modules. This ensures that the route paths and names correspond one-to-one with the game's business scenarios, clearly reflecting each business configuration module. For example: the route path for the item configuration business module is set to ` / itemConfig`, and the name is `ItemConfig`; the route path for the gift pack management business module is ` / gameGift`, and the name is `GameGift`; the route path for the achievement system business module is ` / achievementSystem`, and the name is `AchievementSystem`; and the route path for the activity configuration business module is ` / activityConfig`, and the name is `ActivityConfig`.

[0031] The system comprises three business roles: operations, design, and development. A business-specific permission control unit manages and configures access and operation permissions for each role. For operations roles, the primary responsibility is daily game operations, such as managing items and gift packs. Therefore, operations roles only have access to item configuration and gift pack management routes, and permissions to create, edit, and delete items and gift packs. For design roles, the focus is on game design, including the achievement system and event configuration. Design roles have access to the achievement system and event configuration routes, and permissions to set achievement conditions, plan event rules, and schedule event times. For development roles, the responsibility is system development and maintenance. They have access to all business configuration modules and can perform more advanced operations, such as modifying system configurations and debugging interfaces, to ensure stable system operation and functional expansion.

[0032] Next, implement role-based routing access control through the permission.ts file. The specific steps are as follows: User login and role acquisition: When a user logs into the system, the user's business role information is obtained from the login interface and stored in the browser's local storage (such as localStorage) or Vuex state management for later use.

[0033] Route guard configuration: Configure a global beforeEach route guard in router / index.ts. Before each route hop, check if the user is logged in and their business role. If the user is not logged in, redirect to the login page; if the user is logged in, perform permission verification based on their business role and the target route.

[0034] Permission verification logic: During the permission verification process, the user's business role is retrieved from local storage or Vuex and then compared with the permission requirements of the business module corresponding to the target route. If the user's business role has permission to access the target route, route redirection is allowed; otherwise, redirection is blocked and the user is prompted that they do not have permission to access.

[0035] In addition to route access control, operation access control can be further refined. In the page components of each business configuration module, operation buttons can be dynamically shown or hidden based on the user's business role. For example, in the item configuration page, if the user is an operations role, buttons for creating, editing, and deleting items are displayed; if the user is another role, these buttons are hidden. This can be achieved by using conditional rendering (such as v-if) within the component.

[0036] The business-oriented permission control unit enables dynamic permission allocation based on user business roles. Different business roles can only access and operate authorized business configuration modules within the system, effectively preventing unauthorized operations and ensuring system security and data accuracy. Simultaneously, the clear routing structure and permission control logic improve the system's maintainability and scalability, providing strong support for game business management.

[0037] The business-oriented interaction unit customizes the interface interaction rules and page interaction logic according to the business configuration module. The interface request parameters and response format correspond to the configuration items of the corresponding game business scenario.

[0038] In the game business management system, different business modules have unique operation processes and data interaction requirements. By constructing business-oriented interaction units, interface interaction rules and page interaction logic are customized according to business modules. This customization of interface interaction rules and page interaction logic by business module ensures precise matching between interface request parameters, response formats, and corresponding business configuration items. The page interaction logic closely aligns with the business operation process, improving the system's maintainability, scalability, and the convenience and accuracy of user operations. Specifically, interface request parameters only include business configuration fields; response data includes business status identifiers, business prompts, and business result data; business status identifiers include configuration success, verification failure, and data anomaly.

[0039] Specifically, each business module has independent business logic and data structure. For example, the item configuration module involves configuration items such as item name, attributes, and acquisition methods; the gift pack management module contains configuration information such as gift pack name, contents, and validity period. In the project's `api` folder, interface files are split according to business modules. For example, `itemConfig.js` is created to manage item configuration-related interfaces, `gameGift.js` handles gift pack management-related interfaces, `achievementSystem.js` handles achievement system-related interface interactions, and `activityConfig.js` handles activity configuration interface requests. This ensures a one-to-one correspondence between interface files and business modules, facilitating development and maintenance. In each interface file, the defined functions are closely related to specific business operations. For example, in `itemConfig.js`, the `queryItemConfig` function is defined to query item configuration information, the `addItem` function to add item configurations, the `updateItem` function to modify item configurations, and the `deleteItem` function to delete item configurations. The `gameGift.js` file contains functions like `queryGameGift` to retrieve gift pack information and `addGameGift` to add gift pack rules, making the functionality of the API functions clear and easy for developers to understand and use. Furthermore, the API's request parameters and response formats are strictly designed based on business scenarios. Taking the `addItem` API in `itemConfig.js` as an example, it only accepts parameters related to items, such as the item name (`itemName`), attributes (which may include specific attribute values ​​like attack power and defense power), and acquisition method (`acquireWay`, such as quest rewards or store purchases). The response format is also customized according to business needs, for example, returning the unique identifier of the newly added item (`itemId`) and creation time (`createTime`).

[0040] Next, the page layout was designed according to the business operation process, ensuring a close correspondence between page elements and operation steps. During page interactions, operation results were promptly fed back and kept synchronized with the business status. For example, in the item configuration page, buttons and input boxes were arranged sequentially according to the operation order of query, add, edit, and delete, referencing... Figure 3As shown in the diagram. The query area contains query conditions and a query button; the add area provides input boxes for item name, attributes, and acquisition method, as well as a submit button; the edit area dynamically displays item information based on the query results and provides editing functionality; and the delete area provides a confirmation prompt and a button for deletion. When a user clicks the add item button, the page displays a loading status, waiting for the API to return the result. If the addition is successful, the page refreshes the item list, displays the newly added item information, and provides a success message; if the addition fails, the page displays an error message, prompting the user to try again.

[0041] The business adaptation tool unit provides tool functions corresponding to the game business scenarios.

[0042] In the development of game applications, there are numerous operations closely related to business logic, such as validating business configuration items, performing calculations based on specific business rules, and formatting business data. By constructing a business adaptation tool unit, utility functions tailored to the game's business logic are provided. This tool unit creates a series of utility functions in the utils folder that are aligned with the game's business logic, enabling accurate validation of business configuration items, precise calculation of business rules, and effective formatting of business data. This improves code reusability and maintainability, reduces the complexity of business logic processing, and ensures the efficient and stable operation of the game application.

[0043] Specifically, create a `utils` folder in the project root directory to store all utility functions adapted for various business applications. Further subdivide the `utils` folder into files based on the function categories of these utility functions. For example, create a `validate.ts` file to store functions related to business configuration item validation, and an `index.js` file to store other business utility functions such as business rule calculation and business data formatting. In the `validate.ts` file, implement the configuration item validation logic closely related to the game's business, including item attribute validity validation and gift pack benefit conflict detection. Additionally, in the `index.js` file, implement utility functions for business rule calculation and business data formatting, including achievement condition calculation, activity time range judgment, and business data formatting (e.g., date formatting). In other business modules, these utility functions can be used by importing them. For example, in the business module related to item configuration, the `validateItemAttributes` function is used to validate item attributes.

[0044] The business adaptation tool unit successfully created a series of utility functions tailored to the game's business logic in the utils folder. These functions accurately validate business configuration items, precisely calculate according to business rules, and effectively format business data. This improves code reusability and maintainability, and reduces errors and redundant code in business logic processing. Furthermore, the clear folder structure and function naming facilitate developers in quickly finding and using the required utility functions, improving development efficiency and the overall quality of the system.

[0045] The configuration synchronization unit designs the page component interaction process according to the game business scenario.

[0046] In the operation of game business, the timely updating and synchronization of business configuration data is crucial for the normal operation of the game and the user experience. By building a configuration synchronization unit, it is necessary not only to synchronize business configuration data to the game server in real time to ensure that configuration changes take effect quickly, but also to design page component interaction processes that fit the business operation flow according to the game business scenario, reduce operational redundancy, and improve the configuration efficiency of business personnel. Specifically, the configuration synchronization unit realizes the real-time synchronization function of business configuration data, ensuring that configuration changes take effect in a short time and guaranteeing the accurate execution of game business logic; and designs page component interaction processes according to different game business scenarios, enabling business personnel to complete configuration operations in an intuitive and convenient manner, improving configuration efficiency and accuracy; at the same time, it provides a configuration preview function, allowing business personnel to see the configuration effect in advance before submitting and saving the configuration, avoiding game failures caused by configuration errors.

[0047] Specifically, the configuration synchronization unit mainly consists of three parts: a configuration management backend, a synchronization service interface, and a game server. The configuration management backend provides the interactive interface for business users to perform configuration operations. It receives input from business users, validates and processes the configuration data, and sends valid configuration data to the synchronization service interface. The synchronization service interface acts as a bridge between the configuration management backend and the game server, receiving configuration data from the configuration management backend and forwarding it to the game server. It also handles errors and exceptions during the synchronization process, ensuring the reliability of data synchronization. The game server receives the configuration data from the synchronization service interface and performs corresponding business logic processing based on the configuration data, enabling configuration changes to take effect quickly.

[0048] In this embodiment, an item configuration scenario is used as an example. On the item configuration page, an attribute configuration form is designed, including basic attributes such as item name and attack power, and special attribute fields such as critical hit rate. Each field has a corresponding input box or selection box for business personnel to fill in values. The system will verify the input values ​​in real time; for example, the attack power must be between 0 and 1000, and prompts for correction if it does not meet the rules. Below the form is an effective range selection area, providing radio buttons or drop-down menus to select the effective range, such as the entire server, a specific server, or a specific player group. When selecting a specific player group, further filtering conditions such as player level range must be entered. The system will perform corresponding logical processing based on the selection, such as verifying the validity of the specific server ID and checking the rationality of the player filtering conditions. Below that is a preview button and a display area. Clicking the preview button will generate a preview effect of the item in the game simulation environment according to the configuration, including appearance, attribute values, and usage effect demonstration, and display it. If the effect does not meet expectations, it can be returned to modify and previewed again. Below the preview area is a submit and save button. Once the business personnel confirm that the preview is correct, they click the button. The system first performs a final check on the data's integrity and validity before sending the data to the synchronization service interface, which then forwards it to the game server. The game server processes the business logic to make the item configuration take effect quickly, and the system simultaneously displays a successful submission notification to the business personnel.

[0049] By configuring a synchronization unit, a page component interaction flow was designed to fit the business operation process based on the game's business scenarios, realizing the real-time synchronization of business configuration data. Business personnel can complete business operations such as item configuration and event configuration according to an intuitive and convenient process, reducing operational redundancy and improving configuration efficiency and accuracy. At the same time, the configuration preview function allows business personnel to see the configuration effect in advance, avoiding game failures caused by configuration errors and ensuring the stable operation of the game business.

[0050] The back-end subsystem is based on the Spring Boot framework and includes a business code generation unit, a business data storage unit, a business logic-driven interface implementation unit, and a dynamic business rule unit.

[0051] In this embodiment of the application, a backend subsystem based on the Spring Boot framework and driven by business logic is constructed. This backend subsystem has functions such as business code generation, business-focused database design, business logic-driven interface implementation, and dynamic business adaptation mechanism, so as to improve development efficiency, ensure the consistency of data and business logic, ensure that interface functions meet business requirements, and be able to flexibly respond to business changes.

[0052] The business-oriented code generation unit generates adaptation code according to the game business scenario.

[0053] In game development, different business scenarios involve different business modules, each with its own database table structure and specific business configuration items. Building a business-oriented code generation unit can automatically generate adaptable code based on the game's business scenarios, which is crucial for improving development efficiency, ensuring code quality, and enhancing system maintainability. This unit supports inputting the game's business module name and corresponding database table name, automatically generating entity classes, Mapper interfaces, and XML files that match the module. It ensures that the generated code fields accurately map to the business configuration items, adapting to business requirements without additional modifications. This improves development efficiency, reduces human error, and ensures the generated code conforms to a unified coding style and standards, facilitating subsequent maintenance and expansion.

[0054] Specifically, a Java class named `MyBatisGenerator` is created as the core utility class for business logic code generation. This class encapsulates the main logic of code generation, including reading input parameters, connecting to the database, parsing table structures, and generating various code files. To meet the requirement of configurable generation rules in the business logic code generation unit, relevant configurable items are set in the `MyBatisGenerator` class, including code output path, class naming rules, primary key generation strategy, and field mapping rules. The code output path is divided according to the business configuration module; for example, a separate output folder path is set for the "itemConfig" business module to ensure that code files from different business configuration modules are stored independently. Class naming rules can be predefined, such as generating class names based on a combination of business module names and table names. Primary key generation strategies can be configured, such as auto-incrementing, UUID, etc. Field mapping rules can convert underscore names in database tables to camelCase names in Java classes, etc. The `MyBatisGenerator` class defines methods that can receive two key input parameters via command-line arguments, configuration files, or a user interface: the business module name (e.g., "itemConfig" or "gameGift") and the corresponding database table name (e.g., `ItemConfig` for item configuration, `game_gift` for gift configuration). A connection to the database can be established using JDBC or a connection pool (e.g., HikariCP). Database connection information, including the database driver, URL, username, and password, is configured in the `MyBatisGenerator` class. The `DatabaseMetaData` interface or a third-party library (e.g., Apache Commons DbUtils) is used to parse the table structure and obtain metadata information for the specified database table, including column names, data types, and nullability. Based on the parsed table structure information, entity classes corresponding to the business module are generated. Field names in the entity classes are mapped to column names in the database table (e.g., converting underscore names to camelCase), and field types are converted to corresponding Java types based on the database data type. Generate a Mapper interface corresponding to the entity class, defining commonly used data access methods such as querying, inserting, updating, and deleting by primary key. The interface method names follow certain naming conventions for ease of understanding and use. Also generate an XML file corresponding to the Mapper interface for configuring SQL statements. The SQL statements in the XML file correspond one-to-one with the methods in the Mapper interface, implementing the specific logic for data access.Next, in the main method of the MyBatisGenerator class, the above code generation methods are called in sequence to complete the generation of entity classes, Mapper interfaces, and XML files.

[0055] The business data storage unit is designed with a database table structure according to the business configuration module.

[0056] In game business systems, to ensure that data storage is closely aligned with business logic and efficiently supports various game business operations, the business data storage unit needs to carefully design its database table structure based on the business modules. By designing the database table structure independently for each business module, ensuring that each business module corresponds to a unique data table, and that each data table field corresponds one-to-one with the business configuration item, a business-focused database design is achieved, improving system maintainability and data processing accuracy.

[0057] When constructing business data storage units, the principle of designing database table structures according to business configuration modules is strictly followed to ensure that data storage is closely aligned with business logic. Specifically, a comprehensive and detailed analysis of the business processes involved in the system is conducted to clarify the boundaries and functions of each business module. For example, in an e-commerce system, core business modules such as product management, order processing, and user management can be identified. Each business module has unique business logic and configuration items, which will serve as the key basis for subsequent database table structure design. For each identified business module, a corresponding data table is designed independently. Taking the product management business module as an example, a data table named PackageGoodsCfg is designed specifically to store data related to product configuration. This independent design approach helps avoid confusion and interference between data from different business modules, improving the clarity and maintainability of data management. When designing data table fields, it is ensured that each field accurately maps to a business configuration item. Taking the PackageGoodsCfg table as an example, it contains multiple fields closely related to product business, ensuring that each field in the data table corresponds one-to-one with a business configuration item, guaranteeing that data storage accurately reflects business logic and facilitating subsequent querying, analysis, and processing of business data. GoodsName (Item Name): This field stores the name information of the product, which directly corresponds to the basic attribute configuration of the product in the business.

[0058] GoodsType: This field records the type of product, such as electronic products or clothing. It is an important configuration item for classifying and managing products in business operations.

[0059] ... (Other fields can be listed based on the actual business configuration items).

[0060] Next, ensure that each business module corresponds to only one data table. This avoids situations where data from one business module is scattered across multiple tables, and also prevents data from multiple business modules from being mixed in the same table. This helps to establish a clear data model, simplifies data access and operation logic, and improves system performance and stability. For example, the order processing business module corresponds to the OrderInfo table, and the user management business module corresponds to the UserInfo table. These tables are independent of each other but are related through specific business relationships. After completing the database table structure design, a comprehensive verification process is conducted. By simulating real-world business scenarios, operations such as inserting, updating, deleting, and querying data tables are performed to check whether the data storage is accurate and can meet the needs of the business logic. Simultaneously, based on the issues discovered during verification, the table structure is optimized and adjusted, such as adding or deleting fields or modifying field types, to ensure that the database table structure perfectly adapts to the business configuration modules, providing solid data support for the smooth operation of the business.

[0061] The business data storage unit enables the scientific and rational design of database table structures according to business configuration modules, achieving a high degree of consistency between data storage and business logic, and improving the overall performance and maintainability of the system.

[0062] The interface implementation unit driven by the business logic is split into interfaces according to the business configuration module customization unit, and each interface corresponds to a specific game business operation.

[0063] Among them, specific game business operations refer to configuration behaviors that are directly related to the core business scenarios of the game and have clear business objectives, including but not limited to the following types: Item configuration operations: such as querying the item attribute list (queryItemList), adding item configurations (addItemConfig), modifying the scope of item application (updateItemScope), etc., corresponding to the business requirements of the front-end item configuration page (views / itemConfig); Gift pack management operations include creating gift pack rules (createGiftPackage), validating gift pack benefit conflicts (validateGiftBenefits), and deleting expired gift packs (removeExpiredGift), which correspond to the business process of the front-end gift pack configuration page (views / gameGift). Achievement system operations: such as calculating achievement conditions, modifying achievement descriptions, and modifying achievement level configurations, which serve the interaction logic of the achievement configuration page; Activity configuration operations, such as validating the activity time range (validateActivityTime), triggering activity status changes (updateActivityStatus), and batch synchronizing activity data (batchSyncActivity), meet the dynamic configuration requirements of the activity management page.

[0064] When constructing business logic-driven interface implementation units, interfaces are split according to customized units based on business configuration modules to ensure that each interface accurately corresponds to a specific game business operation. Specifically, independent interface units are customized for each business configuration module. For example, the ItemConfigController class corresponding to api / itemConfig.js provides interfaces such as queryItemList (query item configuration) and addItemConfig (add item configuration). The interfaces integrate business rule validation (such as item attribute limit validation and validity judgment of the effective scope) to ensure that the configuration data conforms to the business logic. In addition, the split interfaces can be fully tested to simulate various game business scenarios, verify the correctness of the interface functions and the effectiveness of business rule validation, and ensure that the interfaces can stably and accurately support the game business.

[0065] The dynamic business rule unit dynamically stores business rule parameters through configuration files or databases, and adjusts business rules through these parameters.

[0066] When building flexible and adaptable business systems, dynamic business rule units dynamically store business rule parameters through configuration files or databases, and flexibly adjust business rules based on these parameters. Specifically, a configuration file or database is chosen as the storage medium for business rule parameters. For business scenarios with relatively fixed rules and low change frequency, the application.yml file of the Spring Boot framework can be used as the configuration file, such as a JSON or XML format file, to store business rule parameters in a structured manner. These business rule parameters include at least three of the following: configuration item upper limit values, business logic conflict judgment conditions, configuration effective scope rules, and data validation rules. For example, when defining the upper limit rule for item attributes, parameters like {"max_attack": 1000, "max_defense": 800} can be set in the configuration file, representing the upper limit values ​​for attack power and defense power, respectively. For businesses with complex rules, frequent changes, and the need for persistent storage, a database is a better choice. A dedicated business rule table, such as BusinessRuleTable, is created, containing fields such as rule name, rule parameters, and effective time to store rule parameters for different businesses. When the system starts, the dynamic business rule unit reads business rule parameters from the selected storage location. If a configuration file is used, the file content is read through the corresponding file parsing library and converted into a data structure that the system can recognize. If a database is used, a query statement is executed to retrieve the rule parameter records and encapsulates them into objects. When business changes occur, no code modification is required; the business rules are dynamically adjusted simply by modifying the business rule parameters in the configuration file or database. Furthermore, to ensure the accuracy and stability of business rule adjustments, comprehensive verification testing is performed after parameter modifications. Various business scenarios are simulated to check whether the system correctly executes business operations according to the new rule parameters. Simultaneously, a monitoring mechanism is established to monitor the execution of business rules in real time. Once an anomaly is detected, an alert is issued promptly and relevant logs are recorded to quickly locate and resolve problems, ensuring the normal operation of the business.

[0067] Compared to existing game configuration management methods, which suffer from problems such as high coupling between the front-end and back-end, lack of business orientation in configuration management, non-standard data interaction, cumbersome code generation, and disconnect between permission management and business, this application achieves deep adaptation of configuration management to game business scenarios through the coupling of front-end subsystems and back-end subsystems, supporting dynamic configuration adjustment and efficient maintenance driven by business.

[0068] Reference Figure 2 The diagram shown is a flowchart illustrating a game configuration data processing method according to an embodiment of this application. The game configuration data processing method includes the following steps.

[0069] S21, based on the user's business role, allocates accessible authorized business configuration modules and blocks unauthorized modules through the business-oriented permission control unit.

[0070] The unauthorized module is an unauthorized business configuration module.

[0071] When the user selects / inputs a business role, the front-end redirects. Using the permission.ts file in the business permission control unit, based on the user's business role (e.g., operations, planning, etc.) and the pre-defined role-module permission mapping, a list of accessible business routes for that user is dynamically generated. The pre-defined role-module permission mapping means that the operations role only has access to the item configuration module and the gift pack management module; the planning role only has access to the achievement system module and the activity configuration module; and the development role has access to the business configuration module.

[0072] At the same time, the business-oriented permission control unit can also block unauthorized business configuration modules, preventing users from seeing or accessing the entry points of these modules and ensuring that users can only operate within their authorized scope.

[0073] S22, Receive service configuration data filled in by the user in the authorized service configuration module.

[0074] The business configuration data corresponds one-to-one with the configuration items of the corresponding game business. Users fill in the business configuration data according to their actual business needs on the authorized business configuration module page. This business configuration data corresponds one-to-one with the configuration items of the corresponding game business. For example, in the item configuration module, users need to fill in specific information such as item name, item type, and item attributes to ensure that the entered data accurately reflects the configuration requirements of the game business.

[0075] S23, the business configuration data is sent to the back-end subsystem through the business-oriented interaction unit according to the pre-customized interface interaction rules. The interface request carries the business status identifier and configuration parameters.

[0076] After the user completes and submits the business configuration data, the business-oriented interaction unit encapsulates this data into an interface request and sends it to the backend subsystem according to pre-defined interface interaction rules. The interface request carries a business status identifier (including configuration success, validation failure, and data anomaly) and specific business configuration parameters so that the backend can accurately identify and process the request. For example, the frontend sends the request by calling the corresponding business module's interface function, such as the `editGift` interface function in `api / gameGift.js`, with the entered business configuration data as the request parameter.

[0077] S24, the back-end subsystem obtains the business rule parameters corresponding to the target game business through the dynamic business rule unit, and performs business rule verification on the business configuration data; The business rule verification includes verification of configuration item validity, business logic conflicts, and configuration limit; the target game business can be any type of game business.

[0078] After receiving the interface request, the backend subsystem retrieves the business rule parameters corresponding to the target game business from the configuration file or database. These parameters include configuration item validity rules (such as item name length limits), business logic conflict rules (such as duplicate gift pack benefits), and configuration limit rules (such as item attribute values ​​not exceeding a set limit). Then, business rule validation is performed on the business configuration data based on these rules, including configuration item validity, business logic conflict checks, and configuration limit checks. For example, when validating gift pack configurations, it checks whether gift pack benefits are duplicated and whether the effective time is reasonable.

[0079] In some embodiments, business rule verification is based on the real-time configuration of dynamic business rule units. If the verification criteria for business rule verification need to be adjusted, it can be achieved by modifying the business rule parameters in the configuration file or database before step S14 above, without restarting the system or modifying the code.

[0080] S25, if the verification result of the business rule verification is that the verification passes, the business configuration data is stored in the dedicated data table of the corresponding business configuration module through the business data storage unit; if the verification result of the business rule verification is that the verification fails, response data containing verification failure information is returned.

[0081] If the business rule validation passes, the business data storage unit stores the business configuration data in the dedicated data table of the corresponding business configuration module. For example, for the "Item Configuration" business, the data will be stored in the ItemConfig table; for the "Activity Configuration" business, the data will be stored in the activity_config table. If the validation fails, the backend subsystem will return response data containing validation failure information, such as prompts like "Gift pack benefits conflict" or "Item attribute value exceeds the limit," so that users can understand the problem and make corrections.

[0082] S26, the back-end subsystem returns response data containing a service status identifier, and the front-end subsystem displays the corresponding service feedback information based on the service status identifier.

[0083] After the backend subsystem returns response data containing a business status identifier, the frontend subsystem displays the corresponding business feedback information based on this identifier. If the business status identifier is "Configuration Successful," the frontend will display a success message; if the identifier is "Verification Failed," the frontend will highlight the conflicting fields based on the specific failure information returned, making it easier for users to quickly locate and resolve problems, thus completing the business configuration loop.

[0084] S27, the configuration synchronization unit pushes the business configuration data stored in the dedicated data table to the game server, and receives the synchronization result from the game server and feeds it back to the user, so as to complete the configuration data processing closed loop.

[0085] To ensure the game's operational needs can be adjusted in real time, the configuration synchronization unit pushes the business configuration data stored in a dedicated data table to the game server. The push method can be either scheduled synchronization or real-time triggered synchronization, depending on the business requirements. Simultaneously, the configuration synchronization unit receives the synchronization results from the game server and sends the results back to the user, allowing them to understand whether the configuration data has been successfully synchronized to the game server, thus completing the entire configuration data processing loop.

[0086] In some embodiments, the configuration synchronization process supports two modes: batch synchronization and single synchronization. The synchronization result includes three states: synchronization successful, synchronization failed, and synchronization in progress. When synchronization fails, the failure reason prompt and retry function are provided.

[0087] In an optional implementation, before assigning accessible authorized service configuration modules and blocking unauthorized modules through the service-oriented permission control unit based on the user's service role, the method further includes: The business code generation unit receives the business configuration module name and database table name corresponding to the target business configuration module input by the user; the target business configuration module can be any type of business configuration module. The system automatically queries the primary key and structure information of the database tables to generate entity class files, data access interfaces, and data mapping files that match the business configuration module.

[0088] In some embodiments, before performing step S21 above, business module initialization also needs to be performed. Specifically, the business code generation unit receives the target business configuration module name (e.g., "Gift Management") and the corresponding database table name (e.g., "GameGiftConfig") input by the user, and automatically queries the structure information of the database table, including primary key fields (e.g., gift_id), non-null fields, field data types (e.g., VARCHAR / INT), and field comments. Based on the parsed metadata, a predefined code template is dynamically populated to generate the following three types of files: Entity class file: Generates Java / C# entity classes that map to the table structure (e.g., GameGiftEntity.java), including field declarations and ORM annotations (e.g., @Column(name="gift_name")). Data access interface: Generates an interface file containing CRUD methods (e.g., IGameGiftDao.java), with method signatures carrying pagination parameters (e.g., List). <gamegiftentity>queryByPage(int page, int size)); Data mapping file: Generates MyBatis / Hibernate XML mapping file (such as GameGiftMapper.xml), defining the mapping relationship between SQL statements and entity attributes.

[0089] The generated entity class field names are consistent with the business configuration item names, and the data access interface includes the query, add, modify, and delete operation methods required by the business module, which can adapt to the basic operations of the business configuration data without additional coding.

[0090] Perform static checks on the generated code, including: field type compatibility with database types (e.g., avoid mapping VARCHAR to Integer); primary key generation strategy verification (e.g., auto-incrementing primary keys must be annotated with @GeneratedValue); and interface method naming convention verification (e.g., must start with "query / insert / update / delete").

[0091] Next, the verified code files are automatically packaged into JAR / DLL and pushed to the code repository branch of the target business configuration module (e.g., feature / gift-config-v1.2); the CI / CD pipeline is triggered to execute unit tests, and the test cases cover the generated CRUD interfaces and data mapping logic; the target business configuration module directly calls the generated entity classes and data access interfaces to complete the CRUD operations of configuration data, without the need to manually write data layer code, and can be directly used for the configuration data processing of this business module.

[0092] Reference Figure 4 The diagram shown is an architectural flowchart of a game configuration management system according to an embodiment of this application. It combines Spring Boot, Vue and microservice architecture to efficiently manage and synchronize game configuration data.

[0093] In some embodiments, the system components include a game configuration management system, a ctrl server (control server), a con server (routing gateway), a game server cluster, and a db server (unified database operation layer). The game configuration management system, developed based on Spring Boot and Vue, is operated by operations / planning personnel and is used to manage game configurations (such as items, gift packs, achievements, etc.). The ctrl server (control server) manages the game servers and has notification functions, primarily handling configuration update notifications and refresh commands. The con server (routing gateway) serves as the entry point for player requests, handling only routing and not connecting to the ctrl server, forwarding player requests to the appropriate game server. The game server cluster consists of multiple game servers and is responsible for handling the actual game logic, pulling the latest configuration data from the db server. The db server (unified database operation layer) is responsible for database read and write operations, storing and managing game configuration data.

[0094] Operations / planning personnel perform configuration operations (such as adding, modifying, or deleting items, gift packs, achievements, etc.) through the game configuration management system. The game configuration management system writes or updates the configuration data to the database server. The game configuration management system sends a configuration update notification (with a change identifier) ​​to the Ctrl server. After receiving the notification, the Ctrl server broadcasts a "refresh configuration" command to all game servers (batch distribution). After receiving the command, the game servers pull the latest configuration data from the database server and complete the configuration update.

[0095] The player sends a game request. The request first reaches the con server, which forwards it to the appropriate game server according to routing rules. The game server processes the player request using the latest configuration data obtained from the db server and returns the processing result to the player.

[0096] Through the aforementioned game configuration management system, operations / planning personnel can easily perform configuration operations. The system automatically synchronizes configuration data to various game servers, ensuring consistency and timeliness. Adopting a microservice architecture, each service is deployed independently, allowing for flexible expansion of the game server cluster based on business needs, thus improving system processing capacity. The Ctrl server centrally manages configuration update notifications and refresh commands, ensuring the reliability and stability of configuration updates. Simultaneously, the Con server acts as a routing gateway, centrally managing and forwarding player requests, enhancing system security.

[0097] Compared to existing technologies, this application adopts a business-driven system architecture, deeply adapting configuration management to game business scenarios. The clear division of business modules and the closely aligned operation processes with actual business needs effectively reduce operational costs for business personnel and significantly improve configuration management efficiency. Furthermore, it supports business-driven dynamic configuration adjustments, leveraging backend dynamic rule configurations or database field modifications to flexibly adapt to business changes without altering frontend or backend code, meeting the rapid iteration needs of game businesses while reducing system maintenance costs. Simultaneously, the business-oriented interface design and data interaction processes effectively ensure the accuracy and consistency of configuration data, significantly reducing errors caused by mismatches between configuration and business logic, and guaranteeing the normal operation of game businesses. It possesses a modular code generation function, enabling rapid generation of adaptable code for different business scenarios, greatly reducing repetitive coding workload, improving development efficiency, and shortening the launch cycle of new business modules. Finally, it constructs a business role-based permission management mechanism, achieving precise matching between configuration permissions and business responsibilities, effectively preventing unauthorized roles from operating core business configurations and enhancing the security of business data.

[0098] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0099] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0100] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.< / gamegiftentity>

Claims

1. A game configuration management backend system, characterized in that, The system includes: Front terminal system and rear terminal system; The front-end subsystem is based on the Vue framework and includes a business configuration module customization unit, a business-oriented permission control unit, a business-oriented interaction unit, a business adaptation tool unit, and a configuration synchronization unit. The business configuration module customization unit divides the game's business scenarios into corresponding business configuration modules. The business-oriented permission control unit designs the routing structure according to the business configuration modules and uses permission.ts to implement role-based routing permission control. The business-oriented interaction unit customizes interface interaction rules and page interaction logic according to the business configuration modules, with the interface request parameters and response formats corresponding to the configuration items of the corresponding game business scenario. The business adaptation tool unit provides utility functions corresponding to the game's business scenarios. The configuration synchronization unit designs the page component interaction flow according to the game's business scenarios. The backend subsystem is based on the Spring Boot framework and includes a business logic code generation unit, a business data storage unit, a business logic-driven interface implementation unit, and a dynamic business rule unit. The business logic code generation unit generates adaptive code according to the game's business scenario. The business data storage unit designs the database table structure according to the business configuration module. The business logic-driven interface implementation unit splits interfaces according to the business configuration module's customization unit, with each interface corresponding to a specific game business operation. The dynamic business rule unit dynamically stores business rule parameters through configuration files or a database and adjusts business rules using these parameters.

2. The game configuration management backend system according to claim 1, characterized in that, The game business scenarios include at least one of item configuration, gift pack management, achievement system, and event configuration; the business configuration modules include an item configuration module, a gift pack management module, an achievement system module, and an event configuration module; in the business-oriented permission control unit, the operation role only has operation permissions for the item configuration module and the gift pack management module; the planning role only has operation permissions for the achievement system module and the event configuration module; The development role has the operation permissions for the aforementioned business configuration module.

3. The game configuration management backend system according to claim 1, characterized in that, The business rule parameters in the dynamic business rule unit include at least three of the following: configuration item upper limit value, business logic conflict judgment condition, configuration effective scope rule, and data validation rule; the configuration file is the application.yml file of the Spring Boot framework, and the database stores the business rule table of the business rule parameters.

4. The game configuration management backend system according to claim 1, characterized in that, The interface interaction rules in the business-oriented interaction unit satisfy the requirement that the interface request parameters only contain business configuration fields, and the response data includes business status identifiers, business prompt information, and business result data. The business status identifiers include configuration success, verification failure, and data anomaly.

5. The game configuration management backend system according to claim 1, characterized in that, The adaptation code generation rules in the business code generation unit are configurable generation rules, which include code output paths, class naming rules, primary key generation strategies, and field mapping rules. The code output paths are divided according to the business configuration modules so that the code files of different business configuration modules are stored independently.

6. A method for processing game configuration data, characterized in that, The method, applied to the game configuration management backend system according to any one of claims 1 to 5, comprises: Based on the user's business role, authorized business configuration modules are allocated and unauthorized modules are blocked through the business-oriented permission control unit; the unauthorized modules are unauthorized business configuration modules. The system receives service configuration data filled in by the user in the authorized service configuration module, and the service configuration data corresponds one-to-one with the configuration items of the corresponding game service. The business configuration data is sent to the back-end subsystem through the business-oriented interaction unit according to the pre-defined interface interaction rules. The interface request carries the business status identifier and configuration parameters. The back-end subsystem obtains the business rule parameters corresponding to the target game service through the dynamic business rule unit, and performs business rule verification on the business configuration data. The business rule verification includes configuration item legality, business logic conflict, and configuration limit verification. The target game service can be any type of game service. If the verification result of the business rule is successful, the business configuration data is stored in the dedicated data table of the corresponding business configuration module through the business data storage unit; if the verification result of the business rule is unsuccessful, response data containing verification failure information is returned. The back-end subsystem returns response data containing a service status identifier, and the front-end subsystem displays the corresponding service feedback information based on the service status identifier. The configuration synchronization unit pushes the business configuration data stored in the dedicated data table to the game server, and receives the synchronization results from the game server and feeds them back to the user, thus completing the closed loop of configuration data processing.

7. The game configuration data processing method according to claim 6, characterized in that, The business rule verification is configured in real time through the dynamic business rule unit; when it is determined to adjust the verification standard of the business rule verification, the business rule parameters in the configuration file or database are modified.

8. The game configuration data processing method according to claim 6, characterized in that, The configuration synchronization unit supports both batch synchronization and single-item synchronization modes; the synchronization result includes three states: synchronization successful, synchronization failed, and synchronization in progress; when the synchronization result is determined to be a synchronization failure, the failure reason prompt and retry function are provided.

9. The game configuration data processing method according to claim 6, characterized in that, Before allocating accessible authorized business configuration modules and blocking unauthorized modules through the business-based permission control unit based on user business roles, the method further includes: The business code generation unit receives the business configuration module name and database table name corresponding to the target business configuration module input by the user; the target business configuration module can be any type of business configuration module. The system automatically queries the primary key and structure information of the database tables to generate entity class files, data access interfaces, and data mapping files that match the business configuration module.

10. The game configuration data processing method according to claim 9, characterized in that, The entity class field names in the entity class file must be consistent with the business configuration item names; the data access interface includes the query, add, modify, and delete operation methods required by the business configuration module.

Images