A method for game account data collection, sharing and recovery under a distributed cluster
By using a distributed cluster architecture and a ZooKeeper central registration server, the problem of low account operation efficiency in game testing was solved, and efficient sharing and recovery of account data was achieved. It is applicable to LAN, cross-network and offline environments, and reduces development costs.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- XIAMEN WOOBEST INTERACTIVE NETWORK TECH CO LTD
- Filing Date
- 2024-09-09
- Publication Date
- 2026-07-14
AI Technical Summary
In the current game testing process, account operation is inefficient, account data sharing is inconvenient, and cross-LAN data communication is difficult, resulting in high development costs and low efficiency.
It adopts a distributed cluster architecture, uses the ZooKeeper central registration server to realize dynamic monitoring and mutual discovery of machine nodes, and automatically collects, shares and restores account data through HTTP and ProtoBuf protocols, supporting operation in local, cross-network and offline environments.
It enables seamless sharing and efficient operation of account data, improves the convenience and efficiency of the development and testing process, reduces development costs, and supports use in both online and offline environments.
Smart Images
Figure CN119179746B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data collection, sharing, and recovery technology, and in particular to a method for collecting, sharing, and recovering game account data in a distributed cluster. Background Technology
[0002] The process by which developers play games to find bugs during game testing is commonly known as "game testing" or "Game Quality Assurance Testing" (QA Testing). This process is a crucial part of the software development lifecycle, aiming to ensure the game is free of major defects and provides a smooth and enjoyable user experience before release. Game testing steps may include, but are not limited to: Functional testing: checking that all game functions work as expected. Performance testing: ensuring the game runs smoothly on different hardware without performance bottlenecks. Compatibility testing: testing the game's compatibility across different operating systems, devices, or browsers. User interface testing: evaluating the game's user interface for intuitiveness and ease of use. Regression testing: testing after each update or fix to ensure that new changes do not introduce new problems. Stress testing: testing the game's performance under high load or extreme conditions. Security testing: ensuring the game has no security vulnerabilities and protecting player data security. Localization testing: if the game supports multiple languages, ensuring the accuracy and cultural adaptability of all language versions. Game testing is an iterative process that may require multiple iterations until the game meets release standards. Therefore, it is often necessary to store game data in stages to quickly switch to the desired testing stage after bug fixes. However, existing methods have certain limitations, including:
[0003] 1. Limited efficiency of manual account operation: When developers need to quickly advance to a certain stage of the game or transition to a specific state, manual account operation will consume a lot of time and cause inefficiency.
[0004] 2. Backing up other team members' account data is frequent and tedious: When developers want to use other team members' account data, they must perform the following steps: back up the other team's database, copy the database backup to their local machine, import the database, and restart the game server process. All of these steps are quite time-consuming and tedious, significantly impacting efficiency.
[0005] 3. The development cost of game GMs is too high: If developers decide to implement GM menus programmatically to quickly reach specific stages, they will need to write data conversion code for different business modules. For games with rapid requirement iterations and many business modules, this approach will expose high code maintenance costs, as it requires continuous maintenance of the GM code.
[0006] 4. Inconvenient sharing between different local area networks: Since game servers are built in different intranet environments, data sharing is not implemented for security reasons. This makes it inconvenient to share account data. Although the database can be backed up, the backup method is not efficient and the database size is uncontrollable. Summary of the Invention
[0007] In view of this, the purpose of this invention is to propose a method for collecting, sharing and recovering game account data under a distributed cluster, which can solve at least one of the technical problems mentioned in the background art.
[0008] According to one aspect of the present invention, a method for collecting, sharing, and recovering game account data in a distributed cluster is provided, the method comprising:
[0009] Deploy a ZooKeeper central registration server. When the game server process of each team member starts, it registers the node IP and port with the ZooKeeper server and subscribes to node IP change events to dynamically monitor online machine nodes in the team.
[0010] The game server process, running in the individual development environment of each team member, will automatically save the phased account data to the local database when preset conditions are met.
[0011] Team members access account data in other team members' local databases from their respective development environments via node IPs and ports, and query and download other team members' account data to their local databases.
[0012] In the above technical solution, this method utilizes a distributed cluster architecture based on the local area network (LAN) machine nodes. The game server supports local account data collection, sharing, recovery, serialization, import, and export functions. It can be applied not only within a LAN but also across networks and in offline environments, providing game development teams with extremely convenient account data operation services and improving the convenience and efficiency of account data use during program development and testing. The servers within this LAN adopt a microservice architecture, deploying ZooKeeper as a central registration server. Each machine node registers its IP address and port number with ZooKeeper and subscribes to node change events. This setup allows nodes to discover and access each other, building a highly efficient distributed cluster and achieving seamless data sharing. The cluster design emphasizes high availability, scalability, and load balancing capabilities, ensuring the stability and reliability of the data sharing platform. Furthermore, the most practical benefit of introducing ZooKeeper is the improved "service discovery capability." With the ZooKeeper central registration server, the game server process registers node IP information upon startup. When the process is shut down or the user goes offline, ZooKeeper can detect the node's exit and deregister it, thus maintaining a valid list of online nodes. When team members meet certain specific rules (such as changes to the main quest), the game server process automatically clones and collects relevant account data. Utilizing a distributed cluster architecture, machines within the local area network achieve mutual discovery, access, and data sharing through a service discovery mechanism. This data will serve as a source of shared information for subsequent team collaboration.
[0013] In some embodiments, the game server process running in the individual development environments of team members automatically saves the phased account data to the local database when preset conditions are met. Specifically:
[0014] When a team member's character completes the current main quest in the game, a "Main Quest Change" event is thrown to the outside world through the event frame;
[0015] Upon receiving the "Main Quest Change" event, the specific execution steps are as follows:
[0016] The game process server automatically clones a copy of the account data for storage; the account name is named in the format of "_Chapter ID_Main Quest Index", and the current timestamp is recorded in the character data;
[0017] If the account data already exists in the local database, the latest account data will be used to overwrite it.
[0018] In the above technical solution, team members can automatically collect account data when main storyline events in the game change, without requiring manual intervention. Specifically, when team members meet certain rules (such as changes in main storyline events), the game server process automatically clones and collects relevant account data. Utilizing a distributed cluster architecture, machines within the local area network achieve mutual discovery, access, and data sharing through a service discovery mechanism. This data will serve as a source of information for subsequent team collaboration.
[0019] In some embodiments, team members access account data in other team members' local databases from their respective development environments via node IPs and ports. Specifically:
[0020] Based on the IP and port information provided by the ZooKeeper central registration server, we can query the basic information of all shared accounts on the local area network, including the branch names of SVN code repositories and key information descriptions of main tasks in each machine environment.
[0021] In the above technical solution, team members can easily preview and retrieve account data. With the help of key information descriptions in the main quest, they can quickly filter out the account data they need.
[0022] In some embodiments, team members access account data in other team members' local databases from their respective development environments via node IPs and ports, and query and download other team members' account data to their local databases. Specifically:
[0023] Based on the node IP and shared account role ID, access other team members' local databases via HTTP protocol, download the account binary data to the local machine, and import it into the local database.
[0024] In the above technical solution, account data can be obtained with a simple click to download based on node IP, shared account role ID, and HTTP protocol, which greatly saves time, improves efficiency, and enhances convenience.
[0025] In some embodiments, after importing the local database, the method further includes:
[0026] Generate the latest unique character ID locally, and replace the character ID and account name fields in the downloaded account data with the generated unique character ID;
[0027] If the generated account name already exists locally, the mapping relationship between the account name and the character ID will be re-established, and the old character data will be deleted.
[0028] The above technical solution achieves the overlay download of account data, and for convenience, the account name is consistent with the role ID.
[0029] In some embodiments, after importing the local database, the method further includes:
[0030] Access the local database via HTTP protocol, clone the account binary data to the local database, and generate a new set of character data.
[0031] In the above technical solution, account data cloning is achieved by accessing the local server via the HTTP protocol, cloning the account binary data to the local machine, importing it into the local database, and generating a new set of character data.
[0032] In some embodiments, after importing the local database, the method further includes:
[0033] The ProtoBuf protocol is used to serialize database data into binary format.
[0034] In the above technical solution, the import and export of offline account data is realized through the ProtoBuf protocol. The ProtoBuf protocol is used to serialize the database data into binary format, which can export local account data as binary files and import external binary files into the local database, making it convenient for use in cross-network or offline environments.
[0035] According to another aspect of the present invention, an apparatus for collecting, sharing, and restoring game account data in a distributed cluster is provided, based on the above-described method; comprising sequentially connected:
[0036] The ZooKeeper module is used to deploy a ZooKeeper central registration server. When the game server process of a team member starts, it registers the node IP and port with the ZooKeeper server and subscribes to node IP change events to dynamically monitor online machine nodes in the team.
[0037] Several local server modules are used to run the game server process in the individual development environment of team members. When preset conditions are met, the game server process will automatically save the phased account data to the local database. Additionally, the modules are used for team members to access the account data in the local database of other team members from their respective development environments through node IP and port, and to query and download the account data of other team members to their local database.
[0038] In order to better utilize the above method, this application proposes a device for collecting, sharing and restoring game account data under a distributed cluster. Each module corresponds to a step of the above method, and its specific principle has been described above and will not be repeated here.
[0039] According to another aspect of the present invention, a device for collecting, sharing, and restoring game account data in a distributed cluster is provided, comprising:
[0040] At least one processor and a memory communicatively connected to said at least one processor;
[0041] The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method described above.
[0042] In the above technical solution, to better operate and process the method, the method is stored in memory, and the processor executes the stored method. It should be noted that the principle and effect of each step have been described above and will not be elaborated upon here.
[0043] According to another aspect of the present invention, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the above-described method.
[0044] In the above technical solution, to better operate and use the method, the method is stored in a computer-readable storage medium and implemented using a processor. It should be noted that the principle and effect of each step have been described above and will not be elaborated upon here. Attached Figure Description
[0045] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0046] Figure 1 This is a flowchart illustrating an embodiment of a method for collecting, sharing, and restoring game account data under a distributed cluster according to the present invention.
[0047] Figure 2 This is a schematic diagram of the system framework of an embodiment of a method for collecting, sharing, and restoring game account data under a distributed cluster according to the present invention;
[0048] Figure 3 This is a schematic diagram of an embodiment of a device for collecting, sharing, and restoring game account data under a distributed cluster according to the present invention;
[0049] Figure 4 This is a schematic diagram of the local server module structure of an embodiment of a device for collecting, sharing, and restoring game account data under a distributed cluster. Detailed Implementation
[0050] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be particularly noted that the following embodiments are for illustrative purposes only and do not limit the scope of the invention. Similarly, the following embodiments are only some, not all, embodiments of the present invention, and all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0051] This invention provides a method for collecting, sharing, and restoring game account data in a distributed cluster, which can solve at least one of the technical problems mentioned in the background section.
[0052] Example 1
[0053] Please see Figure 1 A method for collecting, sharing, and restoring game account data in a distributed cluster, the method comprising:
[0054] S1. Deploy a ZooKeeper central registration server. When the game server process of each team member starts, it registers the node IP and port with the ZooKeeper server and subscribes to node IP change events to dynamically monitor the online machine nodes in the team.
[0055] In this embodiment, the ZooKeeper central registration server is deployed as follows: In a local area network environment, deploy a Windows or Linux server that runs 24 hours a day. Download the ZooKeeper application from the official website (https: / / zookeeper.apache.org / releases.html#download), extract it, modify the configuration file, and then it can be run.
[0056] S2. The game server process, which runs in the individual development environment of each team member, will automatically save the phased account data to the local database when the preset conditions are met.
[0057] In this embodiment, the game server process running in each team member's individual development environment automatically saves the phased account data to the local database when preset conditions are met. Specifically, when a team member's character completes the current main quest, they throw a "Main Quest Change" event through the event framework. Upon receiving the "Main Quest Change" event, the specific execution steps are as follows: the game server automatically clones and stores the account data; the account name is named in the format "_Chapter ID_Main Quest Index", and the current timestamp is recorded in the character data; if the account data already exists in the local database, it is overwritten with the latest account data. For team members, they can automatically collect account data when the game's main quest event changes, without user intervention. Specifically, when a team member meets a certain rule (such as a main quest change), the game server process automatically clones and collects the relevant account data. Utilizing the distributed cluster architecture concept, machines within the local area network achieve mutual discovery, mutual access, and data sharing through a service discovery mechanism. This data will serve as a source of information for subsequent team collaboration.
[0058] S3: Team members access account data in other team members' local databases from their respective development environments via node IP and port, and query and download other team members' account data to their local databases.
[0059] In this embodiment, the ZooKeeper central registration server does not store account data; it only serves a "service discovery" function. That is, it is only used to register the IP addresses and ports of machine nodes and then provide subscription services to the game server processes on each machine; it does not perform any upload or download operations. Account data is always stored in the databases on the individual computers of team members.
[0060] In this embodiment, team members access account data in other team members' local databases via node IP and port from their respective development environments. Specifically:
[0061] Based on the IP and port information provided by the ZooKeeper central registration server, basic information of all shared accounts on the local area network can be queried, including the branch names of SVN code repositories on each machine environment and key information descriptions of main quests. Team members can easily preview and search account data, and with the help of key information descriptions of main quests, they can quickly filter out the account data they need.
[0062] In this embodiment, the account data of other team members is queried and downloaded to the local database. Specifically, based on the node IP and shared account role ID, the local database of other team members is accessed via HTTP protocol, the account binary data is downloaded to the local machine, and then imported into the local database. Account data can be obtained with a simple click to download using the node IP, shared account role ID, and HTTP protocol, significantly saving time, improving efficiency, and enhancing convenience.
[0063] In this embodiment, after importing the local database, the following is also included:
[0064] The system generates a new, unique character ID locally and replaces the character ID and account name fields in the downloaded account data with this generated unique character ID. If the generated account name already exists locally, the mapping between the account name and character ID is re-established, and the old character data is deleted. This solution overwrites the downloaded account data and, for convenience, ensures that the account name and character ID are consistent.
[0065] In this embodiment, after importing the local database, the method further includes: accessing the local database via the HTTP protocol, cloning the account binary data into the local database, and generating a new set of character data. This solution clones account data by accessing the local server via the HTTP protocol, cloning the account binary data to the local machine, importing it into the local database, and generating a new set of character data.
[0066] In this embodiment, after importing the local database, the method further includes: serializing the database data into binary format using the ProtoBuf protocol. This solution uses the ProtoBuf protocol to import and export offline account data. By serializing the database data into binary format using the ProtoBuf protocol, local account data can be exported as a binary file, and external binary files can be imported into the local database, facilitating use across networks or in offline environments.
[0067] In this embodiment, the method utilizes a distributed cluster architecture based on the local area network (LAN) machine nodes. The game server supports local account data collection, sharing, recovery, serialization, import, and export functions. It can be applied not only within a LAN but also across networks and in offline environments, providing game development teams with extremely convenient account data operation services and improving the convenience and efficiency of account data use during program development and testing. The servers within the LAN adopt a microservice architecture, deploying ZooKeeper as a central registration server. Each machine node registers its IP address and port number with ZooKeeper and subscribes to node change events. This setup allows nodes to discover and access each other, building a highly efficient distributed cluster and achieving seamless data sharing. The cluster design emphasizes high availability, scalability, and load balancing capabilities, ensuring the stability and reliability of the data sharing platform. When team members meet certain specific rules (such as changes in main quests), the game server process automatically clones and collects relevant account data. By employing the concept of a distributed cluster architecture, machines within a local area network can discover, access, and share data with each other through a service discovery mechanism. This data will serve as a source of information for subsequent team collaboration.
[0068] To better explain the embodiments of the present invention, the embodiments of the present invention will be described in terms of system modules, as follows:
[0069] This invention discloses a method for collecting, sharing, and restoring game account data under a distributed cluster. This method refers to the use of a distributed cluster architecture concept by machine nodes in a local area network. The game server supports local account data collection, sharing, restoration, serialization, import and export functions. It can be applied not only to local area networks but also to cross-network and offline environments, providing game development teams with extremely convenient account data operation services and improving the convenience and efficiency of account data use during program development and testing.
[0070] Please see Figure 2The account data recovery function is divided into five main modules: account data collection, account data sharing, account data management, account sharing web page, and service discovery. These five modules are integrated into a single game server process, allowing operation in a local area network environment for team collaboration, as well as exporting account data for use in cross-network or offline environments. The server within this local area network adopts a microservice architecture, deploying ZooKeeper as the central registration server. Each machine node registers its IP address and port number with ZooKeeper and subscribes to node change events. This setup enables nodes to discover and access each other, building a highly efficient distributed cluster and achieving seamless data sharing. The cluster design emphasizes high availability, scalability, and load balancing capabilities, ensuring the stability and reliability of the data sharing platform.
[0071] Within this system, account data from team members in their respective development environments can be collected, categorized, and stored in a local database according to specific rules (e.g., by game main quest ID). Then, through their respective "account data sharing modules," team members can provide data preview, search, and download services to other team members. The service discovery module enables machine nodes on the local area network to discover, access, and share valid and diverse game account data within their respective environments. Team members can quickly download finished accounts created by other members online or import them offline, saving them the time of creating accounts step-by-step.
[0072] ② The technical solution of the invention (the technical solution is explained in conjunction with the diagram, mainly focusing on the innovative points of the technology and the effects brought about by the innovation in detail):
[0073] This invention discloses a method for collecting, sharing, and restoring game account data under a distributed cluster. This method refers to the use of a distributed cluster architecture concept by machine nodes in a local area network. The game server supports local account data collection, sharing, restoration, serialization, import and export functions. It can be applied not only to local area networks but also to cross-network and offline environments, providing game development teams with extremely convenient account data operation services and improving the convenience and efficiency of account data use during program development and testing.
[0074] The account data recovery function consists of five main modules: account data collection module, account data sharing module, account data management module, account sharing web page module, and service discovery module. These five modules are integrated into a single game server process, which can run in a local area network environment for team collaboration, or export account data for use in cross-network or offline environments.
[0075] The servers within this local area network employ a microservices architecture, deploying ZooKeeper as the central registration server. Each machine node registers its IP address and port number with ZooKeeper and subscribes to node change events. This setup enables nodes to discover and access each other, building a highly efficient distributed cluster and achieving seamless data sharing. The cluster design prioritizes high availability and scalability, and incorporates load balancing capabilities, ensuring the stability and reliability of the data sharing platform.
[0076] Within this system, account data from team members in their respective development environments can be collected, categorized, and stored in a local database according to specific rules (e.g., by game main quest ID). Then, through their respective "account data sharing modules," team members can provide data preview, search, and download services to other team members. The service discovery module enables machine nodes on the local area network to discover, access, and share valid and diverse game account data within their respective environments. Team members can quickly download or import finished accounts created by other members online or offline, saving them the time of creating accounts step-by-step. Within this framework, the functions of each module are as follows:
[0077] 1. Account Data Collection Module: Responsible for collecting and storing account data locally. It collects and categorizes data according to specific rules, such as the game's main quest ID, and stores it in the local database. The specific steps are as follows:
[0078] (1) Send a main quest change event. When a character in the game completes the current main quest, a "main quest change" event will be sent to the outside world through the event frame.
[0079] (2) Listen for main quest change events. Upon receiving a "main quest change" event, the specific steps are as follows:
[0080] ①Clone a copy of the account data and store it, naming the account in the format of "_Chapter ID_Main Quest Index", and record the current timestamp in the character data so that the generation time of the account data can be displayed to users through the "Account Sharing Web Page Module".
[0081] ② If the account name already exists in the database, the newer account data will be used to overwrite it, ensuring that an account name is mapped to only one set of data, and the latest set of data will be used as the standard.
[0082] 2. The account data sharing module is responsible for providing other team members with locally collected shared account data. Only account data named in the format "_Chapter ID_Main Quest Index" is allowed to appear in the shared list. The specific steps are as follows:
[0083] (1) Provide an HTTP interface for “Get List of Shared Accounts”, which returns the basic information of all shared accounts in the local environment, including: Channel ID, Account Name, Role Name, Role ID, Role Level, Role Creation Time, Last Login Time, Last Logout Time, Account Data Generation Time, Main Quest ID, Combat Power and other fields. Fields can be expanded as needed.
[0084] (2) Provide an HTTP interface for “Get Code Branch Name”, which returns the branch name of the SVN code repository in the local environment, so that other team members can know that the account data comes from a certain code branch version.
[0085] (3) Provide an HTTP interface for “getting main quest information”, which returns the core key information corresponding to the main quest ID. The key information makes it easier to convey which game data the corresponding account data has unlocked, making it easier for other team members to find matching accounts through text descriptions.
[0086] (4) Provide HTTP interfaces for “Download Account Role Data” and “Clone Account Role Data”, and return all binary data information of the account.
[0087] 3. Account Data Management Module: Responsible for various management operations of account data, such as downloading other party's account data, cloning local account data, and importing and exporting offline account data.
[0088] (1) Pass in the IP address and the shared account role ID, access the "Download Account Role Data" interface of other team members via HTTP protocol, download the account binary data to the local machine, and import it into the local database.
[0089] (2) Supports overwriting download account data
[0090] ① Generate the latest unique character ID locally, and replace the character ID and account name fields in the downloaded account data with the newly generated character ID. For convenience, the account name and character ID are the same.
[0091] ②If the generated account name already exists locally, the mapping relationship between the account name and the character ID will be re-established, and the old character data will be deleted to achieve data overwriting.
[0092] (3) Supports cloning account data. Access the local server via HTTP protocol, clone the account binary data to the local machine, import it into the local database, and generate a new set of character data.
[0093] (4) Supports importing and exporting offline account data. The ProtoBuf protocol is used to serialize the database data into binary format. Local account data can be exported as a binary file, and external binary files can be imported into the local database, which is convenient for use in cross-network or offline environments.
[0094] 4. Account Sharing Web Page Module: This module provides a web page that allows team members to preview and search account sharing information and download account data in a visual manner.
[0095] (1) The web page obtains information such as the IP address and port number of the accessible local area network machine node through the "service discovery" module, and accesses the "account data sharing module" data of each team member through the HTTP protocol, thereby displaying the account data they share with the outside world and displaying the basic information of the account on the web page. The basic information includes: channel ID, account name, role name, role ID, role level, role creation time, role last login time, role last logout time, account data generation time, main quest ID, combat power and other fields.
[0096] (2) The web page provides a text filtering function, which allows users to enter text information to quickly find matching account data entries.
[0097] (3) The web page provides a download button. Find the account entry you need, click "Download", and download the other party's account data to your local computer by calling your own "Account Data Management Module". After the download is successful, the account name will be automatically copied to the clipboard, making it easy to paste directly into the game client input window.
[0098] (4) The web page provides a clone button. Find your local account entry, click "clone", and clone your local account data by calling your "account data management module" and storing it in the local database. After successful cloning, the account name will be automatically copied to the clipboard for easy pasting into the game client input window.
[0099] 5. Service discovery module, responsible for interacting with the central registration server ZooKeeper to register, search, and manage services.
[0100] (1) Register your information with ZooKeeper, such as IP address, port number, etc.
[0101] (2) Subscribe to ZooKeeper service change events, such as service addition, deletion, modification, etc., and update the machine node information cached on the local server in a timely manner.
[0102] (3) Provide an interface to access accessible machine nodes to facilitate the display of the account sharing data list in the "Account Sharing Web Page Module" and ensure the validity of the page data.
[0103] Based on the above, the advantages of this case are as follows:
[0104] 1. Automatic Account Data Collection: For team members, account data can be automatically collected when main storyline events in the game change, without requiring manual intervention. Utilizing a distributed cluster architecture, machines within the local area network achieve mutual discovery, access, and data sharing through a service discovery mechanism. This data will serve as a source of information for subsequent team collaboration.
[0105] 2. Quick Download of Finished Accounts: Team members can easily preview and search account data. Using key information from the main quest descriptions, they can quickly filter out the account data they need. They can also download a variety of finished accounts. A simple click to download account data significantly saves time, improves efficiency, and enhances convenience. Account data can also be imported and exported across network or offline environments. Depending on individual needs, they can flexibly download account data or finished accounts from others, allowing characters in their local environment to quickly reach a certain state, thereby greatly improving the development efficiency of developers.
[0106] 3. Controllable Development Costs: The development costs of this solution are completely controllable. Once development is complete, no further adjustments are needed, allowing for sustainable and stable use, further reducing development costs.
[0107] 4. High Scalability of Distributed Cluster: Team members frequently turn their machines on and off, or shut down the game server, which can lead to situations where other servers become inaccessible. Utilizing the ZooKeeper service discovery mechanism, nodes can be dynamically added and removed, improving the real-time performance of account sharing pages. Compared to existing technologies that can only store data on a single game server and cannot achieve data sharing across multiple machine nodes within a local area network, this patent incorporates a distributed cluster architecture, enhancing the scalability and robustness of data sharing within a local area network.
[0108] 5. Improved Convenience of Account Data Sharing Across Different Local Area Networks (LANs): When server clusters on different LANs cannot communicate with each other, account data can be exported as a binary file from the first environment, shared to the second environment, and then imported into the server, achieving cross-network account data sharing. The addition of cross-network and offline import / export functionality expands beyond a single LAN. Compared to file retrieval, this patent offers multiple options, enabling account data sharing within a LAN, across LANs, and offline, making it more universally applicable.
[0109] Example 2
[0110] Please see Figure 3 A device for collecting, sharing, and restoring game account data in a distributed cluster, based on the above method; including connections:
[0111] The ZooKeeper module is used to deploy a ZooKeeper central registration server. When the game server process of a team member starts, it registers the node IP and port with the ZooKeeper server and subscribes to node IP change events to dynamically monitor online machine nodes in the team.
[0112] Several local server modules are used to run the game server process in each team member's individual development environment. When preset conditions are met, the game server process automatically saves periodic account data to the local database. Additionally, modules are used by team members to access account data in other team members' local databases from their respective development environments via node IPs and ports, and to query and download other team members' account data to their local databases. Please refer to [link to relevant documentation]. Figure 4 The local server module includes the following sub-modules:
[0113] 1. Account Data Collection Module: Responsible for collecting and storing account data locally. It collects and categorizes data according to specific rules, such as the game's main quest ID, and stores it in the local database. The specific steps are as follows:
[0114] (1) Send a main quest change event. When a character in the game completes the current main quest, a "main quest change" event will be sent to the outside world through the event frame.
[0115] (2) Listen for main quest change events. Upon receiving a "main quest change" event, the specific steps are as follows:
[0116] ①Clone a copy of the account data and store it, naming the account in the format of "_Chapter ID_Main Quest Index", and record the current timestamp in the character data so that the generation time of the account data can be displayed to users through the "Account Sharing Web Page Module".
[0117] ② If the account name already exists in the database, the newer account data will be used to overwrite it, ensuring that an account name is mapped to only one set of data, and the latest set of data will be used as the standard.
[0118] 2. The account data sharing module is responsible for providing other team members with locally collected shared account data. Only account data named in the format "_Chapter ID_Main Quest Index" is allowed to appear in the shared list. The specific steps are as follows:
[0119] (1) Provide an HTTP interface for “Get List of Shared Accounts”, which returns the basic information of all shared accounts in the local environment, including: Channel ID, Account Name, Role Name, Role ID, Role Level, Role Creation Time, Last Login Time, Last Logout Time, Account Data Generation Time, Main Quest ID, Combat Power and other fields. Fields can be expanded as needed.
[0120] (2) Provide an HTTP interface for “Get Code Branch Name”, which returns the branch name of the SVN code repository in the local environment, so that other team members can know that the account data comes from a certain code branch version.
[0121] (3) Provide an HTTP interface for “getting main quest information”, which returns the core key information corresponding to the main quest ID. The key information makes it easier to convey which game data the corresponding account data has unlocked, making it easier for other team members to find matching accounts through text descriptions.
[0122] (4) Provide HTTP interfaces for “Download Account Role Data” and “Clone Account Role Data”, and return all binary data information of the account.
[0123] 3. Account Data Management Module: Responsible for various management operations of account data, such as downloading other party's account data, cloning local account data, and importing and exporting offline account data.
[0124] (1) Pass in the IP address and the shared account role ID, access the "Download Account Role Data" interface of other team members via HTTP protocol, download the account binary data to the local machine, and import it into the local database.
[0125] (2) Supports overwriting download account data
[0126] ① Generate the latest unique character ID locally, and replace the character ID and account name fields in the downloaded account data with the newly generated character ID. For convenience, the account name and character ID are the same.
[0127] ②If the generated account name already exists locally, the mapping relationship between the account name and the character ID will be re-established, and the old character data will be deleted to achieve data overwriting.
[0128] (3) Supports cloning account data. Access the local server via HTTP protocol, clone the account binary data to the local machine, import it into the local database, and generate a new set of character data.
[0129] (4) Supports importing and exporting offline account data. The ProtoBuf protocol is used to serialize the database data into binary format. Local account data can be exported as a binary file, and external binary files can be imported into the local database, which is convenient for use in cross-network or offline environments.
[0130] 4. Account Sharing Web Page Module: This module provides a web page that allows team members to preview and search account sharing information and download account data in a visual manner.
[0131] (1) The web page obtains information such as the IP address and port number of the accessible local area network machine node through the "service discovery" module, and accesses the "account data sharing module" data of each team member through the HTTP protocol, thereby displaying the account data they share with the outside world and displaying the basic information of the account on the web page. The basic information includes: channel ID, account name, role name, role ID, role level, role creation time, role last login time, role last logout time, account data generation time, main quest ID, combat power and other fields.
[0132] (2) The web page provides a text filtering function, which allows users to enter text information to quickly find matching account data entries.
[0133] (3) The web page provides a download button. Find the account entry you need, click "Download", and download the other party's account data to your local computer by calling your own "Account Data Management Module". After the download is successful, the account name will be automatically copied to the clipboard, making it easy to paste directly into the game client input window.
[0134] (4) The web page provides a clone button. Find your local account entry, click "clone", and clone your local account data by calling your "account data management module" and storing it in the local database. After successful cloning, the account name will be automatically copied to the clipboard for easy pasting into the game client input window.
[0135] 5. Service discovery module, responsible for interacting with the central registration server ZooKeeper to register, search, and manage services.
[0136] (1) Register your information with ZooKeeper, such as IP address, port number, etc.
[0137] (2) Subscribe to ZooKeeper service change events, such as service addition, deletion, modification, etc., and update the machine node information cached on the local server in a timely manner.
[0138] (3) Provide an interface to access accessible machine nodes to facilitate the display of the account sharing data list in the "Account Sharing Web Page Module" and ensure the validity of the page data.
[0139] In this embodiment, in order to better utilize the method described in one of the embodiments, this application proposes a device for collecting, sharing and restoring game account data under a distributed cluster. Each module corresponds to each step of the above method, and its specific principle has been described above and will not be repeated here.
[0140] Example 3
[0141] A device for collecting, sharing, and restoring game account data in a distributed cluster includes:
[0142] At least one processor and a memory communicatively connected to said at least one processor;
[0143] The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method described in one of the embodiments.
[0144] In this embodiment, to better run and process the method described in one of the embodiments, the above method is stored in a memory, and the stored method is executed using a processor. It should be noted that the principle and effect of each step have been described above and will not be elaborated further here.
[0145] Example 4
[0146] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in one of the embodiments.
[0147] In this embodiment, to better operate and use the method described in one of the embodiments, the above method is stored in a computer-readable storage medium, and the above method is implemented using a processor. It should be noted that the principle and effect of each step have been described above and will not be elaborated further here.
[0148] The above description is only a part of the embodiments of the present invention and does not limit the scope of protection of the present invention. Any equivalent device or equivalent process transformation made based on the content of the present invention specification and drawings, or direct or indirect application in other related technical fields, are similarly included within the patent protection scope of the present invention.
Claims
1. A method for collecting, sharing, and restoring game account data in a distributed cluster, characterized in that, The method includes: Deploy a ZooKeeper central registration server. When the game server process of each team member starts, it registers the node IP and port with the ZooKeeper server and subscribes to node IP change events to dynamically monitor online machine nodes in the team. The game server process, running in the individual development environment of each team member, will automatically save the phased account data to the local database when preset conditions are met. Team members can access account data in other team members' local databases via node IP and port in their respective development environments, and query and download other team members' account data to their local databases. The game server process, running in the individual development environments of team members, automatically saves periodic account data to the local database when preset conditions are met. Specifically: When a team member's character completes the current main quest in the game, a "Main Quest Change" event is thrown to the outside world through the event frame; Upon receiving the "Main Quest Change" event, the specific execution steps are as follows: The game process server automatically clones a copy of the account data for storage; the account name is named in the format of "_Chapter ID_Main Quest Index", and the current timestamp is recorded in the character data; If the account data already exists in the local database, the latest account data will be used to overwrite it.
2. The method for collecting, sharing, and restoring game account data in a distributed cluster as described in claim 1, characterized in that, Team members access account data in other team members' local databases from their respective development environments via node IPs and ports. Specifically: Based on the IP and port information provided by the ZooKeeper central registration server, we can query the basic information of all shared accounts on the local area network, including the branch names of SVN code repositories and key information descriptions of main tasks in each machine environment.
3. The method for collecting, sharing, and restoring game account data in a distributed cluster as described in claim 2, characterized in that, Query and download account data of other team members to the local database, specifically: Based on the node IP and shared account role ID, access other team members' local databases via HTTP protocol, download the account binary data to the local machine, and import it into the local database.
4. The method for collecting, sharing, and restoring game account data in a distributed cluster as described in claim 3, characterized in that, After importing the local database, it also includes: Generate the latest unique character ID locally, and replace the character ID and account name fields in the downloaded account data with the generated unique character ID; If the generated account name already exists locally, the mapping relationship between the account name and the character ID will be re-established, and the old character data will be deleted.
5. The method for collecting, sharing, and restoring game account data in a distributed cluster as described in claim 3, characterized in that, After importing the local database, it also includes: Access the local database via HTTP protocol, clone the account binary data to the local database, and generate a new set of character data.
6. The method for collecting, sharing, and restoring game account data in a distributed cluster as described in claim 1, characterized in that, The method further includes: The ProtoBuf protocol is used to serialize data from the local database into binary format.
7. A device for collecting, sharing, and restoring game account data in a distributed cluster, characterized in that, The method based on any one of claims 1-6; comprising the following connections: The ZooKeeper module is used to deploy a ZooKeeper central registration server. When the game server process of a team member starts, it registers the node IP and port with the ZooKeeper server and subscribes to node IP change events to dynamically monitor online machine nodes in the team. Several local server modules are used to run the game server process in the development environment of each team member. When preset conditions are met, the game server process will automatically save the account data in stages to the local database. Also, it is used for team members to access the account data in the local database of other team members from their own development environment through node IP and port, and to query and download the account data of other team members to the local database. The game server process, running in the individual development environments of team members, automatically saves periodic account data to the local database when preset conditions are met. Specifically: When a team member's character completes the current main quest in the game, a "Main Quest Change" event is thrown to the outside world through the event frame; Upon receiving the "Main Quest Change" event, the specific execution steps are as follows: The game process server automatically clones a copy of the account data for storage; the account name is named in the format of "_Chapter ID_Main Quest Index", and the current timestamp is recorded in the character data; If the account data already exists in the local database, the latest account data will be used to overwrite it.
8. A device for collecting, sharing, and restoring game account data in a distributed cluster, characterized in that, include: At least one processor and a memory communicatively connected to said at least one processor; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1 to 6.
9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 6.