Cross-server access method, device, equipment, medium and program product of virtual world

Abstract

This application discloses a method, apparatus, device, medium, and program product for cross-server access in a virtual world, relating to the field of computer technology. The method includes: establishing cross-server access permissions for a first account to a first server when cross-server occupancy information meets a first occupancy requirement; and sending first display data to the first account when the first account has cross-server access permissions to the first server. When a world entry request is received from the first account, the load status of cross-server accounts on the first server is obtained by acquiring cross-server occupancy information, and a decision is made on whether to allow the first account to cross-server access to the first virtual world managed by the first server by determining whether the load status meets the first occupancy requirement. This prevents the first server from being overloaded with too many cross-server accounts, thereby avoiding problems such as longer response times, downtime, and crashes due to excessive load on the first server, and ensuring the stable operation of the first server.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device, medium, and program product for cross-server access in a virtual world. Background Technology

[0002] Games typically offer at least two virtual worlds, each containing a different player group. These virtual worlds are managed by dedicated servers (DS), with different DSs managing different virtual worlds; for example, DS1 manages virtual world 1, and DS2 manages virtual world 2.

[0003] In related technologies, players can traverse between at least two virtual worlds in a game. If player A, belonging to virtual world 1, requests to enter virtual world 2, it is necessary to migrate player A's data (such as character data) from DS1 to DS2 and connect player A's game client to DS2 to complete the traversal operation from virtual world 1 to virtual world 2.

[0004] However, the frequent traversal of virtual worlds by players in the game increases the load on the DS, leading to problems such as longer response times, crashes, and freezes, thus affecting the normal operation of the game. Summary of the Invention

[0005] This application provides a method, apparatus, device, medium, and program product for cross-server access in a virtual world. The technical solution is as follows:

[0006] On the one hand, a method for cross-server access in a virtual world is provided, the method comprising:

[0007] Upon receiving a world entry request from the first account, cross-server occupancy information is obtained. This cross-server occupancy information is used to indicate the load status of cross-server accounts in the current first server. The world entry request is used to request the first account to cross-server enter the first virtual world managed by the first server.

[0008] If the cross-server occupancy information meets the first occupancy requirement, establish cross-server access permissions for the first account to the first server;

[0009] If the first account has cross-server access to the first server, first display data is sent to the first account. The first display data is used to provide the first account with the display screen of the first virtual world.

[0010] On the other hand, a cross-server access device for virtual worlds is provided, the device comprising:

[0011] The acquisition module is used to acquire cross-server occupancy information when it receives a world entry request sent by the first account. The cross-server occupancy information is used to indicate the load status of cross-server accounts in the current first server. The world entry request is used to request the first account to cross-server enter the first virtual world managed by the first server.

[0012] The processing module is used to establish cross-server access permissions for the first account to the first server when the cross-server occupancy information meets the first occupancy requirement.

[0013] The sending module is used to send first display data to the first account when the first account has cross-server access to the first server. The first display data is used to provide the first account with the display screen of the first virtual world.

[0014] On the other hand, a computer device is provided, the computer device including a processor and a memory, the memory storing at least one instruction, at least one program, code set or instruction set, the at least one instruction, the at least one program, the code set or instruction set being loaded and executed by the processor to implement any of the above-described cross-server access methods for virtual worlds.

[0015] On the other hand, a computer-readable storage medium is provided, wherein at least one instruction, at least one program, code set, or instruction set is stored in the storage medium, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement any of the above-described cross-server access methods for virtual worlds.

[0016] On the other hand, a computer program product or computer program is provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform any of the aforementioned cross-server access methods for virtual worlds.

[0017] The beneficial effects of the technical solutions provided in this application include at least the following:

[0018] When a request to enter the world is received from the first account, the load status of cross-server accounts in the first server is obtained by acquiring cross-server occupancy information. The system then determines whether to allow the first account to enter the first virtual world managed by the first server by judging whether the load status meets the first occupancy requirements. This prevents the first server from being overloaded with too many cross-server accounts, thereby avoiding problems such as longer response times, downtime, and crashes caused by excessive load on the first server, and ensuring the stable operation of the first server. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram of a computer system provided in an exemplary embodiment of this application;

[0021] Figure 2 This is a flowchart of a cross-server access method for a virtual world provided in an exemplary embodiment of this application;

[0022] Figure 3 This is a flowchart of a cross-server access method for a virtual world provided in another exemplary embodiment of this application;

[0023] Figure 4 This is an interactive flowchart of a cross-server access method for a virtual world provided in an exemplary embodiment of this application;

[0024] Figure 5 This is a flowchart of a cross-server access method for a virtual world provided in yet another exemplary embodiment of this application;

[0025] Figure 6 This is a schematic diagram of an interface for entering a virtual world across servers, provided in an exemplary embodiment of this application.

[0026] Figure 7 This is a schematic diagram of the implementation architecture of a cross-server access method for virtual worlds provided in an exemplary embodiment of this application;

[0027] Figure 8 This is an interactive flowchart of a cross-server access method for a virtual world provided in another exemplary embodiment of this application;

[0028] Figure 9 This is an interactive flowchart of a cross-server access method for a virtual world provided in yet another exemplary embodiment of this application;

[0029] Figure 10 This is a structural block diagram of a cross-server access device for a virtual world provided in an exemplary embodiment of this application;

[0030] Figure 11 This is a structural block diagram of a computer device provided in an exemplary embodiment of this application. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0032] In this application, the terms "first" and "second" are used to distinguish between identical or similar items that have essentially the same function. It should be understood that there is no logical or temporal dependency between "first" and "second", nor is there any limitation on the quantity or execution order.

[0033] It should be noted that this application may display prompt interfaces, pop-ups, or output voice prompts before and during the collection of user data. These prompt interfaces, pop-ups, or voice prompts are used to inform the user that their data is being collected. This ensures that the application only begins the steps for collecting user data after receiving confirmation from the user regarding the prompt interface or pop-up; otherwise (i.e., without user confirmation), the steps for collecting user data end, meaning no user data is collected. In other words, all user data collected in this application is collected with the user's consent and authorization, and the collection, use, and processing of related user data must comply with relevant laws, regulations, and standards.

[0034] First, the computer system used to implement the cross-server access method for the virtual world provided in the embodiments of this application is... Introduction.

[0035] Figure 1 The present application provides a structural block diagram of a computer system according to an exemplary embodiment. The computer system 100 includes: a terminal 110, a target server 120, and a source server 130, wherein the terminal 110 and the target server 120 are connected via a wireless or wired network, and the terminal 110 and the source server 130 are connected via a wireless or wired network.

[0036] Terminal 110 can be an electronic device such as a mobile phone, tablet computer, vehicle terminal (vehicle system), wearable device, or PC (Personal Computer). A client application for the target application can be installed and run on Terminal 110. This target application can be any of the following: Virtual Reality (VR) application, Augmented Reality (AR) application, 3D mapping application, First-Person Shooter (FPS) game, Third-Person Shooter (TPS) game, Multiplayer Online Battle Arena (MOBA) game, Strategy Game (SLG), Party Game, Building Game, Open World Game, Survival Role-Playing Game, etc. Furthermore, this application does not limit the form of the target application, including but not limited to Apps (Applications), mini-programs, etc., installed on Terminal 110, and can also be in web page form.

[0037] The target server 120 or the original server 130 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, a cloud server providing basic cloud computing services, or a node in a blockchain system. This application embodiment does not limit these possibilities.

[0038] In some embodiments, the target server 120 and the origin server 130 described above can be implemented as dedicated servers (DS). Illustratively, in a target application that supports virtual worlds, the target server 120 and the origin server 130 are used to manage different virtual worlds. The following explanation uses the example of the target server 120 managing a first virtual world and the origin server 130 managing a second virtual world.

[0039] Different virtual worlds contain different player groups. For example, player A belongs to the first virtual world, and player B belongs to the second virtual world. When player B logs into the target application's client using the first account, the client will display the screen corresponding to the second virtual world by default. The second virtual world includes the first virtual character controlled by player B through the first account. The client includes a world entry portal for entering the first virtual world. When player B triggers this world entry portal in the client, the client sends a world entry request to the target server 120. This world entry request is used to request the first account to cross-server access to the first virtual world managed by the target server 120.

[0040] Upon receiving the world entry request, target server 120 first obtains cross-server occupancy information. This information indicates the current load of cross-server accounts on target server 120, such as the number of cross-server accounts currently loaded on target server 120. After obtaining the cross-server occupancy information, target server 120 determines whether it meets the first occupancy requirement. For example, it checks whether the number of cross-server accounts currently loaded on target server 120 reaches a preset account threshold. If it does not reach the preset account threshold, the cross-server occupancy information is determined to meet the first occupancy requirement; if it does reach the preset account threshold, the cross-server occupancy information is determined to not meet the first occupancy requirement.

[0041] If the cross-server access information meets the first access requirement, the target server 120 will establish cross-server access permissions for the first account to the target server 120; if the first account has cross-server access permissions to the target server 120, the target server 120 will generate the first display data and send the first display data to the client; after receiving the first display data, the client will display the screen of the first virtual world on the client.

[0042] In some embodiments, the target server 120 includes a first server process and a mirror server process. The first server process refers to the running process of the first virtual world, and the mirror server process is used to back up the data in the first server process. If the cross-server occupancy information does not meet the first occupancy requirements, the target server 120 will create a mirror virtual world of the first virtual world through the mirror server process and generate mirror display data; then, it will send the mirror display data to the client; after receiving the mirror display data, the client will display the image of the mirror virtual world. The first server process and the mirror server process may run on the same server, or they may run on different servers. When the first server process and the mirror server process run on different servers, the target server 120 can be implemented as a first server cluster. For example, assuming the first server process is implemented as a first DS process, the first server cluster includes a first DS and a mirror DS. The first DS is used to run the first DS process, and the mirror DS is used to run the mirror DS process.

[0043] Next, the process of the cross-server access method for the virtual world provided in this application will be introduced.

[0044] Based on the above introduction, Figure 2 This is a flowchart of a cross-server access method for a virtual world provided in an embodiment of this application. Taking the application of this method to a target server 120 as an example, the target server 120 can be implemented as a first server. The method includes steps 210 to 230.

[0045] Step 210: Upon receiving the world entry request sent by the first account, obtain cross-server occupancy information.

[0046] The World Entry Request is used to request the first account to enter the first virtual world managed by the first server across servers. For illustration, the first account is logged into the target application's client. The client provides a first virtual world and a second virtual world. The first account belongs to the second virtual world, which is managed by the second server. Currently, the first account is in the second virtual world; that is, the current client displays the second virtual world.

[0047] In some embodiments, the first account corresponds to a first virtual character, and the second virtual world displayed by the client includes the first virtual character. The first account entering the first virtual world managed by the first server is also called: the first virtual character entering the first virtual world from the second virtual world.

[0048] Among them, the cross-server occupancy information is used to indicate the load status of cross-server accounts in the current first server.

[0049] Optionally, cross-server occupancy information includes at least one of the following:

[0050] (1) Number of cross-server accounts.

[0051] The number of cross-server accounts indicates the number of cross-server accounts currently loaded on the first server.

[0052] A cross-server account is an account that enters the first virtual world from another server, such as the "first account." For example, account 'a' belongs to a virtual world other than the first virtual world. When account 'a' successfully enters the first virtual world, it becomes a cross-server account on the first server. The number of cross-server accounts refers to the number of cross-server accounts currently active on the first server.

[0053] (2) Current resource usage of cross-server accounts.

[0054] The current resource usage of cross-server accounts indicates the resource usage of cross-server accounts on the first server at the current moment. The resources used by cross-server accounts include at least one of the following: memory resources, CPU (Central Processing Unit) resources, network bandwidth resources, and storage resources.

[0055] To illustrate, let's take the resources occupied by a cross-server account, including memory, CPU, network bandwidth, and storage, as an example. We obtain the total amount of memory, CPU, network bandwidth, and storage resources occupied by all cross-server accounts on the first server. We then normalize these total resources to obtain the normalized total memory as the first resource quantity, the normalized total CPU as the second resource quantity, the normalized total network bandwidth as the third resource quantity, and the normalized total storage as the fourth resource quantity. Finally, we perform a weighted summation of these four resource quantities to obtain the current resource usage of the cross-server account. The weights for each of the four resource quantities can be pre-defined.

[0056] (3) Cross-server account activity.

[0057] Cross-server account activity is used to indicate the activity level of cross-server accounts on the first server. For example, it can be determined by at least one of the following: the frequency of cross-server account logins, the number of times tasks (tasks in the first virtual world) are participated in, and the movement range in the first virtual world. The method for calculating cross-server account activity can be found in the introduction to calculating the activity of accounts on the local server in step 220 below, which will not be repeated here.

[0058] (4) Cross-server account task progress distribution.

[0059] Cross-server account task progress distribution indicates the distribution of the number of cross-server accounts at at least one task progress level under the load of the first server. At least one task progress level refers to the task progress in the first virtual world. For illustration, the first virtual world contains at least one task. The distribution retrieves the task progress associated with all cross-server accounts under the load of the first server, and counts the number of cross-server accounts that have just started executing a task (e.g., task progress from 0% to 30%), the number of cross-server accounts that are close to halfway through the task (e.g., task progress from 30% to 50%), and the number of cross-server accounts that are about to complete the task or have already completed the task (e.g., task progress from 50% to 100%).

[0060] Step 220: If the cross-server occupancy information meets the first occupancy requirement, establish cross-server access permissions for the first account to the first server.

[0061] To illustrate, establishing cross-server access permissions for the first account to the first server means performing an account addition operation. This operation adds the first account to the access account management list corresponding to the first server. Once the first account is successfully added to the access account management list, it indicates that the first account has cross-server access permissions to the first server.

[0062] Optionally, the cross-server occupancy information meeting the first occupancy requirement includes at least one of the following:

[0063] (1) The number of cross-server accounts is less than the account number threshold.

[0064] Optionally, if the number of cross-server accounts is less than the account number threshold, determine that the cross-server occupancy information meets the first occupancy requirement, and establish cross-server access permissions for the first account to the first server.

[0065] In the above solution, by setting a threshold for the number of accounts and allowing new accounts (such as the first account) to enter the first virtual world only when the number of cross-server accounts is less than the threshold, it is possible to effectively prevent the first server from becoming overloaded due to an influx of too many cross-server accounts.

[0066] In some embodiments, the account quantity threshold is a pre-set threshold. Illustratively, in the first virtual world, an account quantity threshold is set for cross-server accounts, which is used to limit the number of cross-server accounts entering the first virtual world. If the number of cross-server accounts currently loaded on the first server is greater than or equal to the account quantity threshold, new cross-server accounts are not allowed to enter the first virtual world. If the number of cross-server accounts currently loaded on the first server is less than the account quantity threshold, new cross-server accounts are allowed to enter the first virtual world.

[0067] In other embodiments, the aforementioned account number threshold is a dynamically changing threshold. Optionally, the method for determining the account number threshold includes at least one of the following methods:

[0068] Method 1: Obtain the number of accounts requesting cross-server access to the first virtual world; based on the number of requesting accounts and the cross-server access success rate corresponding to the first virtual world, determine the threshold for the number of accounts corresponding to the first server.

[0069] As an illustration, the first server counts the number of accounts corresponding to all currently unprocessed world entry requests. The first server analyzes historical data on past cross-server entry situations in the first virtual world to calculate the cross-server entry success rate. For example, it calculates the percentage of accounts that successfully entered the first virtual world out of all accounts that initiated cross-server entry requests over a past period (such as the past month or quarter), using this percentage as the cross-server entry success rate.

[0070] After obtaining the number of requesting accounts and the cross-server entry success rate, the initial account number threshold for the first server is obtained. The account number threshold is then determined based on the number of requesting accounts, the cross-server entry success rate, and the initial account number threshold. Optionally, the initial account number threshold is a pre-set maximum cross-server account capacity for the first server. For example, if the number of requesting accounts is 100, the cross-server entry success rate is 70%, and the initial account number threshold is 500, then the account number threshold = 500 - 100 × 70% = 430.

[0071] In Method 1 above, the account number threshold can be dynamically adjusted based on the actual number of accounts requesting cross-server access to the first virtual world and the historical cross-server access success rate. By statistically analyzing the number of requesting accounts in real time and combining it with past cross-server access success rates, the account number threshold can be adjusted promptly, allowing the server to flexibly handle cross-server requests with varying traffic volumes.

[0072] Method 2: Obtain the account activity level of the account corresponding to the first server; determine the threshold for the number of accounts corresponding to the first server based on the account activity level.

[0073] Among them, the "this server account" is used to indicate the account belonging to the first virtual world. The account activity of the "this server account" is negatively correlated with the threshold of the number of accounts corresponding to the first server.

[0074] This is illustrated by determining the activity level of a server account based on at least one of the following: login frequency of the account within a historical time period, number of tasks participated in (tasks in the first virtual world), and movement range within the first virtual world. After determining the activity level of the server account, a threshold for the number of candidate accounts corresponding to the first server is obtained; a weight is determined based on the account activity level of the server account; and the threshold for the number of candidate accounts is adjusted according to the weight to obtain the threshold for the number of accounts corresponding to the first server.

[0075] The proposed method for determining the activity level of a server account is as follows: Account activity is measured by three metrics: login frequency, number of tasks (in the first virtual world), and movement range within that virtual world over a historical period. For illustration, different weights are assigned to different activity metrics. For example, the weight for task participation is set to 0.5, login frequency to 0.3, and movement range to 0.2 (total weights are 1). The activity score for each server account is calculated according to the assigned weights: Activity Score = Login Frequency (normalized to 0-1) × corresponding weight + Number of Task Participations (normalized to 0-1) × corresponding weight + Movement Range (normalized to 0-1) × corresponding weight. The sum of all activity scores for all server accounts is then calculated as the server account's overall activity level.

[0076] Then, the adjustment weight is determined based on the activity score. Different activity scores correspond to different adjustment weights. Assuming the adjustment weight ranges from 0.8 to 1.2, the higher the activity score, the lower the adjustment weight. The lowest adjustment weight is 0.8, in which case the threshold for the number of accounts corresponding to the first server is 80% of the threshold for the number of candidate accounts; the highest adjustment weight is 1.2, in which case the threshold for the number of accounts corresponding to the first server is 120% of the threshold for the number of candidate accounts.

[0077] In Method 2 above, by linking the activity level of local accounts with the account quantity threshold, the server can dynamically adjust the number of cross-server accounts it can accept based on the activity level of local accounts, thereby better balancing the resource allocation between local and cross-server accounts and flexibly balancing the server load.

[0078] (2) The current resource usage of the cross-server account is less than the first resource threshold.

[0079] Optionally, if the current resource usage of the cross-server account is less than the first resource threshold, the cross-server usage information is determined to meet the first usage requirement, and cross-server access permissions for the first account to the first server are established.

[0080] For illustrative purposes, the current resource usage of a cross-server account is used to indicate the resource usage of all cross-server accounts on the first server at the current moment. The first resource threshold is the maximum amount of resources pre-allocated to cross-server accounts on the first server. When the current resource usage of a cross-server account is less than the first resource threshold, it is determined that the cross-server usage information meets the first usage requirement. If the current resource usage of a cross-server account is greater than or equal to the first resource threshold, it is determined that the cross-server usage information does not meet the first usage requirement.

[0081] In the above solution, by setting a first resource threshold and allowing new accounts (such as the first account) to access the server only when the current resource usage of the cross-server account is less than the threshold, it can ensure that the server will not experience slow response, lag, or even crash due to excessive resource usage at any given moment, thus maintaining the normal operation of the server.

[0082] (3) The expected resource consumption of cross-server accounts is less than the second resource threshold.

[0083] Optionally, if the expected resource usage of the cross-server account is less than the second resource threshold, the cross-server usage information is determined to meet the first usage requirement, and cross-server access permissions for the first account to the first server are established.

[0084] Among them, the cross-server account expected resource consumption is used to indicate the estimated resource consumption of cross-server accounts on the first server within the expected time period. The expected time period refers to the time period after the current moment.

[0085] Optionally, methods for determining expected resource consumption may also include: predicting the expected resource consumption of cross-server accounts based on cross-server account activity and cross-server account task progress distribution.

[0086] In some embodiments, a resource consumption prediction model corresponding to the first virtual world is obtained, and the cross-server account activity and cross-server account task progress distribution are input into the resource consumption prediction model to output the expected resource consumption of the cross-server account. The resource consumption prediction model is a pre-trained neural network model.

[0087] The training process for the resource consumption prediction model is as follows: First, sample data for the first historical time period is acquired. This sample data includes the cross-server account activity and cross-server account task progress distribution for the first virtual world within the first historical time period. Then, the cross-server account resource consumption for the second historical time period is obtained as a reference resource consumption. The first historical time period precedes the second historical time period. The reference resource consumption is used to indicate the actual resource consumption of the cross-server accounts loaded on the first server within the second historical time period.

[0088] The sample data is input into the sample prediction model, which analyzes the data to obtain the corresponding sample feature representation. The model then analyzes this feature representation to obtain the predicted resource usage, which indicates the estimated resource usage of cross-server accounts on the first server within the second historical time period. A first loss is determined based on the difference between the predicted and reference resource usage, and this first loss is used to train the sample prediction model.

[0089] The sample prediction model is iteratively trained using multiple sample data and their corresponding reference resource occupancy values ​​until the first loss calculated by the sample prediction model is less than the preset loss value, or the number of training iterations of the sample prediction model reaches the preset number. At this point, the training stops, and the model obtained is the resource occupancy prediction model.

[0090] The above solution considers the expected resource consumption of cross-server accounts and compares it with the second resource threshold, enabling the server to plan resource allocation in advance. This helps to detect and prevent potential resource overload situations in advance, effectively reducing the risk of overload and ensuring that the server can operate stably for a period of time in the future.

[0091] In some embodiments, if the cross-server occupancy information meets the first occupancy requirement, cross-server access permissions for the first account to the first server are established based on the cross-server access request sent by the second server.

[0092] The second server is used to manage the second virtual world, and the first account belongs to the second virtual world.

[0093] As an illustration, when the cross-server occupancy information meets the first occupancy requirement, the first server sends a cross-server notification message to the second server. This cross-server notification message is used to notify the second server that the cross-server occupancy information meets the first occupancy requirement. After receiving the cross-server notification message, the second server sends a cross-server access request to the first server. This cross-server access request is used to request the establishment of cross-server access permissions for the first account to the first server.

[0094] In the above scheme, the first server can decide whether to accept a new cross-server account (first account) based on its current cross-server account load. Only when conditions permit will permissions be granted through a request from the second server, thus effectively avoiding problems such as excessive resource consumption and server performance degradation caused by arbitrarily granting cross-server accounts.

[0095] Optionally, the cross-server access request includes the first account data of the first account. If the cross-server occupancy information meets the first occupancy requirement, the first account data is obtained based on the cross-server access request sent by the second server. If the first account data meets the second occupancy requirement, cross-server access permissions of the first account to the first server are established.

[0096] It should be noted that the above requirements regarding the first account data and the second occupation are... Figure 3 Steps 321 to 324 will be explained in detail, and will not be repeated here.

[0097] Step 230: If the first account has cross-server access permissions, send the first display data to the first account.

[0098] The first display data is used to provide the first account with the display screen of the first virtual world.

[0099] In some embodiments, the first account corresponds to a first virtual character, and the cross-server access request includes the first character data corresponding to the first virtual character.

[0100] For illustrative purposes, the first character data is used to create the first virtual character in the first virtual world. The first character data includes, but is not limited to, basic character attribute data (such as character level, character type, character intelligence points, character stamina points, etc.), character equipment data, character skill data, character resource data (such as virtual gold coins owned by the character, etc.), character appearance data (such as virtual outfits, virtual mounts, etc.), character quest data, etc.

[0101] Optionally, if the first account has cross-server access to the first server, first display data is generated based on the first character data in the cross-server access request. The first display data is used to provide the first account with a display screen of the first virtual world containing the first virtual character.

[0102] To illustrate, after obtaining the first character data, the first server constructs the first virtual character based on the first character data, and then renders the first virtual character into the first virtual world to obtain the first display data. The first server provides the first display data to the first account in real time, so that the first virtual world containing the first virtual character is displayed on the client logged in by the first account.

[0103] In the above scheme, the first display data is generated based on the first character data in the cross-server access request, which can completely present the player's first virtual character in the original virtual world (or the second virtual world to which they belong) in the first virtual world after the cross-server access.

[0104] Optionally, if the first account logs out of the first virtual world, retrieve the character update data corresponding to the first virtual character; and send the character update data to the second server.

[0105] The second server is used to write character update data into the database.

[0106] This is illustrative; the character update data indicates changes to the first virtual character while active in the first virtual world. Character update data includes, but is not limited to: character basic attribute update data, character equipment update data, character skill update data, character resource update data, character appearance update data, and character quest update data. When the first account logs out of the first virtual world, the first server retrieves the character update data and then sends the corresponding character update data for the first virtual character to the second server, which stores the character update data in its database. This character update data is used to update the display of the first virtual character in the second virtual world.

[0107] In some embodiments, when a first account exits the first virtual world, a return access request is sent to the second server. This return access request is used to request the first account to return to the second virtual world managed by the second server, where the first account belongs. The second server then sends second display data to the first account based on the return access request. This second display data provides the first account with a display screen of the second virtual world.

[0108] To illustrate, after the aforementioned cross-server process is completed, the first account is currently in the first virtual world. When the first account wants to return to the second virtual world, it can trigger a world exit operation in the target application's client, i.e., exit the first virtual world. Upon triggering the world exit operation, the first server will send a return access request to the second server. Upon receiving the return access request, the second server will generate second display data and send it to the client. After receiving the second display data, the client will display the second virtual world based on the second display data, thus completing the process of the first account returning to the second virtual world.

[0109] Optionally, the second server is also used to: send second display data to the first account if the first account has access to the second virtual world. For example, after receiving a return access request, the second server will determine whether the first account has access to the second virtual world, such as whether the first account is in the "native list" corresponding to the second virtual world. If it is, then the first account has access to the second virtual world; otherwise, the first account does not have access to the second virtual world.

[0110] In some embodiments, a first account corresponds to a first virtual character. Optionally, when the first account exits the first virtual world, the character update data corresponding to the first virtual character is obtained. The character update data is used to indicate the character changes that occurred when the first virtual character was active in the first virtual world; a return access request is generated based on the character update data. The second server is used to parse the return access request to obtain the character update data and write the character update data into a database.

[0111] In a schematic scenario, when a world exit operation is triggered, the first server generates character update data based on the character changes that occurred during the first virtual character's activities in the first virtual world. This updated data is then packaged into a return-to-server access request. The first server sends the return-to-server access request to the second server. Upon receiving the request, the second server parses it to obtain the character update data. The second server then writes this data into its database, ensuring that all character-related data is written to the database by the second server. This avoids the storage resource waste caused by multiple points (e.g., the first and second servers) writing character-related data.

[0112] In summary, the cross-server access method for virtual worlds provided in this application, when receiving a world entry request sent by a first account, obtains the load status of cross-server accounts in the current first server by acquiring cross-server occupancy information, and determines whether to allow the first account to cross-server enter the first virtual world managed by the first server by judging whether the load status meets the first occupancy requirement. This prevents the first server from being overloaded by too many cross-server accounts, thereby avoiding problems such as longer response time, downtime, and crashes caused by excessive load pressure on the first server, and ensuring the stable operation of the first server.

[0113] In some embodiments, the cross-server access request includes a first cross-server access request and a second cross-server access request. After determining that the cross-server occupancy information meets the first occupancy requirement, cross-server access permissions for the first account to the first server are established through a two-stage cross-server access request. For illustrative purposes, please refer to [reference needed]. Figure 3 The above Figure 2 The illustrated embodiment can also be implemented as follows: steps 310 to 330.

[0114] Step 310: Upon receiving the world entry request sent by the first account, obtain cross-server occupancy information.

[0115] The World Entry Request is used to request the first account to enter the first virtual world managed by the first server. Optionally, the first account belongs to the second virtual world, which is managed by the second server, and the first account is currently in the second virtual world. The cross-server occupancy information indicates the current load status of cross-server accounts on the first server.

[0116] Step 321: If the cross-server occupancy information meets the first occupancy requirement, receive the first cross-server access request sent by the second server.

[0117] The second server is used to manage the second virtual world, and the first account belongs to the second virtual world.

[0118] Indicatively, the first cross-server access request is a cross-server access request sent by the second server to the first server during the cross-server preparation phase. The first cross-server access request includes the first account data corresponding to the first account.

[0119] Optionally, the first account data corresponding to the first account includes, but is not limited to, account level, current access time, account type, and first character data, etc., which are not limited here. For illustration purposes, account level refers to the account level of the first account, current access time indicates the time when the first server receives the first cross-server access request sent by the first server, account type refers to the account type of the first account, and the first character data includes character equipment information, which refers to the equipment currently owned by the first virtual character corresponding to the first account.

[0120] Step 322: Based on the first cross-server access request, obtain the first account data corresponding to the first account.

[0121] As an illustration, after receiving the first cross-server access request, the first server parses the first cross-server access request and obtains the first account data corresponding to the first account.

[0122] Step 323: If the first account data meets the second occupancy requirements, receive the second cross-server access request sent by the second server.

[0123] Optionally, the first account data meeting the second occupancy requirement includes at least one of the following:

[0124] (1) The account level of the first account meets the account level requirements of the first virtual world.

[0125] As an illustration, in the cross-server access mechanism of virtual worlds, each virtual world (such as the first virtual world) sets corresponding account level requirements. After receiving a cross-server access request sent by the first account and obtaining its account level data, the server compares the level value with the preset level requirements of the first virtual world to determine whether it meets the conditions. Accounts that meet the requirements also meet the level access conditions of the first virtual world.

[0126] (2) The current access time of the first account is within the opening time range of the first virtual world.

[0127] The open time range refers to the time range during which cross-server access to the first virtual world is permitted.

[0128] To illustrate, the first virtual world has a set opening time range, such as 10:00 AM to 10:00 PM daily, during which cross-server access is allowed, while cross-server access is prohibited at other times. When the first server receives the first cross-server access request from the first account, it records and obtains the arrival time of the request (i.e., the first account's current access time), and then compares this time with the pre-set opening time range of the first virtual world. If the current access time is within the opening time range, it meets the opening time access conditions of the first virtual world.

[0129] (3) The account type of the first account meets the access type requirements of the first virtual world.

[0130] As an illustration, the access type requirements of the first virtual world clearly define which account types can enter across servers. After obtaining the account type data of the first account, the first server will check it against the access type requirements set by the first virtual world to determine whether the account type is within the allowed range. Accounts that meet the requirements also meet the type access conditions of the first virtual world.

[0131] (4) The equipment attributes of the first account meet the equipment configuration requirements set by the first virtual world.

[0132] For illustrative purposes, equipment configuration requirements may include equipment type requirements, equipment level requirements, etc., which are not specified here. The equipment configuration requirements of the first virtual world clearly stipulate which equipment can be used across servers. After receiving a cross-server access request from the first account and obtaining its character's equipment status data, the server will check whether the attributes of each piece of equipment meet the equipment configuration requirements set by the first virtual world. Only accounts whose attributes of all equipment are within the specified range meet the equipment access conditions of the first virtual world.

[0133] It should be noted that the above description of the second occupancy requirement is merely an illustrative example, and the embodiments of this application do not limit it.

[0134] The above solution further restricts the first account's cross-server entry into the first virtual world by considering factors such as account level, current access time, account type, and account equipment attributes. This prevents the first account from performing cross-server operations without restriction, thereby avoiding unnecessary resource consumption and reducing server load.

[0135] Indicatively, the second cross-server access request is a cross-server access request sent by the second server to the first server during the formal cross-server phase. The second cross-server access request includes the first account data corresponding to the first account.

[0136] Optionally, the first account data corresponding to the first account includes, but is not limited to, account level, current access time, account type, and first character data, etc., which are not limited here. The first account data obtained by the first server during the preparation phase and the official cross-server phase can be the same or different, which are not limited here.

[0137] Step 324: Based on the second cross-server access request, establish cross-server access permissions for the first account to the first server.

[0138] Optionally, after receiving the second cross-server access request, the first server establishes cross-server access permissions for the first account to the first server.

[0139] To illustrate, establishing cross-server access permissions for the first account to the first server means performing an account addition operation. This operation adds the first account to the access account management list corresponding to the first server. Once the first account is successfully added to the access account management list, it indicates that the first account has cross-server access permissions to the first server.

[0140] This is illustrative; please refer to it. Figure 4 It illustrates a two-stage cross-server access request, such as... Figure 4 As shown, the computer system includes a source server 410 and a target server 420. The source server 410 manages the second virtual world, and the target server 420 manages the first virtual world. The source server 410 can be implemented as the second server described above, and the target server 420 can be implemented as the first server described above.

[0141] The original server 410 includes a second DS process 411, which refers to the running process of the second virtual world. The second DS process 411 is responsible for maintaining the game logic of the second virtual world. For example, when a player controls the first virtual character to perform various operations in the second virtual world, the second DS process 411 is responsible for handling these operations. Optionally, the original server 410 is implemented as a second server cluster, which includes a second DS, and the second DS process 411 runs in the second DS.

[0142] The target server 420 includes a first DS process 421. The first DS process 421 is used to instruct the running process of the first virtual world. The first DS process 421 is responsible for maintaining the game logic of the first virtual world; for example, when a player controls a first virtual character to perform various operations in the first virtual world, the first DS process 421 is responsible for handling these operations. Optionally, the target server 420 is implemented as a first server cluster, which includes a first DS, and the first DS process 421 runs in the first DS.

[0143] In this embodiment of the application, the cross-server access request sent by the second DS process 411 includes a preparatory cross-server access request (i.e., the first cross-server access request mentioned above) and a formal cross-server access request (i.e., the second cross-server access request mentioned above).

[0144] For preparing cross-server access requests:

[0145] The second DS process 411 sends a cross-server access request to the first DS process 421. After receiving the cross-server access request, the first DS process 421 executes a preprocessing procedure. This preprocessing procedure includes determining whether the first account data of the first account meets the second occupancy requirements. The explanation of the second occupancy requirements has been given in step 323 above and will not be repeated here.

[0146] For formal cross-server access requests:

[0147] After the preprocessing process of the first DS process 421 is completed, if the first DS process 421 determines that the first account data of the first account meets the second occupancy requirements, then the first DS process 421 sends a result of preparing a cross-server access request to the second DS process 411. This request result is used to indicate to the second DS process 411 that it can enter the formal cross-server access process. Then the second DS process 411 sends a formal cross-server access request to the first DS process 421. After receiving the formal cross-server access request, the first DS process 421 constructs the first virtual character corresponding to the first account.

[0148] Indicatively, the formal cross-server access request sent by the first DS process 421 to the second DS process 411 includes the first character data of the first virtual character. The first DS process 421 can construct the first virtual character based on the first character data, and then render the first virtual character in the first virtual world to obtain the first display data, which is the first virtual world containing the first virtual character.

[0149] After the first DS process 421 finishes executing the process of building the first virtual character, the first DS process 421 will send the formal cross-server access request result to the second DS process 411. The formal cross-server access request result is used to notify the second DS process 411 that the current first virtual character has successfully accessed the first virtual world across servers.

[0150] In some embodiments, when the first account exits the first virtual world, a return access request is sent to the second server. The return access request is used to request the first account to return to the second virtual world managed by the second server, and the first account belongs to the second virtual world.

[0151] Optionally, the return access request includes a first return access request and a second return access request. The first return access request refers to the return access request sent by the first server to the second server during the preparation phase, and the second return access request refers to the return access request sent by the first server to the second server during the formal return phase.

[0152] Step 330: If the first account has cross-server access permissions, send the first display data to the first account.

[0153] The first display data is used to provide the first account with the display screen of the first virtual world.

[0154] In some embodiments, the first account corresponds to a first virtual character, and the second cross-server access request includes the first character data corresponding to the first virtual character.

[0155] Optionally, if the first account has cross-server access to the first server, first display data is generated based on the first character data in the second cross-server access request. The first display data is used to provide the first account with a display screen of the first virtual world containing the first virtual character.

[0156] In summary, the cross-server access method for virtual worlds provided in this application restricts players' cross-server behavior by setting a first occupancy requirement and a second occupancy requirement. The first occupancy requirement focuses on the server load, restricting players' cross-server behavior from the perspective of server resource capacity. The second occupancy requirement focuses on the compatibility between the cross-server account data and the first virtual world, restricting players' cross-server behavior from the perspective of account matching with the first virtual world. This prevents the first server from being overloaded with too many cross-server accounts, thereby avoiding problems such as longer response times, downtime, and crashes caused by excessive load on the first server, and ensuring the stable operation of the first server.

[0157] In some embodiments, if the cross-server occupancy information does not meet the first occupancy requirement, the first account will be controlled to enter the mirror virtual world corresponding to the first virtual world. This is illustrative; please refer to [the original text]. Figure 5 The above Figure 2 or Figure 3 The illustrated embodiment also includes steps 501 to 502.

[0158] Step 501: If the cross-server occupancy information does not meet the first occupancy requirement, create a mirror virtual world corresponding to the first virtual world through the mirror server process.

[0159] Optionally, the cross-server occupancy information not meeting the first occupancy requirement includes at least one of the following:

[0160] (1) The number of cross-server accounts is greater than or equal to the account number threshold.

[0161] Optionally, if the number of cross-server accounts is greater than or equal to the account number threshold, it is determined that the cross-server occupancy information does not meet the first occupancy requirement.

[0162] (2) The current resource usage of the cross-server account is greater than or equal to the first resource threshold.

[0163] Optionally, if the current resource usage of a cross-server account is greater than or equal to the first resource threshold, it is determined that the cross-server usage information does not meet the first usage requirement.

[0164] (3) The expected resource consumption of cross-server accounts is greater than or equal to the second resource threshold.

[0165] Optionally, if the expected resource usage of a cross-server account is greater than or equal to the second resource threshold, it is determined that the cross-server usage information does not meet the first usage requirement.

[0166] After determining that the cross-server occupancy information does not meet the first occupancy requirement, a mirror virtual world corresponding to the first virtual world is created on the mirror server.

[0167] To illustrate, the aforementioned first server runs a first server process and a mirror server process. The first server process refers to the running process of the first virtual world, which is responsible for maintaining the game logic of the first virtual world. The mirror server process is mainly used to create and maintain copies of the original virtual world (i.e., the first virtual world), which are essentially mirror virtual worlds. The mirror virtual world is basically the same as the original first virtual world in terms of functionality and scenes.

[0168] Optionally, the first server process and the mirror server process run on the same server, or the first server process and the mirror server process run on different servers. When the first server process and the mirror server process run on different servers, the first server can be implemented as a first server cluster. For example, the first server process is implemented as a first DS process. The first server cluster includes a first DS and a mirror DS. The first DS is used to run the first DS process, and the mirror DS is used to run the mirror DS process.

[0169] Step 502: Send image display data to the first account through the image server process.

[0170] The mirrored display data is used to provide the primary account with a view of the mirrored virtual world.

[0171] In some embodiments, the image server process runs on an image server in the first server cluster.

[0172] Optionally, if the cross-server access information does not meet the first access requirement, cross-server access permission for the first account to the mirror server is established based on the cross-server access request sent by the second server; if the first account has cross-server access permission to the mirror server, mirror display data is sent to the first account through the mirror server process running in the mirror server.

[0173] It should be noted that the instructions for establishing cross-server access permissions for the first account to the mirror server can be found in the steps above, which will not be repeated here.

[0174] In some embodiments, the first account corresponds to a first virtual character, and the cross-server access request includes the first character data corresponding to the first virtual character.

[0175] Optionally, if the first account has cross-server access to the mirror server, mirror display data is generated based on the first character data in the cross-server access request. The mirror display data is used to provide the first account with a display screen of the mirror virtual world containing the first virtual character.

[0176] In summary, the cross-server access method for virtual worlds provided in this application can effectively divert traffic when the cross-server occupancy information does not meet the first occupancy requirement by creating a mirror virtual world. This avoids serious service quality issues such as longer response times, lag, or even crashes caused by an influx of too many cross-server accounts into the first virtual world.

[0177] The cross-server access method for virtual worlds provided in this application can be applied to the function of players traversing between various virtual worlds in the game. Please refer to the illustrative example. Figure 6 It shows a schematic diagram of an interface for entering a virtual world across servers.

[0178] like Figure 6 As shown, the virtual character 621 controlled by the player belongs to the second virtual world and can be considered a "native" of the second virtual world. The game provides at least two virtual worlds. When a player wants to control virtual character 621 to enter another virtual world (e.g., the first virtual world), they can trigger an entry point in the game client to enter that other virtual world. For example, when a player triggers the entry point to enter the first virtual world in the game client, a loading screen 610 will be displayed. During the loading of this loading screen 610, the game client's backend server (i.e., the first and second servers mentioned above) will perform a background process (i.e., the cross-server access method for virtual worlds mentioned above). Once loading is complete, the background process ends. If loading is successful, the game client will display the first virtual world's display screen 620, which includes the first virtual character 621, indicating that the first virtual character 621 has entered the first virtual world from the second virtual world.

[0179] The following describes the cross-server access method for players to enter the first virtual world.

[0180] (I) Implementation architecture of cross-server access method in virtual world.

[0181] Please refer to Figure 7 It shows a structural diagram of a cross-server access method in a virtual world.

[0182] The game client's backend servers include the original server (also known as the second server mentioned above) and the target server (also known as the first server mentioned above). The original server manages the second virtual world, and the target server manages the first virtual world. A first account is logged in within the game client, and this first account belongs to the second virtual world.

[0183] The target server includes: a first DS process 711, a first management process 712, and a first cache process 713. The first DS process 711 refers to the running process of the first virtual world, i.e., the server process of the first DS, responsible for maintaining the game logic of the first virtual world. The first management process 712 refers to the management process of the virtual world in the first server cluster, responsible for functions such as pulling the world list, creating worlds, entering worlds, and leaving worlds within the first server cluster. The first cache process 713 is used to provide caching functionality for account data in the first server cluster. The first DS process 711, the first management process 712, and the first cache process 713 can run on the same server, or they can run on different servers. When the first DS process 711, the first management process 712, and the first cache process 713 run on different servers, the target server can be implemented as a first server cluster. Illustratively, the first server cluster includes a first DS running the first DS process 711, a first management server running the first management process 712, and a first cache server running the first cache process 713.

[0184] The original server includes: a second DS process 721, a second management process 722, and a second cache process 723. The second DS process 721 refers to the running process of the second virtual world, i.e., the server process of the second DS, responsible for maintaining the game logic of the second virtual world. The second management process 722 refers to the management process of the virtual world in the second server cluster, responsible for functions such as pulling the world list, creating worlds, entering worlds, and leaving worlds. The second cache process 723 is used to provide caching functionality for account data in the second server cluster. The second DS process 721, the second management process 722, and the second cache process 723 can run on the same server, or they can run on different servers. When the second DS process 721, the second management process 722, and the second cache process 723 run on different servers, the original server can be implemented as a second server cluster. Illustratively, the second server cluster includes a second DS running the second DS process 721, a second management server running the second management process 722, and a second cache server running the second cache process 723.

[0185] When a player uses their first account to control a first virtual character and enters the first virtual world across servers in the game client, a cross-server process from the second DS process 721 to the first DS process 711 is triggered. At this time, the second DS process 721 packages the account data of the first account and transmits it to the first DS process 711. The first DS process 711 caches the account data of the first account in the first cache process 713 for use in subsequent processes. The account data of the first account includes the context information and character transmission data described below.

[0186] When a player uses their first account to control their first virtual character and enters the second virtual world in the game client, a server return process from the first DS process 711 to the second DS process 721 is triggered. At this time, the first DS process 711 packages the account settlement data generated by the first account in the first virtual world and transmits it to the second DS process 721. The second DS process 721 then stores the account settlement data of the first account in database 730. This account settlement data includes character update data and offline data, as described below.

[0187] The following is combined Figure 8 and Figure 9 The cross-server process and the return-to-server process are explained in detail.

[0188] (ii) Cross-server process in cross-server access methods in the virtual world.

[0189] Please refer to Figure 8 It shows an interactive flowchart of the cross-server process in a cross-server access method in a virtual world, which includes the following processes.

[0190] Cross-server preparation phase:

[0191] 1. Client process 801 sends a world entry request to game server process 802.

[0192] The player's first virtual character is currently in the second virtual world. When the player wants the first virtual character to enter the first virtual world across servers, they can trigger the world entry operation in the client. Client process 801 is running in the client. At this time, client process 801 will generate a world entry request. The world entry request includes the identifier of the virtual world that the first account needs to enter across servers, that is, the world ID of the first virtual world.

[0193] The client process 801 sends a world entry request to the game server process 802. The game server process 802 runs on the game server, which is responsible for receiving connection requests from player clients. For example, when a player tries to access (or log in to) the first DS, the client sends a world entry request to the game server.

[0194] 2. Game server process 802 forwards the world entry request to the first management process 803.

[0195] After receiving the world entry request, the game server process 802 determines the cross-server target, namely the first virtual world, based on the identifier of the virtual world in the world entry request. After determination, the game server process 802 sends the world entry request to the first management process 803, which is the management process corresponding to the first virtual world.

[0196] 3. The first management process 803 sends a cross-server preparation request to the second DS process 804.

[0197] After receiving the world entry request, the first management process 803 first obtains the cross-server occupancy information corresponding to the first DS process 805. If it is determined that the cross-server occupancy information meets the first occupancy requirement, it sends a cross-server preparation request to the second DS process 804. For example, the first management process 803 obtains the "number of visitors" (that is, the number of cross-server accounts loaded by the first DS process 805) of the current first DS process 805. If the "number of visitors" is less than the "visitor number threshold", it is determined that the cross-server occupancy information meets the first occupancy requirement.

[0198] The cross-server preparation request is used to request the second DS process to prepare for cross-server operations at 804.

[0199] 4. The second DS process 804 attempts cross-server access for the first time and sends a cross-server access request to the first management process 803.

[0200] The second DS process 804 receives the cross-server preparation request and attempts cross-server access for the first time. That is, the second DS process 804 sends a cross-server access preparation request to the first management process 803.

[0201] 5. The first management process 803 forwards the cross-server access request to the first DS process 805.

[0202] The cross-server access request includes context data and character passthrough data. The context data indicates the cross-server path of the first account, that is, the world the first account is currently in (i.e., the second virtual world) and the virtual world the first account needs to enter (i.e., the first virtual world). The character passthrough data indicates the first account's first account data, which includes the first account's account level, the first virtual character's first character data, etc.

[0203] 6. After the first DS process 805 executes the preprocessing procedure, it sends the result of preparing the cross-server access request to the first management process 803.

[0204] After receiving the cross-server access request, the first DS process 805 executes a preprocessing procedure. This preprocessing procedure includes: obtaining the first account data from the cross-server access request; determining whether the first account data meets the second occupancy requirements, such as whether the account level of the first account is greater than the account level threshold corresponding to the first virtual world; if it is greater, the first account data is deemed to meet the second occupancy requirements; otherwise, it is deemed not to meet the second occupancy requirements. After the preprocessing procedure is completed, the first DS process 805 sends the cross-server access request result to the first management process 803.

[0205] Official cross-server phase:

[0206] 7. The first management process 803 forwards the successful request result to the second DS process 804.

[0207] After receiving the result of the cross-server access request, if the result indicates that the first account data meets the second occupancy requirements, the first management process 803 will forward the successful request result to the second DS process 804. If the result indicates that the first account data does not meet the second occupancy requirements, the first management process 803 will forward the failed request result to the second DS process 804 and terminate the cross-server process.

[0208] 8. The second DS process 804 initiates the second formal cross-server access, sending a formal cross-server access request to the first management process 803.

[0209] If the second DS process 804 receives a successful request result, the second formal cross-server access will be initiated, that is, the second DS process 804 will send a formal cross-server access request to the first management process 803.

[0210] After receiving the formal cross-server access request, the first management process 803 executes the data addition process based on the first account data in the formal cross-server access request, such as adding the first account to the "visitor list" corresponding to the first virtual world. After the first account is successfully added to the "visitor list" corresponding to the first virtual world, the first account will have cross-server access permissions to the first server.

[0211] 9. The first management process 803 forwards the formal cross-server access request to the first DS process 805.

[0212] After confirming that the first account has cross-server access permissions to the first server, the first management process 803 forwards the formal cross-server access request to the first DS process 805. The formal cross-server access request also includes context data and character pass-through data. Optionally, the context data and character pass-through data included in the prepared cross-server access request and the formal cross-server access request are the same.

[0213] 10. After the first DS process 805 executes the virtual character construction process, it sends the result of the formal cross-server access request to the first management process 803.

[0214] After receiving the formal cross-server access request, the first DS process 805 executes the virtual character construction process. The virtual character construction process includes: obtaining the first character data in the formal cross-server access request, constructing the first virtual character based on the first character data, and then rendering the first virtual character in the first virtual world to obtain the first display data.

[0215] 11. The first DS process at 805 notifies the client process at 801 that cross-server communication has been successful.

[0216] The first DS process 805 sends a notification message to the client process 801, notifying the client process 801 that the cross-server operation has been successful. At the same time, the first DS process 805 feeds back the first display data to the client process 801. After receiving the first display data, the client process 801 will display the first virtual world containing the first virtual character, thus completing the first virtual character's transition from the second virtual world to the first virtual world.

[0217] Optionally, if the cross-server occupancy information does not meet the first occupancy requirement, the first management process 803 will send a mirror world creation request to the mirror DS process corresponding to the first DS process 805; after receiving the mirror world creation request, the mirror DS process will obtain the mirror world data corresponding to the first virtual world and create a mirror virtual world of the first virtual world based on the mirror world data; after successfully creating the mirror virtual world, the mirror DS process will send a creation success notification to the first management process 803; after receiving the creation success notification, the first management process 803 will send a cross-server preparation request to the second DS process 804; the second DS process 804 will send a cross-server access preparation request on its first attempt to access the cross-server. The request is sent to the first management process 803; the first management process 803 forwards the cross-server access request preparation to the mirror DS process; after executing the preprocessing flow, the mirror DS process sends the cross-server access request preparation result to the first management process 803; the first management process 803 forwards the successful request result to the second DS process 804; the second DS process 804 initiates the second formal cross-server access, sending the formal cross-server access request to the first management process 803; the first management process 803 forwards the formal cross-server access request to the mirror DS process; after executing the virtual character construction process, the mirror DS process sends the formal cross-server access request result to the first management process 803; the mirror DS process notifies the client process 801 that the cross-server access was successful. For details regarding the mirror DS process's workflow, please refer to the first DS process 805; it will not be elaborated upon here.

[0218] (III) The return process in the cross-server access method in the virtual world.

[0219] Please refer to Figure 9 It shows an interactive flowchart of the return process in a cross-server access method in a virtual world, which includes the following processes.

[0220] Preparation for return to service phase:

[0221] 1. The first DS process 805 writes back offline data in the database process 807.

[0222] The player's first virtual character is currently in the first virtual world. When the player wants the first virtual character to return to the second virtual world, they can trigger a world departure operation in the client. At this time, the first DS process 805 will first write offline data to the database process 807. The offline data is key offline data, mainly related to the first virtual world, such as the resource consumption in the first virtual world (the total amount of resources consumed during the first virtual character's activities in the first virtual world), the resource output (the total amount of resources produced during the first virtual character's activities in the first virtual world), and the changes in the world scene (scenes built or created by the first virtual character in the first virtual world), etc. There are no restrictions here.

[0223] Database process 807 runs on the database, which can be implemented as a distributed database.

[0224] 2. Database process 807 sends a return preparation request to the first DS process 805.

[0225] After successfully writing offline data, database process 807 sends a return preparation request to the first DS process 805. The return preparation request is used to request the first DS process 805 to prepare for return.

[0226] 3. The first DS process 805 attempts to access the server for the first time and sends a request to prepare to access the server to the second management process 806.

[0227] The first DS process 805 receives the return service preparation request and attempts to access the service for the first time. That is, the first DS process 805 sends the return service preparation request to the second management process 806.

[0228] 4. The second management process 806 forwards the request to prepare for the return access to the second DS process 804.

[0229] The request to return to the server includes context data and character pass-through data. The context data indicates the return path for the first account, that is, the world the first account is currently in (i.e., the first virtual world) and the virtual world the first account needs to enter (i.e., the second virtual world). The character pass-through data indicates the first account's first account data, which includes the first virtual character's character update data, offline data, etc.

[0230] 5. After the second DS process 804 executes the preprocessing procedure, it sends the result of the preparation for the return access request to the second management process 806.

[0231] After receiving the request to prepare for a server return access, the second DS process 804 executes a preprocessing procedure. This preprocessing procedure includes determining whether the first account has access permissions to the second virtual world, such as whether the first account is in the corresponding "native list" of the second virtual world. If so, the first account is confirmed to have access permissions to the second virtual world; otherwise, the first account does not have access permissions. After the preprocessing procedure is completed, the second DS process 804 sends the result of the server return access request to the second management process 806.

[0232] Official return phase:

[0233] 6. The second management process 806 forwards the successful request result to the first DS process 805.

[0234] After receiving the result of the request to prepare for a return access, if the result indicates that the first account has access to the second virtual world, the second management process 806 will forward the successful request result to the first DS process 805. If the result indicates that the first account does not have access to the second virtual world, the second management process 806 will forward the failed request result to the first DS process 805 and terminate the return access process.

[0235] 7. The first DS process 805 initiates the second formal return access request, sending a formal return access request to the second management process 806.

[0236] If the first DS process 805 confirms that the request was successfully received, the second formal return access is initiated, that is, the first DS process 805 sends a formal return access request to the second management process 806.

[0237] 8. The second management process 806 forwards the formal return access request to the second DS process 804.

[0238] The official server access request also includes context data and character pass-through data. Optionally, the context data and character pass-through data included in the prepared server access request and the official server access request are the same.

[0239] Among them, the prepared return access request is the first return access request in the return access request mentioned above, and the formal return access request is the second return access request in the return access request mentioned above.

[0240] 9. After the second DS process 804 executes the virtual character construction process, it sends the result of the formal return access request to the second management process 806.

[0241] After receiving the formal server access request, the second DS process 804 executes the virtual character construction process. The virtual character construction process includes: obtaining the character update data and offline data from the formal server access request, reconstructing the first virtual character based on the character update data and offline data, and then rendering the first virtual character in the second virtual world to obtain the second display data.

[0242] 10. The second DS process 804 notifies the client process 801 that the server has successfully returned.

[0243] The second DS process 804 sends a notification message to the client process 801, notifying the client process 801 that the server response was successful. At the same time, the second DS process 804 feeds back the second display data to the client process 801. After receiving the second display data, the client process 801 will display the second virtual world containing the first virtual character, thus completing the transition of the first virtual character from the first virtual world to the second virtual world.

[0244] It should be noted that the process of returning from the mirrored virtual world to the second virtual world can be referenced from the process of returning from the first virtual world to the second virtual world, and will not be repeated here.

[0245] In summary, the cross-server access method for virtual worlds provided in this application can avoid DS overload by obtaining cross-server occupancy information and using a two-stage cross-server access approach. This means that DS will be able to better handle player requests and provide a more stable gaming experience.

[0246] This is illustrative; please refer to it. Figure 10 It shows a structural block diagram of a cross-server access device in a virtual world, such as Figure 10 As shown, the device includes:

[0247] The acquisition module 1010 is used to acquire cross-server occupancy information when it receives a world entry request sent by the first account. The cross-server occupancy information is used to indicate the load status of cross-server accounts in the current first server. The world entry request is used to request the first account to cross-server enter the first virtual world managed by the first server.

[0248] Processing module 1020 is used to establish cross-server access permissions for the first account to the first server when the cross-server occupancy information meets the first occupancy requirements;

[0249] The sending module 1030 is used to send first display data to the first account when the first account has cross-server access to the first server. The first display data is used to provide the first account with the display screen of the first virtual world.

[0250] In some embodiments, the cross-server occupancy information includes the number of cross-server accounts, which indicates the number of cross-server accounts currently under load on the first server; the processing module 1020 is configured to:

[0251] If the number of cross-server accounts is less than the account number threshold, establish the cross-server access permission of the first account to the first server.

[0252] In some embodiments, the processing module 1020 is configured to:

[0253] Obtain the number of accounts currently requesting cross-server access to the first virtual world; based on the number of requesting accounts and the cross-server access success rate corresponding to the first virtual world, determine the threshold number of accounts corresponding to the first server;

[0254] or,

[0255] Obtain the account activity level of the local account corresponding to the first server; determine the account quantity threshold corresponding to the first server based on the account activity level, wherein the local account is used to indicate the account belonging to the first virtual world.

[0256] In some embodiments, the processing module 1020 is used to create a mirror virtual world corresponding to the first virtual world through the mirror server process when the cross-server occupancy information does not meet the first occupancy requirement; the sending module 1030 is used to send mirror display data to the first account through the mirror server process, and the mirror display data is used to provide the first account with the display screen of the mirror virtual world.

[0257] In some embodiments, the processing module 1020 is configured to:

[0258] If the cross-server occupancy information meets the first occupancy requirement, cross-server access permissions for the first account to the first server are established based on the cross-server access request sent by the second server.

[0259] The second server is used to manage the second virtual world, and the first account belongs to the second virtual world.

[0260] In some embodiments, the cross-server access request includes a first cross-server access request and a second cross-server access request; the processing module 1020 is configured to:

[0261] If the cross-server occupancy information meets the first occupancy requirement, the first cross-server access request sent by the second server is received;

[0262] Based on the first cross-server access request, obtain the first account data corresponding to the first account;

[0263] If the first account data meets the second occupancy requirement, the second cross-server access request sent by the second server is received;

[0264] Based on the second cross-server access request, establish cross-server access permissions for the first account to the first server.

[0265] In some embodiments, the first account data meeting the second occupancy requirement includes at least one of the following:

[0266] The account level of the first account meets the account level requirements corresponding to the first virtual world;

[0267] The current access time of the first account is within the opening time range of the first virtual world, which refers to the time range during which cross-server access to the first virtual world is permitted.

[0268] In some embodiments, the first account corresponds to a first virtual character; the cross-server access request includes first character data corresponding to the first virtual character; the sending module 1030 is used for:

[0269] When the first account has cross-server access to the first server, the first display data is generated based on the first character data in the cross-server access request. The first display data is used to provide the first account with a display screen of the first virtual world containing the first virtual character; and the first display data is sent to the first account.

[0270] In some embodiments, the cross-server resource usage information includes the current resource usage of a cross-server account, which indicates the resource usage of the cross-server account on the first server at the current moment; the processing module 1020 is used to:

[0271] If the current resource usage of the cross-server account is less than the first resource threshold, establish cross-server access permissions for the first account to the first server.

[0272] In some embodiments, the sending module 1030 is configured to:

[0273] If the first account exits the first virtual world, a return access request is sent to the second server. The return access request is used to request the first account to return to the second virtual world managed by the second server, and the first account belongs to the second virtual world.

[0274] The second server is used to send second display data to the first account based on the return access request, and the second display data is used to provide the first account with the display screen of the second virtual world.

[0275] In some embodiments, the first account corresponds to a first virtual character; the sending module 1030 is used for:

[0276] When the first account logs out of the first virtual world, obtain the character update data corresponding to the first virtual character. The character update data is used to indicate the character changes that occurred when the first virtual character was active in the first virtual world. Generate the return access request based on the character update data.

[0277] The second server is used to parse the return access request to obtain the character update data and write the character update data into the database.

[0278] In summary, the cross-server access device for the virtual world provided in this application, when receiving a world entry request sent by a first account, obtains the load status of the cross-server account in the current first server by acquiring cross-server occupancy information, and determines whether to allow the first account to cross-server enter the first virtual world managed by the first server by judging whether the load status meets the first occupancy requirement. This prevents the first server from being overloaded by too many cross-server accounts, thereby avoiding problems such as longer response time, downtime, and crashes caused by excessive load pressure on the first server, and ensuring the stable operation of the first server.

[0279] It should be noted that the cross-server access device for the virtual world provided in the above embodiments is only an example of the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the cross-server access device for the virtual world and the cross-server access method embodiments for the virtual world provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0280] This application also provides a computer device, which includes: a processor and a memory, wherein the memory stores a computer program; the processor is used to execute the computer program in the memory to implement the cross-server access method for the virtual world provided in the above method embodiments.

[0281] For example, Figure 11 This is a structural block diagram of a computer device 1100 provided in an exemplary embodiment of this application. Optionally, the computer device 1100 is a server 1100. The server 1100 can be implemented as... Figure 1 The target server is 120 or the original server is 130.

[0282] Typically, server 1100 includes a processor 1101 and memory 1102.

[0283] Processor 1101 may include one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Processor 1101 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). Processor 1101 may also include a main processor and a coprocessor. The main processor, also known as a Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 1101 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 1101 may also include an Artificial Intelligence (AI) processor, which is used to handle computational operations related to machine learning.

[0284] The memory 1102 may include one or more computer-readable storage media, which may be non-transitory. The memory 1102 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 1102 is used to store at least one instruction, which is executed by the processor 1101 to implement the cross-server access method for virtual worlds provided in the various method embodiments of this application.

[0285] In some embodiments, server 1100 may optionally include an input interface 1103 and an output interface 1104. Processor 1101, memory 1102, and input interface 1103 and output interface 1104 can be connected via a bus or signal lines. Various peripheral devices can be connected to input interface 1103 and output interface 1104 via a bus, signal lines, or circuit board. Input interface 1103 and output interface 1104 can be used to connect at least one input / output (I / O) related peripheral device to processor 1101 and memory 1102. In some embodiments, processor 1101, memory 1102, and input interface 1103 and output interface 1104 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 1101, memory 1102, and input interface 1103 and output interface 1104 can be implemented on separate chips or circuit boards, and this application embodiment does not limit this.

[0286] Those skilled in the art will understand that Figure 11 The structure shown does not constitute a limitation on the computer device 1100 and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0287] In an exemplary embodiment, this application provides a chip including programmable logic circuits and / or program instructions, which, when running on a computer device, is used to implement the cross-server access method for the virtual world provided in the above-described method embodiments.

[0288] In an exemplary embodiment, this application provides a computer-readable storage medium storing a computer program that is loaded and executed by a processor to implement the cross-server access method for virtual worlds provided in the above-described method embodiments.

[0289] In an exemplary embodiment, this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the processor of the computer device to load and execute the method to implement the cross-server access method for virtual worlds provided in the above-described method embodiments.

[0290] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0291] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0292] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0293] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for cross-server access in a virtual world, characterized in that, The method includes: Upon receiving a world entry request from the first account, cross-server occupancy information is obtained. This cross-server occupancy information is used to indicate the load status of cross-server accounts in the current first server. The world entry request is used to request the first account to cross-server enter the first virtual world managed by the first server. If the cross-server occupancy information meets the first occupancy requirement, establish cross-server access permissions for the first account to the first server; If the first account has cross-server access to the first server, first display data is sent to the first account. The first display data is used to provide the first account with the display screen of the first virtual world.

2. The method according to claim 1, characterized in that, The cross-server occupancy information includes the number of cross-server accounts, which is used to indicate the number of cross-server accounts currently being loaded on the first server. The step of establishing cross-server access permissions for the first account to the first server when the cross-server occupancy information meets the first occupancy requirement includes: If the number of cross-server accounts is less than the account number threshold, establish the cross-server access permission of the first account to the first server.

3. The method according to claim 2, characterized in that, The method further includes: Obtain the number of accounts currently requesting cross-server access to the first virtual world; based on the number of requesting accounts and the cross-server access success rate corresponding to the first virtual world, determine the threshold number of accounts corresponding to the first server; or, Obtain the account activity level of the local account corresponding to the first server; determine the account quantity threshold corresponding to the first server based on the account activity level, wherein the local account is used to indicate the account belonging to the first virtual world.

4. The method according to any one of claims 1 to 3, characterized in that, The first server runs a process including a mirror server; the method further includes: If the cross-server occupancy information does not meet the first occupancy requirement, a mirror virtual world corresponding to the first virtual world is created through the mirror server process; The mirror server process sends mirror display data to the first account, and the mirror display data is used to provide the first account with the display screen of the mirrored virtual world.

5. The method according to any one of claims 1 to 3, characterized in that, The step of establishing cross-server access permissions for the first account to the first server when the cross-server occupancy information meets the first occupancy requirement includes: If the cross-server occupancy information meets the first occupancy requirement, cross-server access permissions for the first account to the first server are established based on the cross-server access request sent by the second server. The second server is used to manage the second virtual world, and the first account belongs to the second virtual world.

6. The method according to claim 5, characterized in that, The cross-server access request includes a first cross-server access request and a second cross-server access request; The step of establishing cross-server access permissions for the first account to the first server based on the cross-server access request sent by the second server, when the cross-server occupancy information meets the first occupancy requirement, includes: If the cross-server occupancy information meets the first occupancy requirement, the first cross-server access request sent by the second server is received; Based on the first cross-server access request, obtain the first account data corresponding to the first account; If the first account data meets the second occupancy requirement, the second cross-server access request sent by the second server is received; Based on the second cross-server access request, establish cross-server access permissions for the first account to the first server.

7. The method according to claim 6, characterized in that, The first account data meets the second occupancy requirement under at least one of the following conditions: The account level of the first account meets the account level requirements corresponding to the first virtual world; The current access time of the first account is within the opening time range of the first virtual world, which refers to the time range during which cross-server access to the first virtual world is permitted.

8. The method according to claim 5, characterized in that, The first account corresponds to a first virtual character; the cross-server access request includes the first character data corresponding to the first virtual character. Sending first display data to the first account when the first account has cross-server access to the first server includes: When the first account has cross-server access to the first server, the first display data is generated based on the first character data in the cross-server access request. The first display data is used to provide the first account with a display screen of the first virtual world containing the first virtual character. Send the first display data to the first account.

9. The method according to any one of claims 1 to 3, characterized in that, The cross-server resource usage information includes the current resource usage of the cross-server account, which is used to indicate the resource usage of the cross-server account on the first server at the current moment. The step of establishing cross-server access permissions for the first account to the first server when the cross-server occupancy information meets the first occupancy requirement includes: If the current resource usage of the cross-server account is less than the first resource threshold, establish cross-server access permissions for the first account to the first server.

10. The method according to any one of claims 1 to 3, characterized in that, The method further includes: If the first account exits the first virtual world, a return access request is sent to the second server. The return access request is used to request the first account to return to the second virtual world managed by the second server, and the first account belongs to the second virtual world. The second server is used to send second display data to the first account based on the return access request, and the second display data is used to provide the first account with the display screen of the second virtual world.

11. The method according to claim 10, characterized in that, The first account corresponds to the first virtual character; The step of sending a return access request to the second server when the first account logs out of the first virtual world includes: When the first account logs out of the first virtual world, obtain the character update data corresponding to the first virtual character. The character update data is used to indicate the character changes that occurred when the first virtual character was active in the first virtual world. Generate the return access request based on the character update data. The second server is used to parse the return access request to obtain the character update data and write the character update data into the database.

12. A cross-server access device for a virtual world, characterized in that, The device includes: The acquisition module is used to acquire cross-server occupancy information when it receives a world entry request sent by the first account. The cross-server occupancy information is used to indicate the load status of cross-server accounts in the current first server. The world entry request is used to request the first account to cross-server enter the first virtual world managed by the first server. The processing module is used to establish cross-server access permissions for the first account to the first server when the cross-server occupancy information meets the first occupancy requirement. The sending module is used to send first display data to the first account when the first account has cross-server access to the first server. The first display data is used to provide the first account with the display screen of the first virtual world.

13. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing at least one program, which is loaded and executed by the processor to implement the cross-server access method for the virtual world as described in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one program, which is loaded and executed by a processor to implement the cross-server access method for virtual worlds as described in any one of claims 1 to 11.

15. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the cross-server access method for virtual worlds as described in any one of claims 1 to 11.

Images