Methods, apparatus, devices and storage media for operating target virtual events

Abstract

This application provides a method, apparatus, device, and storage medium for running a target virtual event, belonging to the field of computer technology. In this method, a separate event server is provided for the running of the target virtual event, instead of running the target virtual event within a virtual world server that already has a virtual world running. This makes the running of the target virtual event unrestricted by the source of the virtual objects. The virtual objects participating in the target virtual event are not limited to those from the same virtual world server, but can come from different virtual world servers, enabling cross-server matching. Because this expands the range of sources of virtual objects in the matching pool and increases the number of virtual objects in the matching pool, the time spent waiting for a sufficient number of virtual objects to be collected to start the target virtual event is greatly reduced, improving overall efficiency.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device and storage medium for running a target virtual event. Background Technology

[0002] Currently, most virtual games not only support single-player gameplay with virtual objects, but also allow multiple virtual objects to communicate, cooperate, or fight simultaneously within the same virtual world, i.e., multiplayer online gameplay. In virtual games, multiple virtual objects can participate in a target virtual event with a required number of participants. However, the process of waiting for a sufficient number of virtual objects to be gathered before starting the target virtual event is time-consuming, resulting in overall low efficiency. Summary of the Invention

[0003] This application provides a method, apparatus, device, and storage medium for running a target virtual event, which shortens the time required to start the virtual event and improves overall efficiency. The technical solution is as follows:

[0004] On the one hand, a method for executing a target virtual event is provided, the method comprising:

[0005] Obtain the first virtual team to participate in the target virtual event, the first virtual team including virtual objects from the first server in the virtual world server;

[0006] Obtain at least one second virtual team to participate in the target virtual event, the second virtual team comprising virtual objects from a second server in the virtual world server, the second server and the first server running different virtual worlds;

[0007] Based on the first virtual team, a target virtual team is obtained by matching from the at least one second virtual team;

[0008] If the first virtual team and the target virtual team determine that they will participate in the target virtual event, the target virtual event will be run on the event server based on the virtual object data within the first virtual team and the target virtual team.

[0009] On the other hand, a method for configuring a virtual team is provided, the method comprising:

[0010] In response to the team configuration command of the first virtual object, the member configuration interface of the first virtual team is displayed, wherein the team configuration command instructs the configuration of the first virtual team participating in the target virtual event;

[0011] In the member configuration interface of the first virtual team, candidate virtual objects from different virtual world servers are displayed, and a source differentiation identifier is displayed. The source differentiation identifier indicates that the candidate virtual objects and the first virtual object come from different virtual world servers, and different virtual world servers run different virtual worlds.

[0012] In response to the selection operation of the second virtual object among the candidate virtual objects, a first prompt message is sent to the second virtual object. The first prompt message is used to prompt the second virtual object to join the first virtual team to participate in the target virtual event.

[0013] If the second virtual object joins the first virtual team, the first virtual object and the second virtual object are displayed in the first virtual team.

[0014] On the other hand, a device for running a target virtual event is provided, the device comprising:

[0015] The acquisition module is used to acquire the first virtual team to participate in the target virtual event. The first virtual team includes virtual objects from the first server in the virtual world server.

[0016] The acquisition module is further configured to acquire at least one second virtual team to participate in the target virtual event, the second virtual team including virtual objects from a second server in the virtual world server, the second server and the first server running different virtual worlds;

[0017] The matching module is used to match the first virtual team from the at least one second virtual team to obtain the target virtual team;

[0018] The execution module is configured to, if the first virtual team and the target virtual team determine that they will participate in the target virtual event, run the target virtual event on the event server based on the virtual object data within the first virtual team and the target virtual team.

[0019] In one possible implementation, the matching module is configured to match from at least one second virtual team based on the number of virtual objects in the first virtual team to obtain the target virtual team, wherein the sum of the number of virtual objects in the target virtual team and the number of virtual objects in the first virtual team satisfies the operational requirements of the target virtual event.

[0020] In one possible implementation, the running module is configured to obtain virtual object data of each virtual object from the virtual world server of each virtual object in the first virtual team and the target virtual team respectively; store the obtained virtual object data in a first database, the first database being used to temporarily store data for virtual objects participating in virtual events; load the virtual object data from the first database into the event server, and run the target virtual event on the event server.

[0021] In one possible implementation, the running module is further configured to send the address of the event server to the client of each virtual object in the first virtual team and the target virtual team, wherein the address of the event server is used for the client of each virtual object in the first virtual team and the target virtual team to establish a connection with the event server.

[0022] In one possible implementation, the device further includes:

[0023] The verification module is used to perform a preliminary verification on each virtual object in the first virtual team. The preliminary verification is used to confirm whether the virtual object is qualified to participate in the matching.

[0024] In one possible implementation, the matching module is further configured to perform the step of matching from the at least one second virtual team to obtain the target virtual team, provided that each virtual object in the first virtual team has passed the pre-verification.

[0025] The acquisition module is further configured to restart the execution from the step of acquiring the first virtual team to participate in the target virtual event if any virtual object in the first virtual team fails the pre-matching verification.

[0026] In one possible implementation, the device further includes:

[0027] The loading module is used to load the virtual object data of any virtual object in the first virtual team and the target virtual team from the first database to the virtual world server corresponding to the virtual object if the virtual object determines to exit the target virtual event, so that the virtual object can re-enter the virtual world run by the virtual world server. The first database is used to temporarily store data for virtual objects participating in the virtual event.

[0028] In one possible implementation, the loading module is further configured to obtain virtual event data of the virtual object from the event server, the virtual event data being used to record the results of the virtual object participating in the target virtual event; store the obtained virtual event data in a second database, the second database being used to temporarily store virtual event data for virtual objects that are determined to exit the virtual event; and load the virtual event data from the second database into the virtual world server.

[0029] In one possible implementation, the loading module is further configured to send the address of the virtual world server to the client of the virtual object, wherein the address of the virtual world server is used by the client of the virtual object to establish a connection with the virtual world server.

[0030] In one possible implementation, the loading module is further configured to: if any virtual object in the first virtual team and the target virtual team determines to exit the target virtual event, obtain updated virtual object data of the virtual object from the event server; store the obtained updated virtual object data in a third database, the third database being used to temporarily store the updated virtual object data for the virtual object that has determined to exit the virtual event; and load the updated virtual object data from the third database into the virtual world server corresponding to the virtual object, so that the virtual object re-enters the virtual world run by the virtual world server and obtains the result of the target virtual event.

[0031] On the other hand, a configuration device for a virtual team is provided, the device comprising:

[0032] The interface display module is used to display the member configuration interface of the first virtual team in response to the team configuration command of the first virtual object, wherein the team configuration command instructs the first virtual team to configure the participation of the target virtual event;

[0033] The object display module is used to display candidate virtual objects from different virtual world servers in the member configuration interface of the first virtual team, and display a source differentiation identifier. The source differentiation identifier indicates that the candidate virtual objects and the first virtual object come from different virtual world servers, and different virtual world servers run different virtual worlds.

[0034] The sending module is configured to, in response to the selection operation of the second virtual object among the candidate virtual objects, send a first prompt message to the second virtual object, the first prompt message being used to prompt the second virtual object to join the first virtual team to participate in the target virtual event;

[0035] The team display module is used to display the first virtual object and the second virtual object in the first virtual team if the second virtual object joins the first virtual team.

[0036] In one possible implementation, the device further includes:

[0037] The message display module is used to display a second prompt message in response to the matching instruction of the first virtual object. The matching instruction indicates that the first virtual team is being matched with a virtual team, and the second prompt message is used to indicate that a virtual team is being matched to participate in the target virtual event.

[0038] In one possible implementation, the message display module is further configured to perform at least one of the following: if the first virtual team and the target virtual team to participate in the target virtual event have been successfully matched, display a third prompt message, the third prompt message being used to prompt confirmation of participation in the target virtual event; if the first virtual object has confirmed participation in the target virtual event, display a fourth prompt message, the fourth prompt message being used to prompt each virtual object whether it has confirmed participation in the target virtual event.

[0039] In one possible implementation, the device further includes:

[0040] A connection module is used to establish a connection with the event server based on the received address of the event server, so that the first virtual object can participate in the target virtual event running on the event server.

[0041] In one possible implementation, the connection module is further configured to, if the first virtual object confirms its exit from the target virtual event, establish a connection with the virtual world server based on the received address of the virtual world server corresponding to the first virtual object, so that the first virtual object re-enters the virtual world run by the virtual world server.

[0042] On the other hand, a computer device is provided, the computer device including a processor and a memory, the memory being used to store at least one computer program, the at least one computer program being loaded and executed by the processor to implement the method for running a target virtual event or the method for configuring a virtual team in the embodiments of this application.

[0043] On the other hand, a computer-readable storage medium is provided, wherein at least one computer program is stored in the computer-readable storage medium, the at least one computer program being loaded and executed by a processor to implement the method for running a target virtual event or the method for configuring a virtual team in the embodiments of this application.

[0044] On the other hand, a computer program product is provided, including a computer program that is executed by a processor to implement the method for running a target virtual event or the method for configuring a virtual team in the embodiments of this application.

[0045] This application provides a method for running a target virtual event. Instead of running the target virtual event on a virtual world server containing virtual worlds, a separate event server is provided for its execution. This removes the restriction on the source of the virtual objects from the target virtual event. Virtual objects participating in the target virtual event are not limited to those from the same virtual world server but can come from different virtual world servers, enabling cross-server matching. Because this expands the range of virtual objects in the matching pool and increases the number of virtual objects in the pool, the time spent waiting for a sufficient number of virtual objects to be collected to start the target virtual event is significantly reduced, improving overall efficiency. Attached Figure Description

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

[0047] Figure 1 This is a schematic diagram of an implementation environment provided in an embodiment of this application;

[0048] Figure 2 This is a flowchart of a method for running a target virtual event provided in an embodiment of this application;

[0049] Figure 3 This is a flowchart illustrating a method for configuring a virtual team according to an embodiment of this application;

[0050] Figure 4 This is a schematic diagram of a team creation interface provided according to an embodiment of this application;

[0051] Figure 5 This is a schematic diagram of a virtual world interface provided in this application;

[0052] Figure 6 This is a schematic diagram of a member configuration interface provided according to an embodiment of this application;

[0053] Figure 7 This is a schematic diagram of an invitation prompt interface provided according to an embodiment of this application;

[0054] Figure 8This is a flowchart of another method for running a target virtual event provided in an embodiment of this application;

[0055] Figure 9 This is a schematic diagram of a matching interface provided according to an embodiment of this application;

[0056] Figure 10 This is a schematic diagram of a matching success notification interface provided according to an embodiment of this application;

[0057] Figure 11 This is a schematic diagram of a process for initiating a target virtual event according to an embodiment of this application;

[0058] Figure 12 This is a flowchart illustrating a virtual object joining event according to an embodiment of this application;

[0059] Figure 13 This is a flowchart illustrating a virtual object exit event according to an embodiment of this application;

[0060] Figure 14 This is a block diagram of a device for running a target virtual event, as provided in an embodiment of this application.

[0061] Figure 15 This is a block diagram of another target virtual event execution device provided in the embodiments of this application;

[0062] Figure 16 This is a block diagram of a virtual team configuration device provided in an embodiment of this application;

[0063] Figure 17 This is a block diagram of another virtual team configuration device provided in an embodiment of this application;

[0064] Figure 18 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application;

[0065] Figure 19 This is a schematic diagram of the structure of a server provided in an embodiment of this application. Detailed Implementation

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

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

[0068] In this application, the term "at least one" means one or more, and "multiple" means two or more.

[0069] It should be noted that all information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application have been authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the virtual object data, virtual event data, and virtual teams involved in this application were all obtained with full authorization.

[0070] The following is an explanation of the terms used in this application.

[0071] Virtual world: A virtual scene provided by an application running on a terminal. This virtual world can be a simulation of the real world, a semi-simulated / semi-fictional virtual environment, or a purely fictional virtual environment. The virtual world can be any of a two-dimensional, 2.5-dimensional, or three-dimensional virtual space; this application does not limit the dimensions of the virtual world. For example, the virtual world includes the sky, land, and ocean, with the land including environmental elements such as deserts and cities. Users can control virtual objects to move within this virtual world.

[0072] Virtual objects: These are movable objects in a virtual world. These movable objects can be virtual characters, virtual animals, anime characters, etc. Examples include people, animals, plants, oil drums, walls, and stones displayed in a virtual world. A virtual object can be a virtual avatar representing the user within that virtual world. A virtual world can include multiple virtual objects, each with its own shape and volume, occupying a portion of the virtual world's space.

[0073] Optionally, the virtual object can be a player character controlled through client-side operations, an artificial intelligence (AI) trained and set in the virtual world, or a non-player character (NPC) interacting in the virtual world. Optionally, the virtual object can be a virtual character competing in the virtual world. Optionally, the number of virtual objects participating in the interaction in the virtual world can be preset or dynamically determined based on the number of clients joining the interaction. In this application, a player character controlled through client-side operations is used as an example.

[0074] A target virtual event refers to a virtual event involving multiple virtual objects and having operational requirements. Operational requirements mean that the target virtual event will begin after a specific number of virtual objects are collected, such as requiring 3, 5, or 8-10 virtual objects. Optionally, the target virtual event can be a target level or target instance in a virtual game. Different virtual events can be different levels or different instances in a virtual game. Types of target virtual events include, but are not limited to: advancing the storyline, time-limited challenges, limited-time events, and daily activities. Multiple virtual objects participating in the target virtual event receive corresponding virtual resources based on their performance in the event, such as virtual equipment, virtual materials, virtual items, virtual experience, virtual resources, virtual titles, and specific achievements.

[0075] The system architecture involved in this application is described below.

[0076] Figure 1 This is a schematic diagram of an implementation environment provided in an embodiment of this application. See also... Figure 1 The implementation environment includes: terminal 101 and server cluster 102. Terminal 101 and server cluster 102 can be directly or indirectly connected via wired or wireless network, which is not limited herein.

[0077] In one possible implementation, terminal 101 can be a smartphone, tablet, laptop, desktop computer, wearable electronic device, etc., but is not limited to these. Optionally, a client is installed on terminal 101. This client is a game client that supports the virtual world. This client can be a client pre-installed on the terminal, or it can be a lightweight client embedded in a third-party application; this application does not impose any restrictions on this. The client installed on terminal 101 can establish a connection with server cluster 102 to send data to server cluster 102 or receive data from server cluster 102.

[0078] In one possible implementation, server cluster 102 can be a server cluster or distributed system composed of multiple physical servers, or it can be a server cluster or distributed system composed of multiple cloud servers. The cloud servers can provide cloud services such as cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0079] In one possible implementation, server cluster 102 includes at least virtual world servers and event servers. Virtual world servers run virtual worlds. Different virtual world servers run different virtual worlds. Event servers run virtual events. At any given time, the virtual objects in the virtual events run by different event servers are different. Virtual world servers and event servers can be directly or indirectly connected via wired or wireless networks.

[0080] It should be noted that the client installed in terminal 101 can establish a connection with the virtual world server, allowing the virtual object corresponding to the client to enter the virtual world run by the virtual world server. The client installed in terminal 101 can also establish a connection with the event server, allowing the virtual object corresponding to the client to participate in virtual events run by the event server. The client installed in terminal 101 can establish connections with one virtual world server and one event server simultaneously.

[0081] The virtual world server and event server in server cluster 102 support multiple distribution methods. When server cluster 102 is a server cluster composed of multiple physical servers, the virtual world server and event server can be distributed across different physical servers or run in different virtual machines on the same physical server. When server cluster 102 is a server cluster composed of multiple cloud servers, the virtual world server and event server can run on different cloud servers provided by cloud providers.

[0082] In one possible implementation, the server cluster 102, in addition to including a virtual world server and an event server to perform the aforementioned functions, may also include other servers to provide access services, data processing services, scheduling services, and databases, etc. The physical server providing each service may be one or more, and a single physical server may also provide one or more services. Similarly, the cloud server providing each service may be one or more, and a single cloud server may also provide one or more services; this embodiment does not limit the scope of the application. Those skilled in the art will understand that the aforementioned other servers also support the various distribution methods of the virtual world server and event server described above, which will not be elaborated upon here.

[0083] Those skilled in the art will know that Figure 1The terminal 101 and server cluster 102 shown are for illustrative purposes only. In actual applications, the number of terminals included in this implementation environment may be more or less. For example, there may be hundreds or thousands of terminals 101, or even more. This application embodiment does not limit the number of terminals or the type of devices. Depending on the needs of actual applications, the server cluster 102 in this implementation environment can have any architecture, and this application embodiment does not limit the number and distribution of servers therein.

[0084] This completes the work on... Figure 1 The following is a description of the implementation environment. Figure 1 The implementation environment shown below is used to explain the method for running the target virtual event provided in this application through embodiments. The following embodiments do not constitute a limitation of this application.

[0085] Figure 2 This is a flowchart illustrating a method for running a target virtual event according to an embodiment of this application. This method is executed by a server in the server cluster within the aforementioned implementation environment. This server can establish connections with the virtual world server, the event server, and the client. (See also...) Figure 2 The method includes the following steps:

[0086] 201. The server obtains the first virtual team to participate in the target virtual event. The first virtual team includes virtual objects from the first server in the virtual world server.

[0087] In this embodiment, a target virtual event refers to a virtual event involving multiple virtual objects and having operational requirements. Operational requirements mean that the target virtual event begins to run after a specific number of virtual objects are collected. Optionally, the target virtual event is a target level or target instance in a virtual game. A virtual world is a virtual scene provided by the application at runtime. This virtual world can be a simulation environment of the real world, a semi-simulated / semi-fictional virtual environment, or a purely fictional virtual environment. The virtual world can be a pre-defined virtual world or a virtual world created based on a user-initiated creation request; this embodiment does not impose any limitations on this.

[0088] The virtual world server is used to run the virtual world. The first virtual team includes at least one virtual object, which includes virtual objects originating from the first server. Correspondingly, the first virtual team may include only one virtual object originating from the first server, and the first virtual team may also include one virtual object originating from the first server and other virtual objects, which may originate from the first server or from a virtual world server other than the first server.

[0089] 202. The server obtains at least one second virtual team to participate in the target virtual event. The second virtual team includes virtual objects from a second server in the virtual world server. The second server and the first server run different virtual worlds.

[0090] In this embodiment, at least one second virtual team and the first virtual team participate in the same virtual event, namely the target virtual event. The second virtual team includes at least one virtual object, which includes virtual objects originating from a second server. The source distribution of virtual objects in the second virtual team is similar to that of the virtual objects in the first virtual team in step 201, and will not be repeated here. The first virtual team can be matched with the second virtual team, meaning cross-virtual world server matching is possible.

[0091] 203. The server, based on the first virtual team, matches from at least one second virtual team to obtain the target virtual team.

[0092] In this embodiment, the target virtual team includes one or more virtual teams from at least one second virtual team mentioned above. The target virtual team and the first virtual team participate in the same virtual event, namely the target virtual event. The sum of the number of virtual objects in the target virtual team and the first virtual team satisfies the operational requirements of the target virtual event.

[0093] For example, the execution requirements of a target virtual event indicate that it will begin after 4 virtual objects are collected. The target virtual team includes virtual team A. Virtual team A contains 3 virtual objects, and the first virtual team contains 1 virtual object. The sum of the number of virtual objects in the first virtual team and the target virtual team is 4, which meets the execution requirements of the target virtual event. Therefore, the target virtual team and the first virtual team are successfully matched and can participate in the target virtual event together. Alternatively, the execution requirements of a target virtual event indicate that it will begin after 6-8 virtual objects are collected. The target virtual team includes virtual team A and virtual team B. Virtual team A contains 3 virtual objects, virtual team B contains 1 virtual object, and the first virtual team contains 2 virtual objects. The sum of the number of virtual objects in the first virtual team and the target virtual team is 6, which meets the execution requirements of the target virtual event. Therefore, the target virtual team and the first virtual team are successfully matched and can participate in the target virtual event together.

[0094] 204. If the first virtual team and the target virtual team determine that they will participate in the target virtual event, the server will run the target virtual event on the event server based on the virtual object data within the first virtual team and the target virtual team.

[0095] In this application embodiment, there are several ways for the server to select an event server. In one possible implementation, an event server is selected from multiple servers that are in an idle state. An idle state means that no virtual event is currently running on the server. In another possible implementation, each target virtual event has multiple backup servers, and an idle server is selected from these backup servers as the event server. An idle state means that no target virtual event is currently running on the server.

[0096] This application provides a method for running a target virtual event. Instead of running the target virtual event on a virtual world server that already contains virtual worlds, a separate event server is provided for its execution. This removes the restriction on the source of the virtual objects from the target virtual event. The virtual objects participating in the target virtual event are not limited to those from the same virtual world server but can come from different virtual world servers, enabling cross-server matching. Because this expands the range of virtual objects in the matching pool and increases the number of virtual objects in the pool, the time spent waiting for a sufficient number of virtual objects to be collected to start the target virtual event is significantly reduced, improving overall efficiency.

[0097] Because traditional methods only support configuring virtual teams within the same server and having them participate in a common virtual event, the terminal in the traditional method only displays brief information about the virtual objects in the virtual team member configuration interface to distinguish between different virtual objects. However, in the above... Figure 2 Based on the target virtual event execution method described in the embodiments, the traditional member configuration interface cannot meet the team configuration requirements. Users cannot directly obtain relevant information about the virtual world server from which the virtual object originates through the member configuration interface, which reduces the configuration efficiency of virtual teams. Therefore, a virtual team configuration method is introduced below, which can be used to configure the above-mentioned... Figure 2 The following describes the execution method of the target virtual event as illustrated in the embodiments, using the configuration of the first virtual team as an example. (See also...) Figure 3 , Figure 3 This is a flowchart of a virtual team configuration method provided in an embodiment of this application. The method is executed by a terminal in the above-described implementation environment, and includes the following steps:

[0098] 301. The terminal responds to the team configuration command of the first virtual object and displays the member configuration interface of the first virtual team. The team configuration command instructs the configuration of the first virtual team participating in the target virtual event.

[0099] In this embodiment of the application, since the first virtual object automatically joins the first virtual team after creating the first virtual team, when the first virtual team is displayed in the member configuration interface of the first virtual team, at least the first virtual object is displayed in the virtual team.

[0100] Optionally, the team configuration command for the first virtual object can be triggered by either a trigger operation on the team creation component or a trigger operation on the team configuration component. These will be described separately below.

[0101] In one possible implementation, in response to a trigger operation on the team creation component, the terminal obtains the team configuration instruction for the first virtual object, displays the member configuration interface of the first virtual team, and displays the first virtual team including the first virtual object in the member configuration interface of the first virtual team. For ease of description, see [link to documentation]. Figure 4 As shown, Figure 4 This is a schematic diagram of a team creation interface provided according to an embodiment of this application. A target virtual event is selected by sliding within area 401. As shown in the diagram, the virtual event "Dungeon Challenge - Level 3" has been selected as the target virtual event. The requirement for this target virtual event is a "1-3 player team". 402 is the team creation component. In response to a trigger operation on the team creation component 402, the terminal obtains the team configuration instructions for the first virtual object. Optionally, after creating the first virtual team, the first virtual object can change the virtual events that the first virtual team will participate in; this will not be elaborated further here.

[0102] In another possible implementation, the terminal, in response to a trigger operation on the team configuration component, obtains the team configuration instruction for the first virtual object, displays the member configuration interface of the first virtual team, and displays at least one virtual object in the first virtual team at this time in the member configuration interface of the first virtual team. For ease of description, see [link to documentation]. Figure 5 As shown, Figure 5 This is a schematic diagram of a virtual world interface provided in this application. 501 is a team configuration component, and the terminal responds to the trigger operation on the team configuration component 501 to obtain the team configuration instruction of the first virtual object.

[0103] In some embodiments, the member configuration interface displays the target virtual event to be participated in by the first virtual team, as well as the account level, name, avatar, carried virtual items, and associated controllable objects of each virtual object in the first virtual team. Virtual objects can carry virtual items and fight alongside controllable objects, or virtual objects can cause controllable objects to carry virtual items and control the controllable objects to fight; this embodiment does not limit this. For ease of description, see [link to documentation]. Figure 6 As shown, Figure 6This is a schematic diagram of a member configuration interface provided according to an embodiment of this application. Area 601 displays a first virtual team, and the first virtual team displays virtual objects named 1 and 2.

[0104] 302. In the member configuration interface of the first virtual team, the terminal displays candidate virtual objects from different virtual world servers and displays a source distinction identifier. The source distinction identifier indicates that the candidate virtual objects and the first virtual object come from different virtual world servers, and different virtual world servers run different virtual worlds.

[0105] In this embodiment, the terminal can display candidate virtual objects from the same virtual world server as the first virtual object, in addition to displaying candidate virtual objects from different virtual world servers. Optionally, the source differentiation identifier includes at least one of text and an icon. Optionally, the member configuration interface also displays a source indication identifier. The source indication identifier indicates that the candidate virtual object and the first virtual object come from the same virtual world server. The source indication identifier includes at least one of text and an icon. Optionally, the identifier corresponding to each candidate virtual object is displayed at a preset position of the candidate virtual object.

[0106] For ease of description, see Figure 6 As shown, area 602 displays multiple candidate virtual objects named a, b, c, d, and e. Taking candidate virtual objects named b and c as examples, 6021 is the source differentiation identifier, displayed as "Otherworld," indicating that the candidate virtual object named b, currently located in "×× World," comes from a different virtual world server than the first virtual object. 6022 is the source indication identifier, indicating that the candidate virtual object named c comes from the same virtual world server as the first virtual object.

[0107] In one possible implementation, an invitation component is displayed in the member configuration interface. Accordingly, if a first virtual team is displayed on the member configuration page, the terminal, in response to triggering an invitation component at a preset position within the first virtual team, displays candidate virtual objects from multiple different virtual world servers. See also... Figure 6 As shown, 6011 is the invitation component. In response to the trigger operation on 6011, the terminal switches from displaying the first virtual team in area 601 to simultaneously displaying the first virtual team in area 601 and multiple candidate virtual objects in area 602.

[0108] In one possible implementation, the member configuration page displays multiple attribute tags. Accordingly, in response to a trigger operation on any attribute tag, the terminal displays multiple candidate virtual objects corresponding to that attribute tag on the member configuration page. Different attribute tags correspond to candidate virtual objects under different attributes. For example, the multiple attribute tags may respectively correspond to candidate virtual objects that are associated with the first virtual object, candidate virtual objects that come from the same virtual world server as the first virtual object, candidate virtual objects that participate in virtual games with the first virtual object within a preset time range, and candidate virtual objects that are within the same virtual organization as the first virtual object. Optionally, the association relationship can refer to a friend relationship, and the virtual organization can refer to a virtual guild, virtual tribe, virtual team, etc. See also Figure 6 As shown, area 602 displays multiple attribute labels such as "Friends", "World", and "Recent". The current area 602 displays multiple candidate virtual objects corresponding to the "Friends" attribute label.

[0109] In one possible implementation, the terminal displays candidate virtual objects based on their basic data. Accordingly, the virtual world server of the first virtual object obtains the basic data of each candidate virtual object from the virtual world servers of multiple candidate virtual objects; alternatively, the virtual world server of the first virtual object retrieves the basic data of multiple candidate virtual objects in batches from a storage server based on the account information of the candidate virtual objects. The virtual world server of the first virtual object sends the obtained basic data of the candidate virtual objects to the terminal; the terminal displays the candidate virtual objects based on the received basic data.

[0110] The storage server is a high-performance server that stores basic data of virtual objects from multiple virtual world servers. This storage server supports batch data retrieval. The basic data is used to distinguish different virtual objects. The basic data of any virtual object is the data displayed within the virtual team, such as the virtual object's account level, name, avatar, the virtual world server it comes from, its carried virtual items, and associated controllable objects.

[0111] 303. In response to the selection operation of the second virtual object among the candidate virtual objects, the terminal sends a first prompt message to the second virtual object. The first prompt message is used to prompt the second virtual object to join the first virtual team to participate in the target virtual event.

[0112] In this embodiment, the first notification message may include the name of the first virtual object, the target virtual event that the first virtual team is to participate in, a progress bar for displaying the first notification message, and confirmation and rejection components, etc. For ease of description, see [link to documentation]. Figure 7 As shown, Figure 7This is a schematic diagram of an invitation prompt interface provided according to an embodiment of this application. 701 is a first prompt message, used to indicate that a second virtual object has been invited by a first virtual object named × to join a first virtual team, and that the first virtual team is to participate in the target virtual event "Dungeon Challenge - Level 3". As shown in the figure, "Ignore this player's request for 15 minutes" means that the first prompt message sent by the first virtual object will not be displayed for 15 minutes; this option takes effect after checking the box.

[0113] In one possible implementation, when the terminal of the second virtual object receives the first prompt message, the terminal of the second virtual object responds to the triggering operation of the confirmation component and determines that the second virtual object has joined the first virtual team.

[0114] In one possible implementation, the member configuration interface displays the account level, name, avatar, associated controllable objects, current virtual world, current virtual event, and whether the virtual event is unlocked for each candidate virtual object. Accordingly, based on the target virtual event for the first virtual team and the aforementioned information, the terminal determines whether each candidate virtual object is qualified to participate in the target virtual event. Optionally, the terminal determines whether each candidate virtual object is qualified to participate in the target virtual event based on at least one of the following: whether the target virtual event allows cross-virtual world server team formation and participation, whether the candidate virtual object has already joined the target virtual event, whether the candidate virtual object has joined another virtual team, and whether the candidate virtual object is online.

[0115] In one possible implementation, the terminal displays candidate virtual objects that are eligible to participate in the target virtual event as selectable, while displaying candidate virtual objects that are not eligible to participate as unselectable. This method helps the first virtual object more easily and quickly identify the candidate virtual objects that can be invited, improving the intuitiveness of information display and the efficiency of information transmission, avoiding invalid operations, and improving human-computer interaction efficiency.

[0116] 304. If the second virtual object joins the first virtual team, the terminal displays the first virtual object and the second virtual object in the first virtual team.

[0117] In this embodiment, the first virtual team may also display an identifier corresponding to each virtual object within the team. This identifier may be a source differentiation identifier or a source indication identifier. See also... Figure 6As shown, the example uses virtual objects named 1 and 2 within the team. 6011 is the source differentiation identifier, displayed as "Otherworld," indicating that virtual object 2 and the first virtual object originate from different virtual world servers. 6012 is the source indication identifier, indicating that virtual object 1 and the first virtual object originate from the same virtual world server.

[0118] In one possible implementation, the terminal adds the second virtual object to the first virtual object's virtual world based on the second virtual object's basic data. Correspondingly, the virtual world server of the first virtual object retrieves the second virtual object's basic data from the virtual world server of the second virtual object, and the virtual world server of the first virtual object sends the second virtual object's basic data to the terminal. The terminal then displays the second virtual object based on the received basic data.

[0119] This application provides a method for configuring virtual teams, which displays candidate virtual objects from different virtual world servers in the member configuration interface, providing the function of forming teams across virtual world servers. By displaying a source distinction identifier in the member configuration interface, it can intuitively indicate whether the candidate virtual object and the first virtual object come from different virtual world servers, so that users do not need to obtain the above information from other complex paths, improving the intuitiveness of information display and improving the configuration efficiency of virtual teams.

[0120] Figure 3 This paper introduces the process of configuring virtual teams. Figure 3 Based on the method for configuring the first virtual team, this paper provides a detailed introduction to the data interaction process in the execution method of the target virtual event. (See also...) Figure 8 , Figure 8 This is a flowchart of another method for running a target virtual event provided in this application embodiment. The method is executed by a server in the above implementation environment, and includes the following steps:

[0121] 801. The server obtains the first virtual team to participate in the target virtual event. The first virtual team includes virtual objects from the first server in the virtual world server.

[0122] In this embodiment, the principle by which the server obtains the first virtual team is the same as step 201 described above, and will not be repeated here. The server can obtain the first virtual team in various ways, which will be described below.

[0123] In one possible implementation, once any virtual object is confirmed to join the first virtual team, the server establishes communication with the virtual world server from which the virtual object originates and retrieves the virtual object's basic data from that server. This basic data is used to distinguish different virtual objects. The basic data of any virtual object includes the data displayed within the virtual team, such as the virtual object's account level, name, avatar, the virtual world server it originated from, its carried virtual items, and associated controllable objects.

[0124] In another possible implementation, once any virtual object is determined to join the first virtual team, the server establishes communication with the virtual world server from which the virtual object originates, and retrieves the virtual object data of the virtual object from that virtual world server. The virtual object data is used to execute the virtual object's operation. The virtual object data for any virtual object comprises all data associated with that virtual object.

[0125] The confirmation of any virtual object joining the first virtual team includes: the virtual object automatically joining the first virtual team after its creation, as shown in step 301 above; and the virtual object being invited to join the first virtual team, as shown in step 304 above. The data interaction between the server and the terminal in these two scenarios is described below.

[0126] In one possible implementation, the terminal of the first virtual object, in response to a triggering operation of the team creation component, sends a notification to the virtual world server of the first virtual object. This notification instructs the first virtual object to create a first virtual team. Based on the received notification, the virtual world server sends basic data or virtual object data of the first virtual object to the server. For a detailed description of the team creation component, please refer to step 301.

[0127] In another possible implementation, the terminal of the second virtual object, in response to the triggering operation of the confirmation component, sends a notification to the virtual world server of the second virtual object. This notification indicates that the second virtual object has been confirmed to join the first virtual team. Based on the received notification, the virtual world server sends the basic data or virtual object data of the second virtual object to the server. For a description of the confirmation component, please refer to step 303.

[0128] 802. The server obtains at least one second virtual team to participate in the target virtual event. The second virtual team includes virtual objects from a second server in the virtual world server. The second server and the first server run different virtual worlds.

[0129] In this embodiment of the application, the principle by which the server obtains at least one second virtual team is the same as the principle by which the server obtains the first virtual team in step 801, and will not be repeated here.

[0130] In one possible implementation, after the server obtains the first virtual team and at least one second virtual team, before matching from at least one second virtual team based on the first virtual team, it performs a pre-verification on each virtual object in the first virtual team. The pre-verification is used to confirm whether the virtual object is eligible to participate in the matching.

[0131] The server may perform pre-verification based on at least one of the following: whether the virtual object is in an idle state, whether the virtual object has permission to participate in the target virtual event, and whether the client version number of the virtual object is compatible. If the target virtual object undergoes pre-verification based on multiple of the above, and any virtual object is in an idle state, has permission to participate in the target virtual event, and the client version number is compatible, then the virtual object passes the pre-verification and is eligible to participate in the matching process. If any virtual object meets at least one of the following conditions: being in a non-idle state, lacking permission to participate in the target virtual event, or having an incompatible client version number, then the virtual object fails the pre-verification and is not eligible to participate in the matching process.

[0132] In this context, "virtual object in idle state" means that the virtual object is not performing an uninterruptible task and has not entered the target virtual event. "Virtual object has permission to participate in the target virtual event" means that the virtual object has unlocked the virtual game level corresponding to the target virtual event. "Virtual object client version compatibility" means that the version number of the virtual object's client matches the version number of the event server that will subsequently run the target virtual event.

[0133] By performing the above pre-verification, we can avoid situations where virtual objects that cannot participate in the target virtual event are included in the matching process, thus preventing invalid matching and improving the efficiency of starting the target virtual event.

[0134] In one possible implementation, if each virtual object in the first virtual team passes the pre-verification, the server performs the step of matching from at least one second virtual team based on the first virtual team to obtain the target virtual team (i.e., step 803); if any virtual object in the first virtual team fails the matching pre-verification, the server restarts execution from the step of obtaining the first virtual team to participate in the target virtual event (i.e., step 801).

[0135] In one possible implementation, the server re-acquiring the first virtual team to participate in the target virtual event means: the server clears the data of each virtual object in the currently stored first virtual team; when a specific virtual object in the first virtual team performs a confirmation matching operation, the server obtains the basic data of each virtual object in the first virtual team stored in the virtual world server of the first virtual object. Optionally, the server can also establish communication with the virtual world server from which each virtual object in the current first virtual team originates based on this data, and obtain the corresponding virtual object data from the aforementioned virtual world server. Here, a specific virtual object refers to a virtual object with team leader permissions.

[0136] Before a specific virtual object in the first virtual team performs a confirmation matching operation, the specific virtual object can remove virtual objects that fail the pre-verification from the first virtual team, and can also invite new virtual objects to join the first virtual team. This application embodiment does not limit this.

[0137] Using the above method, when there are virtual objects in the first virtual team that have failed the pre-verification, it is possible to continue the team configuration or matching operation based on the current first virtual team, without having to disband the first virtual team and re-form a team. This is more convenient and faster, shortens the time required for team configuration and matching, and improves overall efficiency.

[0138] 803. The server, based on the first virtual team, matches from at least one second virtual team to obtain the target virtual team.

[0139] In this application embodiment, there are multiple ways for the server to match from at least one second virtual team, which will be described below.

[0140] In one possible implementation, the matching criteria include the number of virtual objects in each virtual team and the operational requirements of the target virtual event. The server matches data from at least one second virtual team based on the number of virtual objects in the first virtual team to obtain the target virtual team, where the sum of the number of virtual objects in the target virtual team and the number of virtual objects in the first virtual team satisfies the operational requirements of the target virtual event.

[0141] In another possible implementation, the matching criteria include the number of virtual objects in each virtual team, the virtual events that each virtual team needs to participate in, and the operational requirements of each virtual event. Accordingly, the server determines the number of virtual objects in the first virtual team, the target virtual event that the first virtual team needs to participate in, and the operational requirements of that target virtual event; based on the target virtual event that the first virtual team needs to participate in, candidate virtual teams are selected from at least one virtual team, both of which need to participate in the target virtual event; based on the number of virtual objects in the first virtual team, the operational requirements of the target virtual event, and the number of virtual objects in each candidate virtual team, the target virtual team is selected from the candidate teams, and the sum of the number of virtual objects in the target virtual team and the number of virtual objects in the first virtual team satisfies the operational requirements of the target virtual event.

[0142] In one possible implementation, the terminal indicates that matching is in progress. Accordingly, in response to the matching instruction of the first virtual object, the terminal displays a second notification message. The matching instruction indicates that the first virtual team is being matched with another virtual team, and the second notification message indicates that matching is underway with a virtual team awaiting participation in a target virtual event. The second notification message may include the duration from the start of matching to the current moment, the target virtual event awaiting participation by the first virtual team, etc. For ease of description, see [link to documentation]. Figure 9 As shown, Figure 9 This is a schematic diagram of a matching interface provided according to an embodiment of this application. 901 represents a second prompt message. As shown in the figure, area 902 of this interface may also display brief information about multiple virtual objects in the first virtual team, which will not be described in detail here.

[0143] Optionally, after the server obtains the target virtual team, the server further determines whether both the first virtual team and the target virtual team are confirmed to participate in the target virtual event. Optionally, the confirmation that the first virtual team and the target virtual team are confirmed to participate in the target virtual event means that: in the first virtual team and the target virtual team, every virtual object is confirmed to participate in the target virtual event; or, in the first virtual team and the target virtual team, the number of virtual objects confirmed to participate in the target virtual event meets the quantity requirement; or, in the first virtual team and the target virtual team, the ratio between the number of virtual objects confirmed to participate in the target virtual event and the number of virtual objects not confirmed to participate in the target virtual event meets the ratio requirement.

[0144] In this context, "virtual object confirms participation in the target virtual event" means that the virtual object triggers the "confirm" option within a preset time period. "Virtual object does not confirm participation in the target virtual event" means that the virtual object does not perform any triggering operation on the "confirm" or "deny" options within the preset time period, or that the virtual object triggers the "deny" option. The "confirm" option is used to confirm participation in the target virtual event after triggering, and the "deny" option is used to refuse participation in the target virtual event after triggering.

[0145] In one possible implementation, the terminal indicates a successful match. Accordingly, if the first virtual team and the target virtual team for the virtual event to be participated in have successfully matched, the terminal displays a third notification message to prompt confirmation of participation in the target virtual event. This third notification message may include a confirmation countdown, the target virtual event for the first virtual team, and confirmation options, which are used to confirm participation in the target virtual event upon triggering. For ease of description, see [link to documentation]. Figure 10 As shown, Figure 10 This is a schematic diagram of a matching success notification interface provided according to an embodiment of this application. (a) 1001 in the figure is the third prompt message.

[0146] In one possible implementation, the terminal prompts whether the virtual object has been confirmed. Accordingly, if the first virtual object has confirmed its participation in the target virtual event, the terminal displays a fourth prompt message. This fourth prompt message indicates whether each virtual object has confirmed its participation in the target virtual event. The fourth prompt message may include the target virtual event to which the first virtual team is to participate, the multiple virtual objects matched to the target virtual event, and whether each virtual object has confirmed its participation. See also... Figure 10 As shown in Figure (b), 1002 represents the fourth notification message. As shown in the figure, there are a total of 3 virtual objects matched to the target virtual event (i.e., virtual objects in the first virtual team and the target virtual team). Virtual objects named A and B have confirmed their participation in the target virtual event, while virtual object named C has not yet confirmed its participation.

[0147] In one possible implementation, when both the first virtual team and the target virtual team determine the virtual objects participating in the target virtual event, the server has two processing methods: If the server obtains the virtual object data when the virtual object joins the virtual team, then, if both the first virtual team and the target virtual team determine participation in the target virtual event, the server directly sends the virtual object data within the aforementioned virtual teams to the event server and runs the target virtual event on the event server. If the server obtains the basic data of the virtual object when the virtual object joins the virtual team, then, if both the first virtual team and the target virtual team determine participation in the target virtual event, the server executes steps 804 to 806 as described below.

[0148] In another possible implementation, the presence of virtual objects in the first virtual team and the target virtual team that are not confirmed to participate in the target virtual event falls into three categories: 1) The first virtual team has virtual objects that are not confirmed to participate in the target virtual event, but the target virtual team does not have any virtual objects that are not confirmed to participate in the target virtual event; 2) The first virtual team does not have any virtual objects that are not confirmed to participate in the target virtual event, but the target virtual team does have virtual objects that are not confirmed to participate in the target virtual event; 3) Both the first virtual team and the target virtual team have virtual objects that are not confirmed to participate in the target virtual event.

[0149] The following section uses the first virtual team as an example to explain the server's data processing procedures in cases where there are unconfirmed virtual objects participating in the target virtual event in the first virtual team.

[0150] If there are no virtual objects in the first virtual team that are not confirmed to participate in the target virtual event, the server retains the data of each virtual object in the currently stored first virtual team and executes step 803 accordingly. Optionally, when the server executes this step, it can start execution after a specific virtual object in the first virtual team performs a confirmation matching operation, or the server can start execution automatically; this embodiment of the application does not impose any restrictions on this. In this case, the first virtual object performs a confirmation matching operation through the quick rematch option provided by the terminal. The quick rematch option is used to directly rematch without changing the virtual objects in the first virtual team.

[0151] If there are virtual objects in the first virtual team that are not confirmed to participate in the target virtual event, the server clears the data of each virtual object in the currently stored first virtual team. If a specific virtual object in the first virtual team performs a confirmation matching operation, the server obtains the basic data of each virtual object in the current first virtual team stored in the virtual world server of the first virtual object. Optionally, the server can also establish communication with the virtual world server from which each virtual object in the current first virtual team originates based on this data, and obtain the corresponding virtual object data from the aforementioned virtual world server.

[0152] The above method provides a quick rematch function without having to disband the first virtual team and rebuild the team, which is more convenient and faster, shortens the time required for team configuration and matching, and improves overall efficiency.

[0153] 804. The server retrieves the virtual object data of each virtual object from the virtual world server of each virtual object in the first virtual team and the target virtual team.

[0154] In this embodiment, the server establishes a connection with the virtual world server of each virtual object based on the basic data of each virtual object that has been acquired, and obtains the corresponding virtual object data from the virtual world server of each virtual object.

[0155] In one possible implementation, the virtual world server sends virtual object data to the server. Accordingly, if the virtual world server of any of the aforementioned virtual objects receives a kick-out request, the server obtains the virtual object data of the corresponding virtual object in the virtual world server. The kick-out request is used to instruct the corresponding virtual object in the virtual world server to be kicked out of the virtual world run by that virtual world server. The aforementioned corresponding virtual object refers to a virtual object in the first virtual team or the target virtual team.

[0156] 805. The server stores the acquired virtual object data in the first database, which is used to temporarily store data for virtual objects participating in virtual events.

[0157] In this embodiment, the first database can store virtual object data of virtual objects participating in different virtual events based on virtual events, or it can store virtual object data of each virtual object separately based on the account information of the virtual object. This embodiment does not limit this.

[0158] 806. The server loads the virtual object data from the first database into the event server, and runs the target virtual event on the event server.

[0159] In this embodiment, the server stores virtual object data in a first database and loads the virtual object data from the first database into an event server. After the server loads the virtual object data from the first database into the event server, it sends the address of the event server to the clients of each virtual object in the first virtual team and the target virtual team. The address of the event server is used by the clients of each virtual object in the first virtual team and the target virtual team to establish a connection with the event server. This method allows clients to log in to the event server, improving the operational efficiency of the target virtual event.

[0160] It should be noted that steps 804 to 806 above are an exemplary method for the server to run the target virtual event on the event server based on the virtual object data within the first virtual team and the target virtual team when the first virtual team and the target virtual team determine that they will participate in the target virtual event.

[0161] By writing virtual object data back to the first database and then loading it into the event server, single-segment writing is achieved. This avoids the risk of data being overwritten due to multiple data runs occurring in both the virtual world server and the event server. This not only ensures that the event server loads the latest virtual object data but also improves data security.

[0162] It should be noted that if any virtual object in the first virtual team or the target virtual team determines to exit the target virtual event, then the virtual object re-enters the virtual world run by the virtual world server corresponding to the virtual object, and updates are performed in that virtual world based on the result of the target virtual event. Specifically, a virtual object exiting the target virtual event includes: the virtual object exiting the target virtual event when it has ended, and the virtual object exiting the target virtual event midway through its execution. Taking the exit of a virtual object from the target virtual event as an example, the server implements the above process in either of the following methods (1) or (2) in the two cases described above.

[0163] Method (1): The above process is achieved by loading the virtual object data in the first database and the virtual events in the second database into the virtual world server. The first database is used to temporarily store data for virtual objects participating in virtual events, and the second database is used to temporarily store virtual event data for virtual objects that are determined to exit the virtual event.

[0164] Accordingly, the server loads the virtual object data from the first database into the virtual world server corresponding to the virtual object, so that the virtual object re-enters the virtual world run by the virtual world server; it retrieves the virtual event data of the virtual object from the event server, which is used to record the results of the virtual object's participation in the target virtual event; it stores the retrieved virtual event data into the second database; and it loads the virtual event data from the second database into the virtual world server. After the virtual events are loaded into the virtual world server, the virtual world server updates the virtual object data based on the virtual event data.

[0165] The above method loads virtual object data and virtual event data separately because, if residual data exists on the virtual world server, directly loading new virtual object data from the event server could lead to data overwriting. Therefore, single-section writing is used, meaning only the virtual world server is allowed to rewrite virtual object data, while the virtual event data provided by the event server only involves the settlement information of the target virtual event. This way, even if data anomalies occur on the event server, it will not directly affect the operation of the virtual world. Therefore, this method reduces the risk of data overwriting and improves data security.

[0166] Method (2): The above process is achieved by loading virtual object data from the third database into the virtual world server. The third database is used to temporarily store updated virtual object data for virtual objects that have exited the virtual event.

[0167] Accordingly, the server retrieves the virtual object data of the virtual object from the event server; stores the retrieved virtual object data in a third database; and loads the virtual object data from the third database into the virtual world server corresponding to the virtual object, so that the virtual object re-enters the virtual world run by the virtual world server and obtains the result of the target virtual event.

[0168] The above method loads new virtual object data directly from the event server, without having to load virtual object data and virtual event data separately, which greatly improves the efficiency of data processing.

[0169] In one possible implementation, the server sends the address of the virtual world server to the client. Accordingly, after loading the virtual object data from a first or third database into the corresponding virtual world server, the server sends the address of the virtual world server to the client of the virtual object. This address is used by the client to establish a connection with the virtual world server. This method allows the client to quickly log in to the virtual world server.

[0170] It should be noted that the virtual world server and event server in this application embodiment can be UE4ds or a ds server that can carry more virtual objects. This application embodiment does not impose any restrictions on this.

[0171] This application provides a method for running a target virtual event, which enables cross-virtual world server matching of virtual objects on a virtual team basis, and runs the target virtual event on an event server. This isolates the virtual world from running the virtual world on the virtual world server, preventing data interference between the virtual world server and the event server, improving data security, and making it more efficient and faster to add new virtual events and corresponding gameplay without requiring significant modifications to the virtual world server corresponding to the virtual world, thus improving overall scalability. Furthermore, since virtual objects within any virtual world server are not limited to matching other virtual objects within that virtual world server, the waiting time for the target virtual event to run is greatly shortened, improving overall operational efficiency. In addition, supporting cross-virtual world server matching also helps to improve the interaction between virtual objects and increase participation in virtual events.

[0172] To illustrate the method for running the target virtual event proposed in this application, an example is provided where a server runs a first process, a second process, and a third process. The first process is the `roomsvr` process, which handles the team-up operations of virtual objects and temporarily stores the virtual team data for each virtual team. Team-up operations include creating virtual teams and inviting virtual objects from the same or different virtual worlds to join the team after creation. The virtual team data for each virtual team includes the basic data of each virtual object within that team. The second process is `matchsvr`, which matches virtual teams participating in the same virtual event together based on the virtual event to be participated in and the event's requirements, thus performing a single virtual event. The third process is the `battlesvr` process, which manages the lifecycle of the event server and temporarily stores the team matching data after each successful match. The event server's lifecycle refers to the process from its startup to its shutdown. The team matching data after any successful match includes the virtual team data of the multiple virtual teams that were matched together. Building upon this foundation, to enable data communication, the server also runs a fourth, fifth, sixth, and seventh process. The fourth process, gamesvr, provides the main entry point for the virtual game and facilitates data communication with clients of virtual objects. The fifth process, starpsvr, manages the virtual world server and handles data communication related to it. The sixth process, starpaccountsvr, handles database writes. The seventh process, starpaccountsvt, also manages the virtual world server. It should be noted that each process can be implemented using a scalable server cluster.

[0173] When a first process, a second process, and a third process are running on the server, for ease of describing the initiation process of the target virtual event in the execution method of the target virtual event, please refer to [link to documentation]. Figure 11 As shown, Figure 11 This is a schematic diagram of a process for initiating a target virtual event according to an embodiment of this application. The process includes the following steps (1)-(10).

[0174] First, step (1) is executed, in response to the client initiating a match, and the fourth process is notified. It should be noted that in response to the creation and joining of virtual teams by virtual objects, basic data is pulled from the virtual world server corresponding to the virtual object and synchronized to the first process. When the first process obtains the basic data within the virtual team, step (2) is executed, and the first process performs a match verification. When all virtual objects within the virtual team pass the match verification, step (3) is executed, and the first process sends a match matching request to the second process. This match matching request is used to request that the virtual team be matched with other virtual teams that are to participate in the same virtual event, so as to conduct a virtual event. The first process sends the virtual team data to the second process. The virtual team data includes the basic data of each virtual object within the virtual team. When the virtual team is successfully matched with other virtual teams, step (4) is executed, and the second process synchronizes the team matching data to the third process. This team matching data includes the virtual team data of the multiple virtual teams that were successfully matched this time. Step (5) is executed, and the second process notifies the clients of the virtual objects in the multiple virtual teams that were successfully matched this time to enter the confirmation process. This confirmation process is used to confirm whether to enter the virtual event. The notification is sent to the virtual object's client via the link of the second process, the first process, the fourth process, and the communication interface. If any virtual object confirms its entry into the virtual event, step (6) is executed, and the virtual object's client notifies the third process that the virtual object has confirmed its entry into the virtual event. This notification is sent to the third process via the link of the communication interface, the fourth process, and the first process. If all virtual objects in the multiple successfully matched virtual teams confirm their entry into the virtual event, step (7) is executed, and the third process starts the event server to run the virtual event on the event server.

[0175] It should be noted that in the above process, client-initiated matching refers to the virtual object performing a confirmation matching operation. The virtual object's performance of this confirmation matching operation is not restricted by whether it has formed a virtual team. If the virtual object has not formed a virtual team but directly performs the confirmation matching operation, a single-person virtual team is automatically created for the virtual object. If the virtual object has formed a virtual team, a virtual team is created in response to the virtual object's team creation operation before the virtual object performs the confirmation matching operation; this virtual team includes the virtual object. Furthermore, in response to the virtual object's invitation operation to any virtual object running on any virtual world server, if the invited virtual object confirms its participation, the invited virtual object is added to the first virtual team.

[0176] When a first process, a second process, and a third process are running on the server, for ease of description of the process of adding the virtual object to the target virtual event in the execution method of the target virtual event, please refer to [link to documentation]. Figure 12As shown, Figure 12 This is a flowchart illustrating a virtual object joining event according to an embodiment of this application. The process includes the following steps (1)-(11).

[0177] First, after the third process starts the event server, step (1) is executed. The event server triggers a success callback after starting the event server. The protocol in this process can be irpc Create Game Session Result Event. Steps (2) and (3) are executed. The third process requests the virtual world server to kick the virtual object out through the fifth process. At this time, the remote call protocol between the third process and the fifth process can be rpc StarP World Exit, and the remote call protocol between the fifth process and the virtual world server can be ipc Player Exit Ds. After receiving the kick-out request, the virtual world server will write the virtual object data back to the first database. After the data is written back, steps (4) and (5) are executed. The virtual world server notifies the third process that the virtual object has been successfully kicked out through the fifth process. At this time, the remote call protocol between the virtual world server and the fifth process can be irpc Player Ds Ofline. After the third process receives the successful kick-out callback from the virtual world server, step (6) is executed. The third process notifies the event server to load the virtual object data. The remote call protocol in this process can be add Player. If the event server finishes loading the virtual object data, step (7) is executed. The event server notifies the third process of the result. The remote call protocol in this process can be addPlayer Finish. If the event server successfully loads the virtual object data, steps (8), (9), and (10) are executed. The third process notifies the client of the event server's address through the link between the first and fourth processes, and the virtual object in the fourth process saves the virtual event data. At this time, the remote call protocol between the third process and the first process can be rpc Battle Create Result, the remote call protocol between the first process and the fourth process can be rpcMatch Succ, and the remote call protocol between the fourth process and the communication interface can be Match Succ Nf protocol. Then, step (11) is executed. The client of the virtual object establishes a connection with the event server, thereby allowing the virtual object to enter the virtual event.

[0178] When a first process, a second process, and a third process are running on the server, for ease of description of the process by which the virtual object exits the target virtual event during the execution method of the target virtual event, see [link to documentation]. Figure 13 As shown, Figure 13This is a flowchart illustrating a virtual object exit event according to an embodiment of this application. The process includes the following steps (1)-(10).

[0179] When a virtual object exits the target virtual event, first, step (1) is executed, where the event server writes the virtual event data to the second database. This process is implemented through the sixth process. Steps (2), (3), (4), and (5) are executed, where the event server notifies the third process that the virtual object has exited the target virtual event. The third process then notifies the client, through the first and fourth processes, that the virtual object has exited the target virtual event. For example, the event server sends an IPC Quit Battle request to the third process, the third process sends an RPC Quit Battle Room Req request to the first process, the first process sends an RPC Quit Battle Nltf request to the fourth process, and the fourth process sends a Quit Battle Ntf notification to the communication interface. When the client receives the notification, step (6) is executed, where the client initiates a request to enter the virtual world server. For example, the client sends a StarPEnter_C2S_Msg request to the virtual world server. Step (7) is executed, where the fifth process starts the virtual world server and notifies the virtual world server to load the virtual object data. The protocol used in this process can be add Player. Once the virtual object data is loaded, step (8) is executed, and the virtual world server notifies the fifth process of the result. The protocol in this process can be add Player Finish. Then, step (9) is executed, and the fifth process notifies the client of the address of the virtual world server through the fourth process. The protocol in this process can be StarPDSInfo Ntf. Once the client obtains the address of the virtual world server, step (10) is executed, and the client of the virtual object establishes a connection with the virtual world server, thereby allowing the virtual object to enter the virtual world. After the virtual object enters the virtual world, step (11) is executed, and virtual event data is loaded from the second database to process the settlement of the target virtual event, such as recording the level completion mark and issuing rewards.

[0180] In this way, the server realizes data communication through a remote call protocol between multiple server processes, thereby realizing the running method of the target virtual event proposed in this application, shortening the waiting time for the target virtual event to be started, and improving the overall running efficiency.

[0181] Figure 14 This is a block diagram of a target virtual event execution apparatus provided in an embodiment of this application. The apparatus is used to execute the steps of the above-described target virtual event execution method, see [link to relevant documentation]. Figure 14The device includes: an acquisition module 1401, a matching module 1402, and an operation module 1403.

[0182] The acquisition module 1401 is used to acquire the first virtual team to participate in the target virtual event. The first virtual team includes virtual objects from the first server in the virtual world server.

[0183] The acquisition module 1401 is also used to acquire at least one second virtual team to participate in the target virtual event. The second virtual team includes virtual objects from a second server in the virtual world server. The second server and the first server run different virtual worlds.

[0184] Matching module 1402 is used to match from at least one second virtual team based on the first virtual team to obtain the target virtual team;

[0185] The execution module 1403 is used to run the target virtual event on the event server based on the virtual object data within the first virtual team and the target virtual team if the first virtual team and the target virtual team determine that they will participate in the target virtual event.

[0186] In one possible implementation, the matching module 1402 is used to match from at least one second virtual team based on the number of virtual objects in the first virtual team to obtain a target virtual team, wherein the sum of the number of virtual objects in the target virtual team and the number of virtual objects in the first virtual team satisfies the operational requirements of the target virtual event.

[0187] In one possible implementation, the execution module 1403 is used to obtain virtual object data of each virtual object from the virtual world server of each virtual object in the first virtual team and the target virtual team respectively; store the obtained virtual object data in a first database, which is used to temporarily store data for virtual objects participating in virtual events; load the virtual object data from the first database into the event server, and run the target virtual event on the event server.

[0188] In one possible implementation, the execution module 1403 is further configured to send the address of the event server to the client of each virtual object in the first virtual team and the target virtual team, the address of the event server being used by the client of each virtual object in the first virtual team and the target virtual team to establish a connection with the event server.

[0189] In one possible implementation, Figure 15 This is a block diagram of another apparatus for running a target virtual event provided in an embodiment of this application. The apparatus further includes:

[0190] The verification module 1501 is used to perform a pre-verification of each virtual object in the first virtual team. The pre-verification is used to confirm whether the virtual object is qualified to participate in the matching.

[0191] In one possible implementation, the matching module 1402 is further configured to perform a step of matching from at least one second virtual team to obtain a target virtual team, provided that each virtual object in the first virtual team has passed the pre-verification.

[0192] The acquisition module 1401 is also used to restart the process from the first virtual team to the first virtual team if any virtual object in the first virtual team fails the pre-matching check.

[0193] In one possible implementation, the device further includes:

[0194] The loading module 1502 is used to load the virtual object data of any virtual object in the first virtual team and the target virtual team from the first database to the virtual world server corresponding to the virtual object if the virtual object determines to exit the target virtual event, so that the virtual object can re-enter the virtual world run by the virtual world server. The first database is used to temporarily store data for virtual objects participating in the virtual event.

[0195] In one possible implementation, the loading module 1502 is further configured to obtain virtual event data of virtual objects from the event server, the virtual event data being used to record the results of virtual objects participating in target virtual events; store the obtained virtual event data in a second database, the second database being used to temporarily store virtual event data for virtual objects that are determined to exit the virtual event; and load the virtual event data from the second database into the virtual world server.

[0196] In one possible implementation, the loading module 1502 is also used to send the address of the virtual world server to the client of the virtual object, the address of the virtual world server being used by the client of the virtual object to establish a connection with the virtual world server.

[0197] In one possible implementation, the loading module 1502 is further configured to: if any virtual object in the first virtual team and the target virtual team determines to exit the target virtual event, obtain updated virtual object data of the virtual object from the event server; store the obtained updated virtual object data in a third database, the third database being used to temporarily store the updated virtual object data for the virtual object that has determined to exit the virtual event; and load the updated virtual object data from the third database into the virtual world server corresponding to the virtual object, so that the virtual object re-enters the virtual world run by the virtual world server and obtains the result of the target virtual event.

[0198] This application provides a device for running a target virtual event. Instead of running the target virtual event within a virtual world server that already contains virtual worlds, a separate event server is provided for its execution. This eliminates the limitation on the source of the virtual objects involved in the target virtual event. Virtual objects participating in the target virtual event are not limited to those from the same virtual world server but can come from different virtual world servers, enabling cross-server matching. Because this expands the range of virtual objects in the matching pool and increases the number of virtual objects in the pool, the time spent waiting for a sufficient number of virtual objects to be collected to initiate the target virtual event is significantly reduced, improving overall efficiency.

[0199] It should be noted that the target virtual event running device provided in the above embodiments is only illustrated by the division of the above functional modules when running the application. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the terminal can be divided into different functional modules to complete all or part of the functions described above. In addition, the target virtual event running device and the target virtual event running method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0200] Figure 16 This is a block diagram of a virtual team configuration device provided in an embodiment of this application. This device is used to execute the steps of the virtual team configuration method described above, see below. Figure 16 The device includes: an interface display module 1601, an object display module 1602, a sending module 1603, and a team display module 1604.

[0201] The interface display module 1601 is used to respond to the team configuration command of the first virtual object and display the member configuration interface of the first virtual team. The team configuration command instructs the configuration of the first virtual team participating in the target virtual event.

[0202] The object display module 1602 is used to display candidate virtual objects from different virtual world servers in the member configuration interface of the first virtual team, and to display a source differentiation identifier. The source differentiation identifier indicates that the candidate virtual objects and the first virtual object come from different virtual world servers, and different virtual world servers run different virtual worlds.

[0203] The sending module 1603 is used to send a first prompt message to the second virtual object in response to the selection operation of the second virtual object among the candidate virtual objects. The first prompt message is used to prompt the second virtual object to join the first virtual team to participate in the target virtual event.

[0204] The team display module 1604 is used to display the first virtual object and the second virtual object in the first virtual team if the second virtual object joins the first virtual team.

[0205] In one possible implementation, Figure 17 This is a block diagram of another virtual team configuration device provided in an embodiment of this application. The device further includes:

[0206] The message display module 1701 is used to display a second prompt message in response to the matching instruction of the first virtual object. The matching instruction indicates that the first virtual team is matched with a virtual team, and the second prompt message is used to indicate that the matching is in progress with the virtual team that is to participate in the target virtual event.

[0207] In one possible implementation, the message display module 1701 is further configured to perform at least one of the following: if the first virtual team and the target virtual team to participate in the target virtual event have been successfully matched, display a third prompt message, the third prompt message being used to prompt confirmation of participation in the target virtual event; if the first virtual object has been confirmed to participate in the target virtual event, display a fourth prompt message, the fourth prompt message being used to prompt each virtual object whether it has confirmed participation in the target virtual event.

[0208] In one possible implementation, the device further includes:

[0209] The connection module 1702 is used to establish a connection with the event server based on the received address of the event server, so that the first virtual object can participate in the target virtual event running on the event server.

[0210] In one possible implementation, the connection module 1702 is further configured to, if the first virtual object confirms exiting the target virtual event, establish a connection with the virtual world server based on the address of the virtual world server corresponding to the first virtual object, so that the first virtual object re-enters the virtual world run by the virtual world server.

[0211] This application provides a virtual team configuration device that displays candidate virtual objects from different virtual world servers in the member configuration interface, providing the function of forming teams across virtual world servers. By displaying a source distinction identifier in the member configuration interface, it can intuitively indicate whether the candidate virtual object and the first virtual object come from different virtual world servers, so that users do not need to obtain the above information from other complex paths, improving the intuitiveness of information display and improving the configuration efficiency of virtual teams.

[0212] It should be noted that the virtual team configuration device provided in the above embodiments is only illustrated by the division of the above functional modules when the application is running. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the terminal can be divided into different functional modules to complete all or part of the functions described above. In addition, the virtual team configuration device and the virtual team configuration method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0213] Figure 18 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application. The terminal 1800 can be a portable mobile terminal, such as a smartphone, tablet computer, laptop computer, or desktop computer. The terminal 1800 may also be referred to as user equipment, portable terminal, laptop terminal, desktop terminal, or other names.

[0214] Typically, terminal 1800 includes a processor 1801 and a memory 1802.

[0215] Processor 1801 may include one or more processing cores, such as a quad-core processor or an octa-core processor. Processor 1801 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 1801 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), 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 one possible implementation, processor 1801 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content required to be displayed on the screen. In some embodiments, processor 1801 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0216] Memory 1802 may include one or more computer-readable storage media, which may be non-transitory. Memory 1802 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 one possible implementation, the non-transitory computer-readable storage media in memory 1802 is used to store at least one computer program, which is executed by processor 1801 to implement the virtual team configuration method provided in the method embodiments of this application.

[0217] In one possible implementation, terminal 1800 may also optionally include: a peripheral device interface 1803 and at least one peripheral device. The processor 1801, memory 1802, and peripheral device interface 1803 can be connected via a bus or signal line. Each peripheral device can be connected to peripheral device interface 1803 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of: radio frequency circuitry 1804, display screen 1805, camera assembly 1806, audio circuitry 1807, and power supply 1808.

[0218] Peripheral device interface 1803 can be used to connect at least one I / O (Input / Output) related peripheral device to processor 1801 and memory 1802. In one possible implementation, processor 1801, memory 1802, and peripheral device interface 1803 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 1801, memory 1802, and peripheral device interface 1803 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0219] The radio frequency (RF) circuit 1804 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 1804 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 1804 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. In one possible implementation, the RF circuit 1804 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc. The RF circuit 1804 can communicate with other terminals via at least one wireless communication protocol. This wireless communication protocol includes, but is not limited to: the World Wide Web, metropolitan area networks, intranets, various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks, and / or WiFi (Wireless Fidelity) networks. In one possible implementation, the RF circuit 1804 may also include circuitry related to NFC (Near Field Communication), which is not limited in this application.

[0220] Display screen 1805 is used to display a UI (User Interface). This UI may include graphics, text, icons, videos, and any combination thereof. When display screen 1805 is a touch display screen, it also has the ability to collect touch signals on or above its surface. These touch signals can be input as control signals to processor 1801 for processing. In this case, display screen 1805 can also be used to provide virtual buttons and / or a virtual keyboard, also known as soft buttons and / or a soft keyboard. In one possible implementation, there may be one display screen 1805, located on the front panel of terminal 1800; in other embodiments, there may be at least two display screens, respectively located on different surfaces of terminal 1800 or in a folded design; in other embodiments, display screen 1805 may be a flexible display screen, located on a curved or folded surface of terminal 1800. Furthermore, display screen 1805 may also be configured as a non-rectangular, irregular shape, i.e., a non-rectangular screen. The display screen 1805 can be made of materials such as LCD (Liquid Crystal Display) and OLED (Organic Light-Emitting Diode).

[0221] The camera assembly 1806 is used to acquire images or videos. In one possible implementation, the camera assembly 1806 includes a front-facing camera and a rear-facing camera. Typically, the front-facing camera is located on the front panel of the terminal, and the rear-facing camera is located on the back of the terminal. In one possible implementation, there are at least two rear-facing cameras, which are any one of a main camera, a depth-sensing camera, a wide-angle camera, and a telephoto camera, to achieve background blurring by fusion of the main camera and the depth-sensing camera, panoramic shooting by fusion of the main camera and the wide-angle camera, VR (Virtual Reality) shooting, or other fusion shooting functions. In one possible implementation, the camera assembly 1806 may also include a flash. The flash can be a single-color temperature flash or a dual-color temperature flash. A dual-color temperature flash refers to a combination of a warm-light flash and a cool-light flash, which can be used for light compensation at different color temperatures.

[0222] The audio circuit 1807 may include a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, converting them into electrical signals that are input to the processor 1801 for processing, or to the radio frequency circuit 1804 for voice communication. For stereo sound acquisition or noise reduction purposes, multiple microphones may be used, each positioned at a different location on the terminal 1800. The microphone may also be an array microphone or an omnidirectional microphone. The speaker is used to convert electrical signals from the processor 1801 or the radio frequency circuit 1804 into sound waves. The speaker may be a conventional film speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can convert electrical signals not only into audible sound waves but also into inaudible sound waves for purposes such as distance measurement. In one possible implementation, the audio circuit 1807 may also include a headphone jack.

[0223] The power supply 1808 is used to power the various components in the terminal 1800. The power supply 1808 can be AC ​​power, DC power, a disposable battery, or a rechargeable battery. When the power supply 1808 includes a rechargeable battery, the rechargeable battery can support wired or wireless charging. The rechargeable battery can also be used to support fast charging technology.

[0224] In one possible implementation, terminal 1800 further includes one or more sensors 1809. The one or more sensors 1809 include, but are not limited to: accelerometer 1810, gyroscope 1811, pressure sensor 1812, optical sensor 1813, and proximity sensor 1814.

[0225] Accelerometer 1810 can detect the magnitude of acceleration along the three axes of a coordinate system established by terminal 1800. For example, accelerometer 1810 can be used to detect the components of gravitational acceleration along the three axes. Processor 1801 can control display screen 1805 to display the user interface in either a landscape or portrait view based on the gravitational acceleration signal acquired by accelerometer 1810. Accelerometer 1810 can also be used for games or for acquiring user motion data.

[0226] The gyroscope sensor 1811 can detect the orientation and rotation angle of the terminal 1800. The gyroscope sensor 1811 can work in conjunction with the accelerometer sensor 1810 to acquire the user's 3D movements on the terminal 1800. Based on the data acquired by the gyroscope sensor 1811, the processor 1801 can perform the following functions: motion sensing (e.g., changing the UI based on the user's tilt), image stabilization during shooting, game control, and inertial navigation.

[0227] The pressure sensor 1812 can be disposed on the side bezel of the terminal 1800 and / or on the lower layer of the display screen 1805. When the pressure sensor 1812 is disposed on the side bezel of the terminal 1800, it can detect the user's grip signal on the terminal 1800, and the processor 1801 can perform left / right hand recognition or quick operation based on the grip signal collected by the pressure sensor 1812. When the pressure sensor 1812 is disposed on the lower layer of the display screen 1805, the processor 1801 can control the operable components on the UI interface based on the user's pressure operation on the display screen 1805. The operable components include at least one of the following: button components, scroll bar components, icon components, and menu components.

[0228] An optical sensor 1813 is used to collect ambient light intensity. In one embodiment, the processor 1801 can control the display brightness of the display screen 1805 based on the ambient light intensity collected by the optical sensor 1813. Optionally, when the ambient light intensity is high, the display brightness of the display screen 1805 is increased; when the ambient light intensity is low, the display brightness of the display screen 1805 is decreased. In another embodiment, the processor 1801 can also dynamically adjust the shooting parameters of the camera assembly 1809 based on the ambient light intensity collected by the optical sensor 1813.

[0229] The proximity sensor 1814, also known as the distance sensor, is installed on the front panel of the terminal 1800. The proximity sensor 1814 is used to detect the distance between the user and the front of the terminal 1800. In one embodiment, when the proximity sensor 1814 detects that the distance between the user and the front of the terminal 1800 is gradually decreasing, the processor 1801 controls the display screen 1805 to switch from a screen-on state to a screen-off state; when the proximity sensor 1814 detects that the distance between the user and the front of the terminal 1800 is gradually increasing, the processor 1801 controls the display screen 1805 to switch from a screen-off state to a screen-on state.

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

[0231] Figure 19 This is a schematic diagram of a server structure provided in an embodiment of this application. The server 1900 can vary significantly due to different configurations or performance. It may include one or more Central Processing Units (CPUs) 1901 and one or more memories 1902. The memories 1902 store at least one computer program, which is loaded and executed by the processor 1901 to implement the method for running the target virtual event provided in the various method embodiments described above. Of course, the server may also have wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The server may also include other components for implementing device functions, which will not be elaborated here.

[0232] This application also provides a computer-readable storage medium storing at least one computer program. This computer program is loaded and executed by a processor to implement the method for running the target virtual event and the method for configuring the virtual team in the above embodiments. For example, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, floppy disk, and optical data storage device, etc.

[0233] This application also provides a computer program product, including a computer program that is executed by a processor to implement the method for running target virtual events and the method for configuring virtual teams in the embodiments of this application.

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

[0235] The above are merely optional embodiments of this application and are 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 executing a target virtual event, characterized in that, The method includes: Obtain the first virtual team to participate in the target virtual event, the first virtual team including virtual objects from the first server in the virtual world server; Obtain at least one second virtual team to participate in the target virtual event, the second virtual team comprising virtual objects from a second server in the virtual world server, the second server and the first server running different virtual worlds; Based on the first virtual team, a target virtual team is obtained by matching from the at least one second virtual team; If the first virtual team and the target virtual team determine that they will participate in the target virtual event, the target virtual event will be run on the event server based on the virtual object data within the first virtual team and the target virtual team.

2. The method according to claim 1, characterized in that, The step of matching from the at least one second virtual team to obtain a target virtual team based on the first virtual team includes: Based on the number of virtual objects in the first virtual team, a target virtual team is obtained by matching from at least one second virtual team. The sum of the number of virtual objects in the target virtual team and the number of virtual objects in the first virtual team satisfies the operational requirements of the target virtual event.

3. The method according to claim 1, characterized in that, The step of running the target virtual event on the event server based on the virtual object data within the first virtual team and the target virtual team includes: The virtual object data of each virtual object is obtained from the virtual world server corresponding to each virtual object in the first virtual team and the target virtual team respectively; The acquired virtual object data is stored in a first database, which is used to temporarily store data for virtual objects participating in virtual events. The virtual object data is loaded from the first database into the event server, and the target virtual event is run on the event server.

4. The method according to claim 3, characterized in that, After loading the virtual object data from the first database into the event server, the method further includes: The address of the event server is sent to the client of each virtual object in the first virtual team and the target virtual team. The address of the event server is used by the client of each virtual object in the first virtual team and the target virtual team to establish a connection with the event server.

5. The method according to claim 1, characterized in that, Before matching from the at least one second virtual team based on the first virtual team to obtain the target virtual team, the method further includes: A preliminary verification is performed on each virtual object in the first virtual team. The preliminary verification is used to confirm whether the virtual object is qualified to participate in the matching.

6. The method according to claim 5, characterized in that, The method further includes: If each virtual object in the first virtual team passes the pre-test, the step of matching from the at least one second virtual team based on the first virtual team to obtain the target virtual team is executed. If any virtual object in the first virtual team fails the pre-matching check, the process restarts from the step of obtaining the first virtual team to participate in the target virtual event.

7. The method according to claim 1, characterized in that, The method further includes: If any virtual object in the first virtual team or the target virtual team determines to exit the target virtual event, the virtual object data of the virtual object is loaded from the first database to the virtual world server corresponding to the virtual object, so that the virtual object re-enters the virtual world run by the virtual world server. The first database is used to temporarily store data for virtual objects participating in the virtual event.

8. The method according to claim 7, characterized in that, The method further includes: The virtual event data of the virtual object is obtained from the event server, and the virtual event data is used to record the results of the virtual object's participation in the target virtual event; The acquired virtual event data is stored in a second database, which is used to temporarily store virtual event data for virtual objects that are determined to exit the virtual event. The virtual event data is loaded from the second database into the virtual world server.

9. The method according to claim 7, characterized in that, After loading the virtual object data of the virtual object from the first database to the virtual world server corresponding to the virtual object, the method further includes: The address of the virtual world server is sent to the client of the virtual object, and the address of the virtual world server is used by the client of the virtual object to establish a connection with the virtual world server.

10. The method according to claim 1, characterized in that, The method further includes: If any virtual object in the first virtual team and the target virtual team determines to exit the target virtual event, the updated virtual object data of the virtual object is obtained from the event server; The obtained updated virtual object data is stored in a third database, which is used to temporarily store the updated virtual object data for virtual objects that have determined to exit virtual events. The updated virtual object data is loaded from the third database into the virtual world server corresponding to the virtual object, so that the virtual object re-enters the virtual world run by the virtual world server and obtains the result of the target virtual event.

11. A method for configuring a virtual team, characterized in that, The method includes: In response to the team configuration command of the first virtual object, the member configuration interface of the first virtual team is displayed, wherein the team configuration command instructs the configuration of the first virtual team participating in the target virtual event; In the member configuration interface of the first virtual team, candidate virtual objects from different virtual world servers are displayed, and a source differentiation identifier is displayed. The source differentiation identifier indicates that the candidate virtual objects and the first virtual object come from different virtual world servers, and different virtual world servers run different virtual worlds. In response to the selection operation of the second virtual object among the candidate virtual objects, a first prompt message is sent to the second virtual object. The first prompt message is used to prompt the second virtual object to join the first virtual team to participate in the target virtual event. If the second virtual object joins the first virtual team, the first virtual object and the second virtual object are displayed in the first virtual team.

12. The method according to claim 11, characterized in that, The method further includes: In response to the matching instruction of the first virtual object, a second prompt message is displayed. The matching instruction indicates that the first virtual team is being matched with a virtual team, and the second prompt message is used to indicate that a virtual team is being matched to participate in the target virtual event.

13. The method according to claim 11, characterized in that, The method further includes at least one of the following: If the first virtual team and the target virtual team to participate in the target virtual event have been successfully matched, a third prompt message is displayed, which is used to prompt confirmation of participation in the target virtual event; If the first virtual object has confirmed its participation in the target virtual event, a fourth prompt message is displayed. The fourth prompt message is used to prompt each virtual object whether it has confirmed its participation in the target virtual event.

14. The method according to claim 13, characterized in that, The method further includes: Based on the received address of the event server, a connection is established with the event server so that the first virtual object can participate in the target virtual event running on the event server.

15. The method according to claim 13, characterized in that, The method further includes: If the first virtual object confirms its exit from the target virtual event, a connection is established with the virtual world server based on the received address of the virtual world server corresponding to the first virtual object, so that the first virtual object can re-enter the virtual world run by the virtual world server.

16. A device for running a target virtual event, characterized in that, The device includes: The acquisition module is used to acquire the first virtual team to participate in the target virtual event. The first virtual team includes virtual objects from the first server in the virtual world server. The acquisition module is further configured to acquire at least one second virtual team to participate in the target virtual event, the second virtual team including virtual objects from a second server in the virtual world server, the second server and the first server running different virtual worlds; The matching module is used to match the first virtual team from the at least one second virtual team to obtain the target virtual team; The execution module is configured to, if the first virtual team and the target virtual team determine that they will participate in the target virtual event, run the target virtual event on the event server based on the virtual object data within the first virtual team and the target virtual team.

17. A configuration device for a virtual team, characterized in that, The device includes: The interface display module is used to display the member configuration interface of the first virtual team in response to the team configuration command of the first virtual object, wherein the team configuration command instructs the first virtual team to configure the participation of the target virtual event; The object display module is used to display candidate virtual objects from different virtual world servers in the member configuration interface of the first virtual team, and display a source differentiation identifier. The source differentiation identifier indicates that the candidate virtual objects and the first virtual object come from different virtual world servers, and different virtual world servers run different virtual worlds. The sending module is configured to, in response to the selection operation of the second virtual object among the candidate virtual objects, send a first prompt message to the second virtual object, the first prompt message being used to prompt the second virtual object to join the first virtual team to participate in the target virtual event; The team display module is used to display the first virtual object and the second virtual object in the first virtual team if the second virtual object joins the first virtual team.

18. A computer device, characterized in that, The computer device includes a processor and a memory, the memory being used to store at least one computer program, the at least one computer program being loaded and executed by the processor as a method for running a target virtual event according to any one of claims 1 to 10, or being loaded and executed by the processor as a method for configuring a virtual team according to any one of claims 11 to 15.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store at least one computer program, the at least one computer program being used to run the method for running the target virtual event as described in any one of claims 1 to 10, or to run the method for configuring the virtual team as described in any one of claims 11 to 15.

20. A computer program product, comprising a computer program, characterized in that, The computer program, when executed by a processor, implements the method for running the target virtual event as described in any one of claims 1 to 10, or the method for configuring the virtual team as described in any one of claims 11 to 15.

Images