A game maintenance method and device, computer equipment and storage medium

Abstract

Embodiments of the present application disclose a game maintenance method and device, computer equipment and a storage medium. The method comprises the following steps: firstly, starting a multi-point game service in a new version of a game configured on a new server; then, closing a single-point game service in an old version of the game configured on an old server, and prompting a first player client connected to the old server to stop using the single-point game service; further, starting a single-point game service on the new server, and prompting the first player client to update the game, so that the first player client updates to the new version of the game; and when the number of the first player clients meets a stop service condition of the old server, closing the old server. Thus, during the game maintenance without stopping the service, a better game experience is provided for the game players.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a game maintenance method, apparatus, computer equipment, and storage medium. Background Technology

[0002] After a game project is launched, due to the rapid iteration of game content, a major version update is usually performed every so often, releasing a large number of newly developed features for players to experience. During game updates, maintenance methods can include server shutdown maintenance and non-server maintenance.

[0003] Among related technologies, non-stop maintenance has a relatively small impact on players. During the maintenance period, players can still enjoy most of the game experience, and the maintenance process is simpler and more controllable. Therefore, most games choose non-stop maintenance for version updates. However, for some games with complex gameplay, such as RPGs (role-playing games), non-stop maintenance requires handling many functional services, which inevitably leads to anomalies and affects the gaming experience of online players. Summary of the Invention

[0004] This application provides a game maintenance method, apparatus, computer equipment, and storage medium, which provides game players with a better gaming experience during game maintenance without downtime.

[0005] This application provides a game maintenance method, including:

[0006] Start the multi-point game service of the new version of the game configured on the new server, wherein the multi-point game service on the new server and the multi-point game service of the old version of the game configured on the old server can coexist;

[0007] The single-point game service in the old version of the game configured on the old server is shut down, and a service shutdown prompt is given to the first player client accessing the old server based on the single-point game service. The single-point game service in the new version of the game configured on the new server does not coexist with the single-point game service on the old server.

[0008] Start the single-point game service on the new server and prompt the first player client to update the game to the new version.

[0009] When the number of the first player clients meets the shutdown conditions of the old server, the old server is shut down.

[0010] Accordingly, this application also provides a game maintenance device, including:

[0011] The first startup unit is used to start the multi-point game service of the new version of the game configured on the new server, wherein the multi-point game service on the new server and the multi-point game service of the old version of the game configured on the old server can coexist.

[0012] The first shutdown unit is used to shut down the single-point game service in the old version of the game configured on the old server, and to provide a service shutdown prompt to the first player client accessing the old server based on the single-point game service. The single-point game service in the new version of the game configured on the new server does not coexist with the single-point game service on the old server.

[0013] The second startup unit is used to start the single-point game service on the new server and prompt the first player client to update the game to the new version.

[0014] The second shutdown unit is used to shut down the old server when the number of the first player clients meets the shutdown conditions of the old server.

[0015] In some embodiments, the device further includes:

[0016] The third shut-down unit is used to shut down the service access switch corresponding to the single-point game service on the old server, so as to prevent player clients or servers from accessing the single-point game service on the old server.

[0017] In some embodiments, the device further includes:

[0018] The third activation unit is used to activate the service access switch corresponding to the single-point game service on the new server, so that the player client or the server can access the single-point game service on the new server.

[0019] In some embodiments, the device further includes:

[0020] The first detection unit is used to detect whether the multi-point game service on the new server has been successfully started.

[0021] The first execution unit is configured to, if the multi-point game service on the new server is successfully started, execute the step of shutting down the single-point game service in the old version of the game configured on the old server.

[0022] In some embodiments, the first detection unit includes:

[0023] The first verification subunit is used to perform functional verification of the multi-point game service on the new server based on game data in the database.

[0024] The first indication unit is used to indicate that the multi-point game service on the new server has started successfully if the function verification is successful.

[0025] In some embodiments, the device further includes:

[0026] The second detection unit is used to detect whether the single-point game service on the old server has been successfully shut down.

[0027] The second execution unit is used to execute the step of starting the single-point game service on the new server if the single-point game service on the old server is successfully shut down.

[0028] In some embodiments, the device further includes:

[0029] The third detection unit is used to detect whether the single-point game service on the new server has been successfully started.

[0030] The third execution unit is used to execute the step of shutting down the old server when the number of the first player clients meets the shutdown conditions of the old server, if the single-point game service on the new server starts successfully.

[0031] In some embodiments, the third detection unit includes:

[0032] The second verification subunit is used to perform functional verification of the single-point game service on the new server based on game data in the database;

[0033] The second indicator subunit is used to indicate that the single-point game service on the new server has started successfully if the function verification is successful.

[0034] In some embodiments, the device further includes:

[0035] The receiving unit is configured to detect the status of the game account corresponding to the second player client in the old server if it receives a login request from the second player client for the new server;

[0036] The control unit is configured to control the game account corresponding to the second player client to exit the old server if the game account corresponding to the second player client is in an online state in the old server, so that the game account corresponding to the second player client is switched to an offline state in the old server.

[0037] The login unit is used to log in to the new server using the game account corresponding to the second player client.

[0038] In some embodiments, the device further includes:

[0039] The sending unit is used to send information about the pending shutdown of the single-point game service on the old server to the first player client, so that the first player client can notify the game player about the pending shutdown of the game service on the old server.

[0040] In some embodiments, the first closing unit includes:

[0041] The first sending subunit is used to send information about the discontinuation of the single-point game service on the old server to the first player client, so that the first player client can notify the game player that the game service on the old server has been discontinued.

[0042] Accordingly, this application also provides a computer device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes any of the game maintenance methods provided in this application.

[0043] Accordingly, this application also provides a storage medium that stores multiple instructions, which are adapted for a processor to load in order to execute the game maintenance method described above.

[0044] This embodiment of the application first starts the multi-point game service of the new version of the game configured on the new server, then shuts down the single-point game service of the old version of the game configured on the old server, and sends a service shutdown prompt to the first player client accessing the old server based on the single-point game service. Further, it starts the single-point game service on the new server and prompts the first player client to update the game to the new version. When the number of first player clients meets the shutdown conditions of the old server, the old server is shut down. In this way, a better gaming experience is provided to players during the game's non-stop maintenance period. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 This is a flowchart illustrating a game maintenance method provided in an embodiment of this application.

[0047] Figure 2 This is a schematic diagram illustrating an application scenario of a game maintenance method provided in an embodiment of this application.

[0048] Figure 3This is a schematic diagram illustrating an application scenario of another game maintenance method provided in an embodiment of this application.

[0049] Figure 4 This is a flowchart illustrating another game maintenance method provided in an embodiment of this application.

[0050] Figure 5 This is a flowchart illustrating another game maintenance method provided in an embodiment of this application.

[0051] Figure 6 This is a flowchart illustrating another game maintenance method provided in an embodiment of this application.

[0052] Figure 7 This is a flowchart illustrating another game maintenance method provided in an embodiment of this application.

[0053] Figure 8 This is a flowchart illustrating another game maintenance method provided in an embodiment of this application.

[0054] Figure 9 This is a flowchart illustrating another game maintenance method provided in an embodiment of this application.

[0055] Figure 10 This is a structural block diagram of a game maintenance device provided in an embodiment of this application.

[0056] Figure 11 A schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0057] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0058] This application provides a game maintenance method, apparatus, storage medium, and computer device. Specifically, the game maintenance method of this application can be executed by a computer device, which can be a server or similar device. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0059] For example, the computer device can be a server that can start a multi-point game service in a new version of a game configured on a new server, wherein the multi-point game service on the new server can coexist with the multi-point game service in the old version of a game configured on an old server; shut down the single-point game service in the old version of a game configured on the old server, and provide a service shutdown prompt to the first player client accessing the old server based on the single-point game service, wherein the single-point game service in the new version of a game configured on the new server cannot coexist with the single-point game service on the old server; start the single-point game service on the new server, and provide a game update prompt to the first player client so that the first player client updates to the new version of the game; and shut down the old server when the number of first player clients meets the shutdown conditions of the old server.

[0060] Based on the above problems, this application provides a first game maintenance method, apparatus, computer equipment, and storage medium, which provides game players with a better gaming experience during game maintenance without downtime.

[0061] The following sections provide detailed descriptions of each example. It should be noted that the order in which the embodiments are described is not intended to limit the preferred order of the embodiments.

[0062] This application provides a game maintenance method, exemplified by a method executed by a server. Please refer to [link to relevant documentation]. Figure 1 , Figure 1 This is a flowchart illustrating a game maintenance method provided in an embodiment of this application. The specific flow of the game maintenance method is as follows:

[0063] 101. Start the multi-point game service in the new version of the game configured on the new server.

[0064] In this embodiment of the application, the new server refers to a game server configured with a new version of the game, and the game server provides game services that handle different game functions.

[0065] For example, please see Figure 2 , Figure 2 This is a schematic diagram illustrating an application scenario of a game maintenance method provided in an embodiment of this application. Figure 2 The overall architecture of the game server according to an embodiment of this application is shown. The game server is based on nodes and can be divided into login nodes, character (AVT) nodes, main city (Town) nodes, battle (Battle) nodes, hub (Hub) nodes, and service (Service) nodes. Each node can correspond to one physical machine, or consist of multiple physical machines. Depending on actual needs, each node in the game server can be horizontally scaled.

[0066] Specifically, a node refers to a unit in the server architecture that manages resources. Multiple nodes with the same function can be configured according to the online load requirements of the game.

[0067] The login node and the AVT node can communicate via the database, while other nodes can forward messages through the hub node. A star topology can be used for network connectivity, with each node's game process establishing a connection with the hub.

[0068] The login node primarily handles player login-related services. The player client establishes a short connection with the login node. After the login node verifies the login, it generates encrypted login information, stores it in the database, and returns the player's character data, making it easier for the player to select a character to log in.

[0069] The AVT node is responsible for player character (avatar) related functions. Upon logging in, a player establishes a stable primary connection with the AVT node. Most player character-related functions can be performed on the AVT node. Each AVT node can correspond to one server, while other nodes share the same server. This facilitates the differentiation of functions across different servers and allows for easy development of cross-server functionality. The avatar refers to the player character entity within the game; it can be understood as an object. Avatar-related functions can be directly understood as player character-related interactions within the game, such as consuming items, purchasing items, sending emails, chatting, and changing outfits.

[0070] The "town" node is responsible for allocating and managing resources in the main city (e.g., NPC (non-player character) resources, spawn points, and portal resources). Since main city allocation and resource management are relatively demanding services, configuring them as a single node provides better isolation and facilitates configuration and management. The concept of a main city is similar to that in RPG games, where multiple towns (regions) exist, each referred to as a main city.

[0071] Among them, the battle node is the node for battle allocation and resource management, mainly used for battles within game instances.

[0072] The `service` node provides other global functional services. Within the `service` node, each functional service can be configured with one or more processes based on load requirements, isolating different functional services through processes to reduce mutual interference. These global functional services may include: player team-up functionality, cross-server message forwarding functionality, and data collection for all players across the server.

[0073] In this embodiment, each node in the game server can provide different functional services, and each node can have a traditional single-server multi-process structure. For example, a node can consist of the gamemanager, game, gate, and dbmanager processes.

[0074] The `game` process can run various gameplay logics; the `gate` process is responsible for proxying and forwarding network communication data between the player client and the `game` process. The `gate` process is responsible for encrypting, parsing, compressing, and decompressing the communication data; the `dbmanager` process provides database operation services to other processes; and the `gamemanager` process manages all processes centrally, enabling functions such as server startup / shutdown control and server-wide broadcasting. The `gamemanager` process can also be used to broadcast messages or forward messages within the cluster.

[0075] In this application embodiment, a multiple service refers to a game service that can coexist on both new and old servers, meaning a game service that can run simultaneously on both. Most multiple services are those that do not require serialization to a database; for example, the logic service handling team-related tasks in a game can be a multiple service.

[0076] Among them, "old server" refers to a game server configured with an older version of the game. Old servers can have the same architecture as new servers, that is... Figure 2 The server architecture shown.

[0077] In this embodiment, the new server and the old server are the same server, that is, the new server and the old server are the same. The new server and the old server can connect to the same ocean database, and the hostnum (server number) of the corresponding server nodes in the new server and the old server are also the same.

[0078] The hardware deployment of new and old servers can include various methods.

[0079] For example, the same physical machines can be deployed for both the new and old servers, with one set serving as the new server and the other as the old server. In this embodiment, the advantage of deploying two sets of physical machines is that hardware resources are abundant and relatively stable. When deploying two sets of servers, maintenance personnel need to make fewer changes to the configuration files of the two servers, making deployment more convenient. Moreover, the login node and hub node can be reused.

[0080] For example, a Docker (application container engine) environment based on Kubernetes (a portable container orchestration and management tool) can be deployed. Two Docker environments can be started on each physical machine, and each Docker environment can run the complete processes from the previous physical machine, essentially using Docker like a virtual machine. Theoretically, the total number of players in the two Docker environments is the same as the previous physical machine, and resource usage is basically the same. The login node and hub node can also be reused. This allows for the maintenance of two service processes under fixed physical hardware conditions without the need to add additional hardware, effectively reducing maintenance costs.

[0081] 102. Disable the single-point game service in the old version of the game configured on the old server, and send a service shutdown prompt to the first player client accessing the old server based on the single-point game service.

[0082] In particular, the single-point game service in the new version of the game configured on the new server cannot coexist with the single-point game service on the old server.

[0083] In this application embodiment, a single-point game service refers to a game service that cannot coexist on a new server and an old server, that is, a game service that cannot run on both a new server and an old server simultaneously. Single-point game services are mostly services that need to be serialized to a database. For example, a service in a game that handles guild-related logic can be a single-point service.

[0084] In some embodiments, to enable player clients or servers to control access to the game service, the following steps may be included before the step "shutting down the single-point game service in the old version of the game configured on the old server":

[0085] Turn off the service access switch for the single-point game service on the old server to prevent player clients or the server from accessing the single-point game service on the old server.

[0086] Specifically, this application provides a distributed service framework that standardizes and services the logical functions in the game, thereby unifying service access control between the player client and the server.

[0087] For example, please see Figure 3 , Figure 3 This is a schematic diagram illustrating an application scenario of another game maintenance method provided in an embodiment of this application. Figure 3This application illustrates a distributed service framework model based on an embodiment of the present application, which can be an MSA (Master, Slave, Accessor) distributed service framework. The Accessor provides the access point, while the Master and Slave provide the services. The MSA distributed service framework can provide all services; the Master and Slave are the actual service providers, and the Accessor is the entry point for service access. For example, in a game, TeamMaster (team-up functionality), TeamMatchMaster (matchmaking functionality), and DunRankMaster (leaderboard functionality) are defined to provide services with different functions.

[0088] Specifically, Master and Slave are the entities that provide the service. Master and Slave are process models within a single node, and one Master can correspond to multiple Slaves.

[0089] For simpler services, only one Master process is needed, and Slaves are not required. For more complex services that consume a lot of memory or CPU, a single Master process may not be able to handle the workload. In this case, multiple Slave processes are needed to share the burden. Each Slave is responsible for providing the actual service, while the Master is only responsible for resource allocation and management. For example, multiple requests are sent to the Master, and the Master assigns different Slaves to these requests. Finally, the corresponding service (logical calculation) is provided on a specific Slave.

[0090] The Accessor serves as the entry point for obtaining services. The corresponding Master can be found through the Accessor.

[0091] Specifically, taking a replica allocation system as an example, we can illustrate the use of MSA. In a replica allocation system, the corresponding MSA can include: AllocatorMaster, the provider of replica allocation and resource management services; AllocatorSlave, the provider of actual replica resources; and AllocatorAccessor, the provider of replica allocation service discovery.

[0092] For example, in a battle node, one AllocatorMaster and multiple AllocatorSlave are started, and multiple battle nodes are started, meaning there are multiple AllocatorMasters providing services. In an AVT node, an AllocatorAccessor is started in each game process. The AVT node can use the AllocatorAccessor to randomly select an available AllocatorMaster, thereby distributing requests to different battle nodes.

[0093] When the AllocatorMaster receives a replica request from the AVT node, it can request to create replica resources on the AllocatorSlave and return the replica resources to the AVT node. The AVT node then notifies the player client of the replica resources. The player client can then acquire the replica resources and join the corresponding replica.

[0094] In some embodiments, some nodes in the new server and the old server can be shared. To avoid confusion in service discovery between the new server and the old server, service discovery can be controlled.

[0095] Specifically, the login and hub nodes are shared between the new and old servers. Without proper handling, service discovery between the new and old servers will become chaotic. For example, if TeamMaster is started on both the old and new servers, an Accessor will discover TeamMaster on both the new and old servers simultaneously. However, the old server cannot use the new code version of TeamMaster on the new server. Therefore, this solution controls service discovery.

[0096] Controlling service discovery for new and old servers can include: marking new and old servers with different groups. This can be done by adding a group field to the configuration file. Since the groups are different for new and old servers, when the Accessor performs service discovery, it only retains services that are in the same group as the current process (the group_type and group_name are the same). This way, service discovery can be distinguished between new and old servers.

[0097] The `group_type` parameter can be used to identify the server, and the `group_name` parameter can be used to identify the node within the server. For example, you can configure the new server's `group_type` to 1001 and the old server's `group_type` to 1002; you can configure the new server's `group_name` to TEST and the old server's `group_name` to PUBLISH.

[0098] In some embodiments, game services can be categorized to facilitate control over different types of game services.

[0099] Since the hostnum of the corresponding nodes in the new server and the old server are the same, and they are connected to the same database, some single-point game services that need to be serialized cannot coexist on the new server and the old server at the same time, otherwise it will cause data inconsistency. Similarly, some single-point game services can only exist on the new server and the old server at the same time due to the restrictions of special logic. Therefore, this solution classifies the services to facilitate the control of different types of services.

[0100] Specifically, when developing new game features, when defining a new service for that feature, you can specify the type of service (e.g., single-player game service or multi-player game service). This can be achieved using a decorator, as follows:

[0101] def service(name, scope, existence, persistent=False, tickable=False):

[0102] Here, "decorator" refers to a syntax feature in the Python language called a decorator. The decorator syntax allows you to dynamically add specified functionality to functions or classes. For example, in this embodiment, a decorator can be a convenient way to specify a service type for an implementation of a service.

[0103] Specifically, in the definition of each service class, the above decorator can be specified. The main thing to pay attention to is the existence parameter in the decorator, which can be used to control whether the service is a single service or a multiple service.

[0104] For example, GuildCenter can be implemented as follows:

[0105] @senvice("GuildCente", SS_GLOBAL, SE_SINGLE, pensistent=True, tickable=True)

[0106] class Guildcenter(Master):

[0107] def___init__(self, entityid=None):

[0108] super(Guildcenter, self).__init__(entityid)

[0109] In this embodiment, since only one single service can exist simultaneously on both the new and old servers, the game logic needs to handle the logic when the service is unavailable, including the server's functional logic and the player client's UI (user interface) related logic. Specifically, service access control can be implemented in three layers: server service access control, player client access interface control within the server avatar, and player client access control.

[0110] The control over server service access can be implemented as follows:

[0111] Specifically, server service access refers to the retrieval of services within the service logic code, such as retrieving the mailbox of TeamMasterservice to send messages to TeamMaster. The mailbox can specifically locate a particular object and may include: IP address, port number, object ID, etc. The IP address can be used to find the specific physical machine. The port number can be used to find the specific process on that physical machine. The ID can be used to find the specific object within that process. In this embodiment, communication between two objects on the network can be accomplished through the mailbox.

[0112] Specifically, all service access entry points are encapsulated uniformly, each with a return value. The code logic needs to handle service unavailability. For example, all service access entry points can be encapsulated into the following three methods:

[0113] def get_master_mb(self):

[0114] This method can be used to retrieve the master's mailbox;

[0115] def get_master_mb_accessor(accessor_name, check_func=None, hash_key=None):

[0116] This method can obtain the master's mailbox through the accessor;

[0117] def get_local_service(service_name):

[0118] This method can obtain the services of the current process.

[0119] In this application embodiment, factors controlling server service access may include: the service is not started or the service has been stopped, or...

[0120] The ENABLE_SERVER_SINGLE_SERVICE switch allows for convenient control over service access, addressing unpredictable traffic issues that may arise when starting or stopping service entities.

[0121] The implementation of controlling the player client access interface in the server avatar can be as follows:

[0122] Specifically, the functional interfaces provided by the server to player clients need to check the availability of different services depending on the function. For example, when a service is unavailable, a user-friendly message can be provided to the player client to indicate that the game is currently undergoing non-stop maintenance. In this embodiment, a method is provided that applies to all player client interfaces in an avatar, and its implementation can be as follows:

[0123] def client_api_check(service_check=None, user_defined_check=None, check_op=False):

[0124] """

[0125] Client access service check

[0126] @:param service_check: The name of the service that needs to be checked, e.g.:

[0127] GuildCenter

[0128] @:param user_defined_check: Supports user-defined extended check functions.

[0129] @:param check_op: Whether to directly call the check function to perform a pre-check.

[0130] """

[0131] The above method defines a `client_api_check` decorator that specifies the services to be checked. This decorator is applied to the corresponding client interface in each avatar, along with the service check. If the check fails, a prompt is given to the player's client (if the architecture itself separates the interface from the implementation, interface control is easier).

[0132] In this embodiment, the control factors for client access interfaces in the avatar may include: on the one hand, regarding the aforementioned server service access control, if the service cannot be obtained through the above method, it indicates that the service is unavailable, and the player client can be directly given a prompt that the service is unavailable; on the other hand, the ENABLE_CLIENT_SINGLE_SERVICE switch can also be added to control the player client's service access, so that when handling some server service start-up and shutdown operations, the player client's service access control can be turned off, thereby avoiding the impact of player client traffic during service start-up and shutdown, while also providing the player client with a friendly prompt; or through...

[0133] CLIENT_LOCKED_SERVICES is a set of services that do not provide services, allowing for finer-grained control over services.

[0134] The implementation of access control for the client can be as follows:

[0135] Specifically, client access control can be mainly divided into two types: one is UI click events, which need to check whether the corresponding service is available. If the service is unavailable, the player can be prompted and the corresponding UI will not be opened to prevent some UI abnormality issues.

[0136] Another approach is to provide a UI interface in the avatar. If the interface fails the check, the client's message does not need to be sent to the server; instead, the player is not prompted directly. This can prevent situations where there are many UI entry points for certain functions, making the UI difficult to control or causing omissions.

[0137] Specifically, disabling the service access switch for the single-point game service on the old server can include controlling the server to disable access to the single-point game service on the old server, and controlling the player client to disable access to the single-point game service on the old server, thereby preventing the player client or server from accessing the single-point game service on the old server.

[0138] The first player client refers to the player client that logs into the old version of the game on the old server. After the single-point game service on the old server is shut down, the service can be disabled for the first player client that accesses the old server based on the single-point game service. In other words, the first player client will be notified which game services are currently unavailable, so as to avoid the first player client having to wait for the response of these unavailable services, which would affect the player's game experience.

[0139] In some embodiments, to ensure the player's gaming experience during non-disruptive maintenance, the following steps may be included before the step "shutting down the single-point game service in the old version of the game configured on the old server":

[0140] Send a message to the first player's client indicating that the single-point game service on the old server is about to be discontinued, so that the first player's client will notify the game player of the game service on the old server that is about to be discontinued.

[0141] Specifically, during the preset time period before shutting down the single-point game service in the old version of the game configured on the old server, players on the first player client can be given a countdown reminder for non-stop maintenance.

[0142] For example, 30 minutes before shutting down the single-player game service in an older version of the game configured on the old server, a message indicating that the single-player game service on the old server will soon be unavailable can be sent to the first player's client. This allows the first player's client to notify other players about the impending shutdown of the game service on the old server.

[0143] In some embodiments, the step "Provide a service shutdown notification to the first player client accessing the old server based on the single-point game service" may include the following operations:

[0144] Send a message to the first player's client indicating that the single-point game service on the old server has been discontinued, so that the first player's client can notify the game player that the game service on the old server has been discontinued.

[0145] Specifically, when shutting down the single-point game service in the old version of the game configured on the old server, a message indicating that the single-point game service on the old server has been deactivated can be sent to the first player's client so that the first player's client can notify the game player that the game service on the old server has been deactivated.

[0146] In some embodiments, to ensure the gaming experience for players during uninterrupted game maintenance, the following steps may be included after the step "Start the multi-point game service configured on the new server":

[0147] Check if the multi-point game service on the new server has started successfully;

[0148] If the multi-point game service on the new server starts successfully, then proceed with the steps to shut down the single-point game service in the old version of the game configured on the old server.

[0149] Specifically, after starting the multi-point game service on the new server, it is possible to check whether the multi-point game service on the new server has started successfully, so as to ensure that the new server provides multi-point game services in the game.

[0150] In some embodiments, to accurately verify that the multi-point game service on the new server has started successfully, the step "detecting whether the multi-point game service on the new server has started successfully" may include the following operations:

[0151] Functional verification of the multi-point game service on the new server is performed based on game data from the database.

[0152] If the functionality verification passes, it indicates that the multi-point game service on the new server has started successfully.

[0153] In this embodiment of the application, after the new server is configured with the new version of the game, that is, before starting the multi-point game service on the new server, the new server can be connected to the database. For example, the new server can be backed up online to the database backup environment, and the latest game data backed up online can be used to test the compatibility of the new version of the game code with the old game data.

[0154] Furthermore, after launching the multi-point game service for the new version of the game on the new server, the service functions of the multi-point game service can be verified based on the game data in the connected game database.

[0155] Specifically, functional verification of the multi-point game service on the new server based on game data in the database can include: testers conducting regression tests on the multi-point game service on the new server based on game data in the game database, including intensive numerical verification, etc.

[0156] Regression testing refers to retesting old code after modifications to confirm that the modifications have not introduced new errors or caused errors in other code.

[0157] For example, if the multi-point game service on the new server is verified to be functioning normally, it means that the multi-point game service on the new server has started successfully, and then the steps to shut down the single-point game service in the old version of the game configured on the old server can be performed.

[0158] For example, if the multi-point game service on the new server is found to be malfunctioning, it means that the multi-point game service on the new server has failed to start. It is necessary to continue to check for and fix the malfunction of the multi-point game service to ensure that the multi-point game service on the new server can be used normally.

[0159] In some embodiments, to ensure the gaming experience for players during non-disruptive maintenance, the following steps may be included after the step "shutting down the single-point game service in the old version of the game configured on the old server":

[0160] Check if the single-point game service on the old server has been successfully shut down;

[0161] If the single-point game service on the old server is successfully shut down, proceed with the steps to start the single-point game service on the new server.

[0162] In this embodiment, since single-point game services cannot coexist on the new and old servers, to avoid confusion caused by both the new and old servers simultaneously enabling single-point game services during maintenance without downtime, it is necessary to check whether the single-point game service on the old server was successfully shut down after shutting it down.

[0163] For example, if the single-point game service on the old server is successfully shut down, you can then proceed with the steps to start the single-point game service on the new server.

[0164] For example, if the single-player game service on the old server fails to shut down, it is necessary to continue to check for and fix the problem of the single-player game service failure on the old server, so as to ensure that the single-player game service on the old server is successfully shut down before starting the single-player game service on the new server.

[0165] 103. Start the single-player game service on the new server and prompt the first player client to update the game to the new version.

[0166] In some embodiments, to enable player clients or servers to control access to the game service, the following steps may be included after the step "Start the single-point game service on the new server":

[0167] Enable the service access switch for the single-point game service on the new server, so that player clients or servers can access the single-point game service on the new server.

[0168] Specifically, enabling the service access switch for the single-point game service on the new server can include controlling the server to enable access to the single-point game service on the new server, as well as controlling the player client to enable access to the single-point game service on the new server, thereby enabling player clients or the server to access the single-point game service on the new server.

[0169] Specifically, after the single-point game service on the new server is launched, the new server can basically provide all the game services of the new version of the game. At this time, the game update prompts can be sent to the players on the first player client so that they can download the new version of the game and update their first player client to the new version of the game.

[0170] 104. When the number of first-time player clients meets the shutdown conditions of the old server, shut down the old server.

[0171] In this embodiment of the application, the shutdown conditions for the old server may include the number of online players on the old server being less than or equal to a set number of players. To avoid affecting the gaming experience of most players, the set number of players can be a small number, such as 10, 20, or 30. Alternatively, to avoid affecting the gaming experience, the set number of players can be 0, meaning the old server can be shut down when the number of online players on the old server is 0.

[0172] For example, after the new server has successfully launched the single-point and multi-point game services for the new version of the game, the new server can be used completely. Then, the number of online players on the old server is detected. When the number of online players on the old server is less than or equal to the preset number of players, the old server can be shut down, thus completing the game's non-disruptive maintenance and allowing players to enter the new server to play the game.

[0173] In some embodiments, to ensure the gaming experience for players during non-disruptive maintenance, the following steps may be included after the step "Start the single-point game service on the new server":

[0174] Check if the single-point game service on the new server has started successfully;

[0175] If the single-player game service on the new server starts successfully, then the old server will be shut down when the number of first player clients meets the shutdown conditions of the old server.

[0176] Specifically, after starting the single-point game service on the new server, it is possible to check whether the single-point game service on the new server has started successfully, so as to ensure that the new server provides single-point game services in the game.

[0177] In some embodiments, to accurately verify the successful startup of the multi-point game service on the new server, the step "detecting whether the single-point game service on the new server has started successfully" may include the following operations:

[0178] Functional verification of single-point game services on the new server is performed based on game data in the database;

[0179] If the functionality verification passes, it indicates that the single-point game service on the new server has started successfully.

[0180] After launching the single-point game service for the new version of the game on the new server, the service functions of the single-point game service can be verified based on the game data in the connected game database.

[0181] Specifically, functional verification of the single-point game service on the new server based on game data in the database can include: testers conducting regression testing on the single-point game service on the new server based on game data in the game database.

[0182] For example, if the single-player game service on the new server is verified to be functioning normally, it means that the single-player game service on the new server has started successfully. Then, the step of shutting down the old server can be executed when the number of the first player clients meets the shutdown conditions of the old server.

[0183] For example, if the single-player game service on the new server is found to be malfunctioning, it means that the single-player game service on the new server has failed to start. It is necessary to continue to check for and fix the malfunction of the single-player game service to ensure that the single-player game service on the new server can be used normally.

[0184] In some embodiments, to ensure the consistency of player data between the new and old servers during non-disruptive maintenance, the following steps may be included before the step "Shut down the old server":

[0185] If a login request for the new server is received from a second player client, check the status of the game account corresponding to the second player client in the old server;

[0186] If the game account corresponding to the second player client is online in the old server, then control the game account corresponding to the second player client to log out of the old server, so that the game account corresponding to the second player client is switched to offline in the old server.

[0187] Log in to the new server using the game account corresponding to the second player's client.

[0188] The detection of the game account status corresponding to the second player client on the old server can include whether it is online or offline, with offline meaning not online.

[0189] This involves controlling the game account corresponding to the second player client to exit the old server, which means kicking the game account corresponding to the second player client offline from the old server.

[0190] In this embodiment of the application, in order to ensure the consistency of player data, the same player's game account can only be online on the new server or the old server at the same time; on the other hand, in order to avoid considering the compatibility of the old version of the game code on the old server with the game data of the new version of the game on the new server, the player client that has logged into the new version of the game on the new server is not allowed to log into the old version of the game on the old server.

[0191] For example, please see Figure 4 , Figure 4 This is a flowchart illustrating another game maintenance method provided in an embodiment of this application. The specific flow of this game maintenance method can be as follows:

[0192] When a second player client receives a login request for the new service, the first thing to do is check the SVN version number of the game configured on the new server.

[0193] In this embodiment of the application, when generating the official external code for each game version, the SVN (Subversion, an open-source version control system) version number of that game version can be generated.

[0194] Specifically, when a second player's client logs into a new server, it can compare the current SVN version of the game on the new server with the SVN version of the game from the last login.

[0195] If the current game SVN version is older than the last game SVN version logged in, it means that the game version configured on the new server is not the latest version, and the second player client will fail to log in.

[0196] If the current game SVN version is newer than the last game SVN version logged in, it means that the game version configured on the new server is the latest version. Secondly, you can check if the game account corresponding to the second player's client is online on the new server.

[0197] If the game account corresponding to the second player's client is online on the new server, the game account login process (including the queued login process) can be carried out directly on the new server.

[0198] When a player's client logs into the new server, it first enters the new server's login queue, and then logs in one by one according to the order of the queue. "Pushing out an account" means that if a player tries to log in with an account that is already in the login queue or already logged into the server, that account is removed from the queue, and the login process is restarted.

[0199] For example, if account 'a' logs in on server A and then wants to log in on server B, the system will first log out account 'a' on server A before proceeding with the login process on server B, thus ensuring that an account can only exist on one server.

[0200] If the game account corresponding to the second player client is not online on the new server, it can be determined whether a cross-server check is needed. That is, if the old server exists, it is necessary to check on the old server whether the game account corresponding to the second player client is online.

[0201] Specifically, when performing cross-server checks, the login service RollMaster on the new server will notify the old server when it starts, and the login service RollMaster on the old server will notify the new server when it stops. In this way, the new server and the old server can know whether cross-server account hijacking is required.

[0202] If cross-server account sharing is not required, the second player's game account can be logged in directly using the original login logic of the new server.

[0203] If cross-server account login is required, the game account corresponding to the second player client can be checked for online status on the old server. If the game account is online on the old server, it can be disconnected, and the login process can then proceed on the new server. If the game account is offline on the old server, the login can proceed using the existing login logic on the new server. This ensures that the game account corresponding to the second player client only logs in on either the old or new server, guaranteeing the consistency of the game data for that account.

[0204] This application discloses a game maintenance method, which includes: starting a multi-point game service in a new version of the game configured on a new server, wherein the multi-point game service on the new server and the multi-point game service in an old version of the game configured on an old server can coexist; shutting down a single-point game service in the old version of the game configured on the old server, and providing a service shutdown prompt to the first player client accessing the old server based on the single-point game service, wherein the single-point game service in the new version of the game configured on the new server and the single-point game service on the old server do not coexist; starting a single-point game service on the new server, and providing a game update prompt to the first player client so that the first player client updates to the new version of the game; and shutting down the old server when the number of first player clients meets the shutdown conditions of the old server. This allows for a better gaming experience for players during non-disruptive game maintenance.

[0205] Based on the above description, the following examples will further illustrate the game maintenance method described in this application. Please refer to... Figure 5 , Figure 5 This is a flowchart illustrating another game maintenance method provided in this application embodiment. Taking the application of this game maintenance method to a new server configured with a new version of the game as an example, the specific process can be as follows:

[0206] 201. Start the gray-scale server launch.

[0207] In this embodiment of the application, gray-scale server launch refers to the gray-scale launch of a new server. Gray-scale launch divides the startup of all game services into two steps: first, multiple services are started, and then at an appropriate time, such as when the single service in the old server has been stopped, the single service of the new server is started.

[0208] Specifically, first, the process of the game_grey group is started through Supervisor to distinguish it from the normally started game group. Second, all multiple services in the new server are started, and the switches for server and client access are turned off. All single services in the new server are not provided.

[0209] Supervisor is a process management tool that allows for easy management and monitoring of processes launched through it. `game_grey` and `game` are two configuration options for Supervisor, which can be understood as tags corresponding to two different server launch processes. `game_grey` indicates a canary launch, while `game` indicates a normal launch.

[0210] The new server launch process in this solution is as follows: first, a gray-scale launch, followed by the launch of the single-point game service. The gray-scale launch is achieved by starting the configuration marked as game_grey in Supervisor. At this time, the server will be started, but only the multi-point game service is available, not the single-point game service. The single-point service needs to be started in a separate process later.

[0211] In some embodiments, if it is necessary to start the server directly, that is, to start the server fully when it starts up, so that both multi-point service and single-point service can be used, then Supervisor only needs to execute the configuration marked as game.

[0212] 202. Start the single-point game service.

[0213] Specifically, wait for the right time, for example, when the single-player services in the old server have been successfully shut down, the new server can start up all the remaining single services.

[0214] 203. Enable access to the single-point game service on both the server and client sides.

[0215] After all single services have been successfully started in the new server, you can turn on the service access switch for both the server and the client. This will allow both the client and the server to experience the single services in the new server normally.

[0216] This application discloses a game maintenance method, which includes: initiating a gray-scale server launch, including: starting a multi-point game service, and disabling access switches for single-point game services on the server and client; further, starting the single-point game service, and finally enabling access switches for single-point game services on the server and client. This completes the successful launch of the new server.

[0217] Please see Figure 6 , Figure 6 This is a flowchart illustrating another game maintenance method provided in an embodiment of this application. Taking the application of this game maintenance method to an old server configured with an older version of the game as an example, the specific process can be as follows:

[0218] 301. Disable access to single-point game services on both the server and client sides.

[0219] In this embodiment of the application, a gray-scale shutdown is performed on the old server. The gray-scale shutdown can be divided into two stages. First, all single services in the old server are stopped. Then, at an appropriate time, all other entities (including multiple services) in the old server are shut down in accordance with the normal shutdown procedure.

[0220] Specifically, before actually stopping all single services on the old server, you can first turn off the switch to access the single service on the old server. This can prevent some traffic anomalies caused by the shutdown of single services on the old server.

[0221] 302. Disable single-point game service.

[0222] Specifically, wait for the right time, for example, when the multi-point game service in the new server has been successfully launched, you can stop all single services in the old server.

[0223] 303. Close the old server.

[0224] When the traffic of online players has been diverted and the number of online players in the old server is not large, it is advisable to consider shutting down the old server completely, just like a normal server shutdown.

[0225] This application discloses a game maintenance method, which includes: turning off the access switch of the single-point game service on the server and client, then turning off the single-point game service, and finally shutting down the old server, thereby completing the shutdown of the old server.

[0226] Please see Figure 7 , Figure 7 This is a flowchart illustrating another game maintenance method provided in an embodiment of this application. Figure 7 This demonstrates the complete process of non-stop maintenance in this solution. Figure 7 Each node in the diagram represents the current state of the server. The left side shows the state transition flowchart for the old server during non-stop maintenance, and the right side shows the state transition flowchart for the new server during non-stop maintenance. Specifically, it can be seen as follows:

[0227] Before time t0, the new server completes the initial configuration for the new version of the game and begins gray-scale server launch.

[0228] At time t0, the old server is in the SS_NORMAL normal operation state, meaning it is fully open to the public, and all service functions on the old server are available. The new server is in the SS_GREY_STARTED phase, where the single service is currently unavailable. Testers can log in to the new server to perform basic regression tests, such as verifying important numerical values. Between time t0 and t1, the old server's service access switch is turned off, and the server and clients are prohibited from accessing the old server. Then, the gray-scale shutdown begins. Once the old server's gray-scale shutdown is complete, the new server starts its multi-point service. After the multi-point service on the new server has started, the service access switch on the new server can be turned on.

[0229] At time t1, the old server is in the SS_GREY_STOPPED gray-scale shutdown completed state, and all single services in the old server have been stopped. Players can continue to experience dungeon combat and other functions in the new server. The new server is in the SS_NORMAL normal operation state, fully usable, and testers can perform complete regression testing. After the new server testing is completed, the patch file can be released, and the external network can be opened. Players who download the patch can then enter the new server.

[0230] At time t2, after the patch file is released, players on the old server can be reminded to update the patch in stages, thus migrating traffic to the new server. At time t2, once there are virtually no players left on the old server, it can be completely shut down.

[0231] For example, please see Figure 8 , Figure 8 This is a flowchart illustrating another game maintenance method provided in an embodiment of this application. Figure 8 The test procedure for non-disruptive maintenance in this solution is illustrated. Specifically, it can be as follows:

[0232] Before time t0, testing is conducted on the online backup server. Specifically, the online backup server connects to the database backup environment and uses the latest data from the previous day's online backup in the database to test the compatibility of the new code with the old data. This online backup server is for internal testing. Between time t0 and time t1, except for the singleservice, most of the new server's other functionalities are basically available, allowing for basic regression testing, including more demanding numerical verification.

[0233] Between time t3 and time t4, testers can perform a complete regression test on the new server. Under normal circumstances, only the single service function needs to be verified, and other tests should have been completed in the previous step.

[0234] For example, please see Figure 9 , Figure 9 This is a flowchart illustrating another game maintenance method provided in an embodiment of this application. Figure 9 This demonstrates the prompting process for players' clients during non-disruptive maintenance according to this solution. Specifically, it can be as follows:

[0235] At that moment, each player's client will be notified that a non-stop maintenance will take place in 30 minutes, displaying the services that will soon be unavailable in the old server.

[0236] At time t1, the message to the player's client can be switched to "Maintenance is in progress without server downtime," displaying which services in the old server are currently unavailable.

[0237] At time t4, players can be prompted to update the patch and switch to a new server.

[0238] At the time of TB, the entrance to the old server's dungeon will be closed, strongly prompting players to update the patch.

[0239] At time t5, shut down the old server and kick out any players still online from the old server.

[0240] To facilitate better implementation of the game maintenance method provided in this application, this application also provides a game maintenance device based on the above-described game maintenance method. The meanings of the terms used are the same as in the game maintenance method described above, and specific implementation details can be found in the descriptions within the method embodiments.

[0241] Please see Figure 10 , Figure 10 A structural block diagram of a game maintenance device provided in this application embodiment, the device comprising:

[0242] The first startup unit 401 is used to start the multi-point game service of the new version of the game configured on the new server, wherein the multi-point game service on the new server and the multi-point game service of the old version of the game configured on the old server can coexist.

[0243] The first shutdown unit 402 is used to shut down the single-point game service in the old version of the game configured on the old server, and to provide a service shutdown prompt to the first player client accessing the old server based on the single-point game service. The single-point game service in the new version of the game configured on the new server does not coexist with the single-point game service on the old server.

[0244] The second startup unit 403 is used to start the single-point game service on the new server and prompt the first player client to update the game to the new version.

[0245] The second shutdown unit 404 is used to shut down the old server when the number of the first player clients meets the shutdown conditions of the old server.

[0246] In some embodiments, the device may further include:

[0247] The third shut-down unit is used to shut down the service access switch corresponding to the single-point game service on the old server, so as to prevent player clients or servers from accessing the single-point game service on the old server.

[0248] In some embodiments, the device may further include:

[0249] The third activation unit is used to activate the service access switch corresponding to the single-point game service on the new server, so that the player client or the server can access the single-point game service on the new server.

[0250] In some embodiments, the device may further include:

[0251] The first detection unit is used to detect whether the multi-point game service on the new server has been successfully started.

[0252] The first execution unit is configured to, if the multi-point game service on the new server is successfully started, execute the step of shutting down the single-point game service in the old version of the game configured on the old server.

[0253] In some embodiments, the first detection unit may include:

[0254] The first verification subunit is used to perform functional verification of the multi-point game service on the new server based on game data in the database.

[0255] The first indication unit is used to indicate that the multi-point game service on the new server has started successfully if the function verification is successful.

[0256] In some embodiments, the device may further include:

[0257] The second detection unit is used to detect whether the single-point game service on the old server has been successfully shut down.

[0258] The second execution unit is used to execute the step of starting the single-point game service on the new server if the single-point game service on the old server is successfully shut down.

[0259] In some embodiments, the device may further include:

[0260] The third detection unit is used to detect whether the single-point game service on the new server has been successfully started.

[0261] The third execution unit is used to execute the step of shutting down the old server when the number of the first player clients meets the shutdown conditions of the old server, if the single-point game service on the new server starts successfully.

[0262] In some embodiments, the third detection unit may include:

[0263] The second verification subunit is used to perform functional verification of the single-point game service on the new server based on game data in the database;

[0264] The second indicator subunit is used to indicate that the single-point game service on the new server has started successfully if the function verification is successful.

[0265] In some embodiments, the device may further include:

[0266] The receiving unit is configured to detect the status of the game account corresponding to the second player client in the old server if it receives a login request from the second player client for the new server;

[0267] The control unit is configured to control the game account corresponding to the second player client to exit the old server if the game account corresponding to the second player client is in an online state in the old server, so that the game account corresponding to the second player client is switched to an offline state in the old server.

[0268] The login unit is used to log in to the new server using the game account corresponding to the second player client.

[0269] In some embodiments, the device may further include:

[0270] The sending unit is used to send information about the pending shutdown of the single-point game service on the old server to the first player client, so that the first player client can notify the game player about the pending shutdown of the game service on the old server.

[0271] In some embodiments, the first closing unit 402 may include:

[0272] The first sending subunit is used to send information about the discontinuation of the single-point game service on the old server to the first player client, so that the first player client can notify the game player that the game service on the old server has been discontinued.

[0273] This application discloses a game maintenance device. A first startup unit 401 starts a multi-point game service in a new version of the game configured on a new server, wherein the multi-point game service on the new server can coexist with the multi-point game service in an old version of the game configured on an old server. A first shutdown unit 402 shuts down the single-point game service in the old version of the game configured on the old server and provides a service shutdown prompt to a first player client accessing the old server based on the single-point game service, wherein the single-point game service in the new version of the game configured on the new server does not coexist with the single-point game service on the old server. A second startup unit 403 starts the single-point game service on the new server and provides a game update prompt to the first player client, so that the first player client updates to the new version of the game. A second shutdown unit 404 shuts down the old server when the number of the first player clients meets the shutdown conditions of the old server. Thus, during non-stop game maintenance, a better gaming experience is provided to players.

[0274] Accordingly, embodiments of this application also provide a computer device, which can be a server. For example... Figure 11 As shown, Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device 500 includes a processor 501 with one or more processing cores, a memory 502 with one or more computer-readable storage media, and a computer program stored on the memory 502 and executable on the processor. The processor 501 and the memory 502 are electrically connected. Those skilled in the art will understand that the computer device structure shown in the figure does not constitute a limitation on the computer device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0275] The processor 501 is the control center of the computer device 500. It connects various parts of the computer device 500 through various interfaces and lines. By running or loading software programs and / or modules stored in the memory 502, and calling data stored in the memory 502, it performs various functions of the computer device 500 and processes data, thereby monitoring the computer device 500 as a whole.

[0276] In this embodiment, the processor 501 in the computer device 500 loads the instructions corresponding to the processes of one or more applications into the memory 502 according to the following steps, and the processor 501 runs the applications stored in the memory 502 to achieve various functions:

[0277] Start the multi-point game service in the new version of the game configured on the new server. The multi-point game service on the new server can coexist with the multi-point game service in the old version of the game configured on the old server.

[0278] The single-point game service configured on the old version of the game on the old server is shut down, and a service shutdown prompt is sent to the first player client accessing the old server based on the single-point game service. The single-point game service configured on the new version of the game on the new server does not coexist with the single-point game service on the old server.

[0279] Start the single-player game service on the new server and prompt the first player's client to update to the new version of the game;

[0280] The old server will be shut down when the number of first-time player clients meets the shutdown conditions.

[0281] In some embodiments, before shutting down the single-point game service in the old version of the game configured on the old server, the method further includes:

[0282] Turn off the service access switch for the single-point game service on the old server to prevent player clients or the server from accessing the single-point game service on the old server.

[0283] In some embodiments, after starting the single-point game service on the new server, the method further includes:

[0284] Enable the service access switch for the single-point game service on the new server, so that player clients or servers can access the single-point game service on the new server.

[0285] In some embodiments, after starting the multi-point gaming service of the new version of the game configured on the new server, the method further includes:

[0286] Check if the multi-point game service on the new server has started successfully;

[0287] If the multi-point game service on the new server starts successfully, then proceed with the steps to shut down the single-point game service in the old version of the game configured on the old server.

[0288] In some embodiments, detecting whether the multi-point gaming service on the new server has started successfully includes:

[0289] Functional verification of the multi-point game service on the new server is performed based on game data from the database.

[0290] If the functionality verification passes, it indicates that the multi-point game service on the new server has started successfully.

[0291] In some embodiments, after shutting down the single-point game service in the old version of the game configured on the old server, the method further includes:

[0292] Check if the single-point game service on the old server has been successfully shut down;

[0293] If the single-point game service on the old server is successfully shut down, proceed with the steps to start the single-point game service on the new server.

[0294] In some embodiments, after starting the single-point game service on the new server, the method further includes:

[0295] Check if the single-point game service on the new server has started successfully;

[0296] If the single-player game service on the new server starts successfully, then the old server will be shut down when the number of first player clients meets the shutdown conditions of the old server.

[0297] In some embodiments, detecting whether the single-point game service on the new server has started successfully includes:

[0298] Functional verification of single-point game services on the new server is performed based on game data in the database;

[0299] If the functionality verification passes, it indicates that the single-point game service on the new server has started successfully.

[0300] In some embodiments, before shutting down the old server, the following is also included:

[0301] If a login request for the new server is received from a second player client, check the status of the game account corresponding to the second player client in the old server;

[0302] If the game account corresponding to the second player client is online in the old server, then control the game account corresponding to the second player client to log out of the old server, so that the game account corresponding to the second player client is switched to offline in the old server.

[0303] Log in to the new server using the game account corresponding to the second player's client.

[0304] In some embodiments, before shutting down the single-point game service in the old version of the game configured on the old server, the method further includes:

[0305] Send the message "Pending Discontinuation of Single-Point Game Service on Old Server" to the first player's client so that the first player's client can notify the game player of the pending discontinuation of the game service on the old server;

[0306] Based on the single-point game service, a service shutdown notification is sent to the first player client accessing the old server, including:

[0307] Send a message to the first player's client indicating that the single-point game service on the old server has been discontinued, so that the first player's client can notify the game player that the game service on the old server has been discontinued.

[0308] This embodiment of the application first starts the multi-point game service of the new version of the game configured on the new server, then shuts down the single-point game service of the old version of the game configured on the old server, and sends a service shutdown prompt to the first player client accessing the old server based on the single-point game service. Further, it starts the single-point game service on the new server and prompts the first player client to update the game to the new version. When the number of first player clients meets the shutdown conditions of the old server, the old server is shut down. In this way, a better gaming experience is provided to players during the game's non-stop maintenance period.

[0309] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0310] Optional, such as Figure 11 As shown, the computer device 500 also includes: a touch screen display 503, a radio frequency circuit 504, an audio circuit 505, an input unit 506, and a power supply 507. The processor 501 is electrically connected to the touch screen display 503, the radio frequency circuit 504, the audio circuit 505, the input unit 506, and the power supply 507. Those skilled in the art will understand that... Figure 11 The computer device structure shown does not constitute a limitation on the computer device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0311] The touch display screen 503 can be used to display a graphical user interface (GUI) and receive operation commands generated by the user interacting with the GUI. The touch display screen 503 may include a display panel and a touch panel. The display panel can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the computer device. These graphical user interfaces can be composed of graphics, text, icons, video, and any combination thereof. Optionally, the display panel can be configured using a liquid crystal display (LCD), organic light-emitting diode (OLED), or other similar technologies. The touch panel can be used to collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel), generate corresponding operation commands, and execute the corresponding program according to the operation commands. Optionally, the touch panel may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch location and the signal generated by the touch operation, transmitting the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 501. It can also receive and execute commands from the processor 501. The touch panel can cover the display panel. When the touch panel detects a touch operation on or near it, it transmits the information to the processor 501 to determine the type of touch event. Subsequently, the processor 501 provides corresponding visual output on the display panel based on the type of touch event. In this embodiment, the touch panel and the display panel can be integrated into the touch display screen 503 to achieve input and output functions. However, in some embodiments, the touch panel and the touch display screen 503 can be implemented as two independent components to achieve input and output functions. That is, the touch display screen 503 can also be used as part of the input unit 506 to achieve input functions.

[0312] In this embodiment, a game application is executed by processor 501 to generate a graphical user interface (GUI) on touch display screen 503. The virtual scene on the GUI includes at least one skill control area, and the skill control area includes at least one skill control. The touch display screen 503 is used to present the GUI and receive operation commands generated by the user interacting with the GUI.

[0313] The radio frequency circuit 504 can be used to transmit and receive radio frequency signals to establish wireless communication with network devices or other computer devices, and to transmit and receive signals with network devices or other computer devices.

[0314] Audio circuitry 505 can be used to provide an audio interface between a user and a computer device via a speaker and a microphone. Audio circuitry 505 converts received audio data into electrical signals, transmits them to the speaker, and the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuitry 505, converted back into audio data, and output to processor 501 for processing. The audio data is then transmitted via radio frequency circuitry 504 to, for example, another computer device, or output to memory 502 for further processing. Audio circuitry 505 may also include an earphone jack to facilitate communication between peripheral headphones and the computer device.

[0315] The input unit 506 can be used to receive input numbers, characters, or user characteristic information (such as fingerprints, iris, facial information, etc.), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.

[0316] Power supply 507 is used to supply power to various components of computer device 500. Optionally, power supply 507 can be logically connected to processor 501 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. Power supply 507 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0317] although Figure 11 As not shown in the diagram, the computer device 500 may also include a camera, sensor, wireless fidelity module, Bluetooth module, etc., which will not be described in detail here.

[0318] 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 in other embodiments.

[0319] As can be seen from the above, the computer device provided in this embodiment starts a multi-point game service in a new version of the game configured on a new server, wherein the multi-point game service on the new server and the multi-point game service in an old version of the game configured on the old server can coexist; it shuts down the single-point game service in the old version of the game configured on the old server, and provides a service shutdown prompt to the first player client accessing the old server based on the single-point game service, wherein the single-point game service in the new version of the game configured on the new server and the single-point game service on the old server do not coexist; it starts the single-point game service on the new server and provides a game update prompt to the first player client so that the first player client updates to the new version of the game; and it shuts down the old server when the number of first player clients meets the shutdown conditions of the old server.

[0320] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0321] Therefore, embodiments of this application provide a computer-readable storage medium storing a plurality of computer programs that can be loaded by a processor to execute the steps in any of the game maintenance methods provided in embodiments of this application. For example, the computer program can execute the following steps:

[0322] Start the multi-point game service in the new version of the game configured on the new server. The multi-point game service on the new server can coexist with the multi-point game service in the old version of the game configured on the old server.

[0323] The single-point game service configured on the old version of the game on the old server is shut down, and a service shutdown prompt is sent to the first player client accessing the old server based on the single-point game service. The single-point game service configured on the new version of the game on the new server does not coexist with the single-point game service on the old server.

[0324] Start the single-player game service on the new server and prompt the first player's client to update to the new version of the game;

[0325] The old server will be shut down when the number of first-time player clients meets the shutdown conditions.

[0326] In some embodiments, before shutting down the single-point game service in the old version of the game configured on the old server, the method further includes:

[0327] Turn off the service access switch for the single-point game service on the old server to prevent player clients or the server from accessing the single-point game service on the old server.

[0328] In some embodiments, after starting the single-point game service on the new server, the method further includes:

[0329] Enable the service access switch for the single-point game service on the new server, so that player clients or servers can access the single-point game service on the new server.

[0330] In some embodiments, after starting the multi-point gaming service of the new version of the game configured on the new server, the method further includes:

[0331] Check if the multi-point game service on the new server has started successfully;

[0332] If the multi-point game service on the new server starts successfully, then proceed with the steps to shut down the single-point game service in the old version of the game configured on the old server.

[0333] In some embodiments, detecting whether the multi-point gaming service on the new server has started successfully includes:

[0334] Functional verification of the multi-point game service on the new server is performed based on game data from the database.

[0335] If the functionality verification passes, it indicates that the multi-point game service on the new server has started successfully.

[0336] In some embodiments, after shutting down the single-point game service in the old version of the game configured on the old server, the method further includes:

[0337] Check if the single-point game service on the old server has been successfully shut down;

[0338] If the single-point game service on the old server is successfully shut down, proceed with the steps to start the single-point game service on the new server.

[0339] In some embodiments, after starting the single-point game service on the new server, the method further includes:

[0340] Check if the single-point game service on the new server has started successfully;

[0341] If the single-player game service on the new server starts successfully, then the old server will be shut down when the number of first player clients meets the shutdown conditions of the old server.

[0342] In some embodiments, detecting whether the single-point game service on the new server has started successfully includes:

[0343] Functional verification of single-point game services on the new server is performed based on game data in the database;

[0344] If the functionality verification passes, it indicates that the single-point game service on the new server has started successfully.

[0345] In some embodiments, before shutting down the old server, the following is also included:

[0346] If a login request for the new server is received from a second player client, check the status of the game account corresponding to the second player client in the old server;

[0347] If the game account corresponding to the second player client is online in the old server, then control the game account corresponding to the second player client to log out of the old server, so that the game account corresponding to the second player client is switched to offline in the old server.

[0348] Log in to the new server using the game account corresponding to the second player's client.

[0349] In some embodiments, before shutting down the single-point game service in the old version of the game configured on the old server, the method further includes:

[0350] Send the message "Pending Discontinuation of Single-Point Game Service on Old Server" to the first player's client so that the first player's client can notify the game player of the pending discontinuation of the game service on the old server;

[0351] Based on the single-point game service, a service shutdown notification is sent to the first player client accessing the old server, including:

[0352] Send a message to the first player's client indicating that the single-point game service on the old server has been discontinued, so that the first player's client can notify the game player that the game service on the old server has been discontinued.

[0353] This embodiment of the application first starts the multi-point game service of the new version of the game configured on the new server, then shuts down the single-point game service of the old version of the game configured on the old server, and sends a service shutdown prompt to the first player client accessing the old server based on the single-point game service. Further, it starts the single-point game service on the new server and prompts the first player client to update the game to the new version. When the number of first player clients meets the shutdown conditions of the old server, the old server is shut down. In this way, a better gaming experience is provided to players during the game's non-stop maintenance period.

[0354] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0355] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0356] Since the computer program stored in the storage medium can execute the steps in any of the game maintenance methods provided in the embodiments of this application, the beneficial effects that any of the game maintenance methods provided in the embodiments of this application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0357] The above provides a detailed description of a game maintenance method, apparatus, storage medium, and computer device provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A game maintenance method, characterized in that, include: Start the multi-point game service of the new version of the game configured on the new server, wherein the multi-point game service on the new server and the multi-point game service of the old version of the game configured on the old server can coexist; the multi-point game service is a service that does not need to be serialized to the database. The single-point game service in the old version of the game configured on the old server is shut down, and a service shutdown prompt is sent to the first player client accessing the old server based on the single-point game service. The single-point game service in the new version of the game configured on the new server does not coexist with the single-point game service on the old server. The single-point game service is a service that needs to be serialized to the database. Start the single-point game service on the new server and prompt the first player client to update the game to the new version. When the number of the first player clients meets the shutdown conditions of the old server, the old server is shut down.

2. The method according to claim 1, characterized in that, Before shutting down the single-point game service in the old version of the game configured on the old server, the following is also included: Turn off the service access switch corresponding to the single-point game service on the old server to prevent player clients or servers from accessing the single-point game service on the old server.

3. The method according to claim 1, characterized in that, After launching the single-point game service on the new server, the following is also included: Enable the service access switch for the single-point game service on the new server, so that player clients or servers can access the single-point game service on the new server.

4. The method according to claim 1, characterized in that, After launching the multi-point gaming service in the new version of the game configured on the new server, the following is also included: Check whether the multi-point game service on the new server has started successfully; If the multi-point game service on the new server starts successfully, then the step of shutting down the single-point game service in the old version of the game configured on the old server is executed.

5. The method according to claim 4, characterized in that, The step of detecting whether the multi-point game service on the new server has started successfully includes: The multi-point game service on the new server is functionally verified based on the game data in the database. If the functionality verification passes, it indicates that the multi-point gaming service on the new server has started successfully.

6. The method according to claim 1, characterized in that, After shutting down the single-point game service in the old version of the game configured on the old server, the following is also included: Check whether the single-point game service on the old server has been successfully shut down; If the single-point game service on the old server is successfully shut down, then proceed with the step of starting the single-point game service on the new server.

7. The method according to claim 1, characterized in that, After launching the single-point game service on the new server, the following is also included: Check whether the single-point game service on the new server has started successfully; If the single-player game service on the new server starts successfully, then the step of shutting down the old server when the number of the first player clients meets the shutdown conditions of the old server will be executed.

8. The method according to claim 7, characterized in that, The step of detecting whether the single-point game service on the new server has started successfully includes: The single-point game service on the new server is functionally verified based on the game data in the database; If the functionality verification passes, it indicates that the single-point game service on the new server has started successfully.

9. The method according to claim 1, characterized in that, Before shutting down the old server, the following is also included: If a login request for the new server is received from a second player client, the status of the game account corresponding to the second player client in the old server is checked. If the game account corresponding to the second player client is online in the old server, then control the game account corresponding to the second player client to log out of the old server, so that the game account corresponding to the second player client is switched to offline in the old server; Log in to the new server using the game account corresponding to the second player client.

10. The method according to claim 1, characterized in that, Before shutting down the single-point game service in the old version of the game configured on the old server, the following is also included: Send the pending shutdown information of the single-point game service on the old server to the first player client, so that the first player client can notify the game player of the pending shutdown game service on the old server; The step of providing a service deactivation notification to the first player client accessing the old server based on the single-point game service includes: Send a message to the first player's client indicating that the single-point game service on the old server has been deactivated, so that the first player's client notifies the game player that the game service on the old server has been deactivated.

11. A game maintenance device, characterized in that, The device includes: The first startup unit is used to start the multi-point game service of the new version of the game configured on the new server, wherein the multi-point game service on the new server and the multi-point game service of the old version of the game configured on the old server can coexist; the multi-point game service is a service that does not need to be serialized to the database. The first shutdown unit is used to shut down the single-point game service in the old version of the game configured on the old server, and to provide a service shutdown prompt to the first player client accessing the old server based on the single-point game service. The single-point game service in the new version of the game configured on the new server does not coexist with the single-point game service on the old server. The single-point game service is a service that needs to be serialized to the database. The second startup unit is used to start the single-point game service on the new server and prompt the first player client to update the game to the new version. The second shutdown unit is used to shut down the old server when the number of the first player clients meets the shutdown conditions of the old server.

12. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein, When the processor executes the program, it implements the game maintenance method as described in any one of claims 1 to 10.

13. A storage medium, characterized in that, The storage medium stores a plurality of instructions adapted for loading by a processor to execute the game maintenance method according to any one of claims 1 to 10.

Images