Virtual character control method and device, storage medium, equipment and program product

Abstract

The application discloses a virtual character control method and device in a game, a storage medium, equipment and a program product. A first graphical user interface is provided through a first terminal device. The first graphical user interface displays a first scene area of a virtual scene. The first scene area includes a first virtual character controlled and operated by the first terminal device. A second virtual character in the same camp as the first virtual character is controlled and operated by a second terminal device. The method includes: in response to receiving a proxy request for character control rights sent by the second terminal device, a proxy window is popped up on the first graphical user interface; and in response to a trigger operation on an agree control, control authority over the second virtual character is obtained. Thus, the application realizes the handover of virtual character control rights between players in the same camp, solves the problem that a player's own character cannot be normally operated when the player encounters an unexpected situation, guarantees the continuity of a game battle, and improves the fault tolerance and interest of team games.

Description

Technical Field

[0001] This application relates to the field of game technology, specifically to a method for controlling virtual characters in a game, a device for controlling virtual characters in a game, a computer-readable storage medium, an electronic device, and a computer program product. Background Technology

[0002] During gameplay, players may need assistance from other players due to various unexpected situations. However, other players usually provide assistance through text chat or voice, which is inefficient and affects the player's gaming experience to some extent. Summary of the Invention

[0003] This application provides a method for controlling virtual characters in a game, a device for controlling virtual characters in a game, a computer-readable storage medium, an electronic device, and a computer program product. By utilizing the interaction between two terminal devices of the same faction in the game, the control of virtual characters between players of the same faction can be entrusted, which improves the players' ability to deal with unexpected situations in the game and enhances the operational flexibility of team games.

[0004] On one hand, embodiments of this application provide a method for controlling virtual characters in a game. A first graphical user interface is provided through a first terminal device. The first graphical user interface displays a first scene area of ​​a virtual scene. The first scene area includes a first virtual character controlled and operated by the first terminal device, and a second virtual character belonging to the same faction as the first virtual character is controlled and operated by a second terminal device. The method includes: In response to receiving a role control delegation request sent by the second terminal device, a delegation window pops up on the first graphical user interface; the delegation window includes an agreement control; The system responds to a triggering action on the consent control to gain control over the second virtual character.

[0005] On the other hand, embodiments of this application provide a virtual character control device in a game, which provides a first graphical user interface through a first terminal device. The first graphical user interface displays a first scene area of ​​a virtual scene, and the first scene area includes a first virtual character controlled and operated by the first terminal device. A second virtual character belonging to the same faction as the first virtual character is controlled and operated by a second terminal device. The device includes: A pop-up window module is used to pop up a management window on the first graphical user interface in response to receiving a management request for role control sent by the second terminal device; the management window includes an agreement control; An operation response module is used to respond to a trigger operation on the consent control in order to obtain control permissions for the second virtual character.

[0006] On the other hand, embodiments of this application provide a method for controlling virtual characters in a game, which provides a second graphical user interface through a second terminal device. The second graphical user interface displays a second scene area of ​​a virtual scene, and the second scene area includes a second virtual character controlled and operated by the second terminal device. A first virtual character, which is in the same faction as the second virtual character, is controlled and operated by the first terminal device. The method includes: A request for the management of the second virtual character's role control is sent to the first terminal device, so that the first terminal device responds to the received management request by popping up a management window including an agreement control on the first graphical user interface provided by the first terminal device, and by responding to a trigger operation for the agreement control, so as to obtain control permissions for the second virtual character.

[0007] On the other hand, embodiments of this application provide a virtual character control device in a game, which provides a second graphical user interface through a second terminal device. The second graphical user interface displays a second scene area of ​​a virtual scene, and the second scene area includes a second virtual character controlled and operated by the second terminal device. A first virtual character in the same faction as the second virtual character is controlled and operated by the first terminal device. The device includes: The request sending module is used to send a management request for the role control of the second virtual character to the first terminal device, so that the first terminal device responds to the received management request by popping up a management window including an agreement control on a first graphical user interface provided by the first terminal device, and by responding to a trigger operation for the agreement control to obtain control rights over the second virtual character.

[0008] On the other hand, embodiments of this application provide a computer-readable storage medium storing a computer program adapted for loading by a processor to execute the virtual character control method in a game as described in any of the above embodiments.

[0009] On the other hand, embodiments of this application provide an electronic device, which includes a processor and a memory. The memory stores a computer program, and the processor executes the virtual character control method in the game as described in any of the above embodiments by calling the computer program stored in the memory.

[0010] On the other hand, embodiments of this application provide a computer program product, including computer instructions, which, when executed by a processor, implement the virtual character control method in a game as described in any of the above embodiments.

[0011] The virtual character control method, virtual character control device, computer-readable storage medium, electronic device, and computer program product provided in this application embodiment, in which a first terminal device provides a first graphical user interface including a first virtual character, the first graphical user interface displays a first scene area of ​​a virtual scene, and in response to receiving a character control delegation request sent by a second terminal device of the same faction, a delegation window including an agreement control pops up on the first graphical user interface, and then responds to the trigger operation of the agreement control to obtain control rights over the second virtual character, thereby realizing the transfer of virtual character control rights between players of the same faction. Compared with the solution of artificial intelligence taking over or physical requisition of equipment, by directly transferring character control rights between different terminal devices, the problem of players' characters being unable to operate normally when encountering emergencies is solved, ensuring the continuity of game battles, and to a certain extent improving the fault tolerance and fun of team games.

[0012] Furthermore, the requirement that the first and second virtual characters belong to the same faction effectively ensures the security and cooperation of the transfer of control, avoiding the risk of control shifting to the opposing side to a certain extent, ensuring the stability of team battles. The designated management window provides a clear request processing entry point for the player on the first terminal device, and the consent control grants the player on the first terminal device the right to decide whether to take over, avoiding operational interference caused by passive takeover to a certain extent, ensuring the continuity of the player's own game operations, and thus achieving an orderly transfer of control to a certain extent. This effectively solves the problem of players being unable to control their characters normally due to unexpected events, network lag, etc., ensuring the continuity of game battles, improving the fault tolerance rate of team games, and enhancing the player's gaming experience and team collaboration. Attached Figure Description

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

[0014] Figure 1 This is a schematic diagram of an example game system provided in an embodiment of this application.

[0015] Figure 2 This is a flowchart illustrating a virtual character control method in a game, as provided in an embodiment of this application.

[0016] Figure 3 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application embodiment.

[0017] Figure 4 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application embodiment.

[0018] Figure 5 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application embodiment.

[0019] Figure 6 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application embodiment.

[0020] Figure 7 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application embodiment.

[0021] Figure 8 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application embodiment.

[0022] Figure 9 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application embodiment.

[0023] Figure 10 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application embodiment.

[0024] Figure 11 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application embodiment.

[0025] Figure 12 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application embodiment.

[0026] Figure 13 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application embodiment.

[0027] Figure 14 This is a flowchart illustrating a virtual character control method in a game, as provided in an embodiment of this application.

[0028] Figure 15 A schematic diagram of the structure of a virtual character control device in a game provided in an embodiment of this application.

[0029] Figure 16 A schematic diagram of the structure of a virtual character control device in a game provided in an embodiment of this application.

[0030] Figure 17 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0032] This application provides a method for controlling virtual characters in a game, a device for controlling virtual characters in a game, a computer-readable storage medium, an electronic device, and a computer program product. Specifically, the method for controlling virtual characters in a game according to this application can be executed by an electronic device, which can be a terminal or a server. The terminal can be a smartphone, tablet, laptop, smart TV, wearable smart device, smart vehicle terminal, etc. The terminal can also include a client, which can be a game client, browser client, instant messaging client, or mini-program, etc. The server can be an independent physical server, a server cluster composed of multiple physical servers, or a distributed system. It can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0033] For example, when the virtual character control method in the game runs on a terminal device, the terminal device may include a display screen and a processor. The display screen is used to present the game screen and receive commands generated by the player interacting with the game screen. The game screen may include a portion of a virtual game scene, which is a virtual world in which the virtual character performs actions. The processor is used to store the game application, run the game, generate game screens, respond to commands, and control the display of the game screen on the display screen. When the player operates the game screen through the display screen, the game screen can control the local content of the terminal device in response to the received operation commands. The terminal device can provide the graphical user interface to the player in various ways, such as rendering the display on the terminal device's screen or presenting the graphical user interface through holographic projection.

[0034] For example, when the virtual character control method in the game runs on a server, this method can be implemented and executed based on a cloud gaming system. A cloud gaming system refers to a gaming method based on cloud computing. A cloud gaming system includes servers and client devices. The main body running the game application and the main body presenting the game screen are separate. The storage and execution of the virtual character control method in the game are completed on the server. The game screen presentation is completed on the client, which is mainly used for receiving and sending game data and presenting the game screen. For example, the client can be a display device with data transmission capabilities close to the player, such as a mobile terminal, television, computer, PDA, personal digital assistant, head-mounted display device, etc. However, the terminal device for processing game data is the server in the cloud. When playing the game, the player operates the client to send commands to the server. The server controls the game to run according to the commands, encodes and compresses the game screen data, returns it to the client through the network, and finally, the client decodes and outputs the game screen.

[0035] It should be noted that, in this embodiment, the executing entity of the virtual character control method in the game can be a terminal device or a server. The terminal device can be a local terminal device or a client device in the aforementioned cloud gaming. This embodiment does not limit the type of executing entity.

[0036] It is understood that in the specific implementation of this application, user object data, context data and other related data are involved. When the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0037] For example, in conjunction with the above description, Figure 1 This application illustrates a game system 1000 for implementing a virtual character control method in a game, as provided in an embodiment of this application. The game system 1000 may include at least one terminal 1001, at least one server 1002, at least one database 1003, and a network. The user-held terminal 1001 can connect to different servers via the network. The terminal is any device with computing hardware capable of supporting and executing software applications corresponding to the game.

[0038] In the aforementioned game system 1000, terminal 1001 is used to install and run the game application. In some cases, the game application may not need to be pre-installed on terminal 1001, and players can directly access the game through a browser or other client. Players log in to the game application using their registered game account to control the virtual character corresponding to that account and participate in the game. When a player logs in to the game application, terminal 1001 sends a login request to server 1002. Server 1002 verifies the game account used by the player and determines the game mechanics corresponding to the game account based on the login request. If the verification is successful, a login success notification is returned to terminal 1001. During the player's participation in the game through the game application, terminal 1001 and server 1002 exchange data. Terminal 1001 sends various information to server 1002. Server 1002 determines the display data for terminal 1001 based on the stored game mechanics and the received information, and sends the display data back to terminal 1001 so that terminal 1001 can display the display data sent by server 1002 to the player.

[0039] In possible application scenarios, different terminals 1001 may be served by different servers 1002. Therefore, in order to distinguish the servers 1002 corresponding to different game terminals 1001, the embodiments of this application will use the terms "first" and "second" to describe them. In fact, the servers 1002 corresponding to different game terminals 1001 can be the same server 1002. Therefore, without distinguishing between "first" and "second", it can be understood that the terminals 1001 corresponding to virtual characters in the same game scene are served by the same server 1002.

[0040] Furthermore, when the game system 1000 includes multiple terminals, multiple servers, and multiple networks, different terminals can connect to each other through different networks and servers. The network can be a wireless network or a wired network; for example, wireless networks include Wi-Fi, LAN, cellular networks, 2G, 3G, 4G, and 5G networks. Additionally, different terminals can also connect to other terminals or servers using their own Bluetooth networks or hotspot networks. Moreover, the system 100 can include multiple databases coupled to different servers, and can continuously store game-related information in the databases while different users are playing multiplayer games online.

[0041] It should be noted that in this embodiment, multiple terminal devices are running the same virtual game. Therefore, data interaction between the multiple terminal devices can be achieved through the virtual game's server. Thus, sending data from terminal device 1 to terminal device 2 can be understood as: terminal device 1 sends data to the virtual game's server, and the server sends the data to terminal device 2. Receiving data from terminal device 2 can be understood as: terminal device 1 receives data sent by the virtual game's server, which is the data sent by terminal device 2 to the server. Alternatively, there may be no game server, and terminal device 1 directly sends game data to terminal device 2.

[0042] It should be noted that, Figure 1 The game system diagram shown is merely an example. The game system 1000 described in this application embodiment is intended to more clearly illustrate the technical solutions of this application embodiment and does not constitute a limitation on the technical solutions provided in this application embodiment. As those skilled in the art will know, with the evolution of game systems and the emergence of new business scenarios, the technical solutions provided in this application embodiment are also applicable to similar technical problems.

[0043] It should be noted that the triggering operations mentioned in the subsequent detailed description of the virtual character control method in the game provided in the embodiments of this application can all be regarded as triggering operations performed by the player through a finger or by controlling a medium such as a mouse, keyboard, or stylus. The specific medium used can be determined according to the type of electronic device. For example, when the electronic device is a touch screen device such as a mobile phone, tablet, or game console, the player can operate on the touch screen using any suitable object or accessory such as a finger or stylus. When the terminal device is a non-touch screen terminal device such as a desktop computer or laptop, the player can operate using an external device such as a mouse or keyboard.

[0044] The technical solution of this application will be described in detail below through specific embodiments. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0045] In this embodiment of the application, a graphical user interface is provided through a terminal device. The graphical user interface includes at least a portion of the virtual scene and at least one virtual character.

[0046] The aforementioned virtual scene can be a game scene, which can be understood as a simulation of the real world within a game, a semi-simulated / semi-fictional virtual environment, or a purely fictional virtual environment. A game scene can be any of the following: two-dimensional, 2.5-dimensional, or three-dimensional virtual scenes. A virtual scene typically includes multiple scene elements, which are the various elements required to constitute the virtual scene. For example, these may include, but are not limited to, at least one of the following: virtual character elements, virtual item elements, virtual building elements, virtual terrain elements, and virtual vegetation elements. Virtual terrain elements may include, but are not limited to, natural landforms such as land, ocean, lakes, and rivers. A virtual scene is a scenario where players control virtual characters to complete game logic.

[0047] As can be understood, a virtual character is a game character controlled by the player in a game. The player manipulates this virtual character to perform various game activities within the game environment, such as picking up items, engaging in combat, exploring, or solving puzzles. This virtual character can represent the player's image, and each virtual character can be implemented using a 3D or 2D virtual model; this embodiment does not specifically limit this. Virtual characters include, but are not limited to, at least one of the following: virtual human, virtual animal, and virtual machine.

[0048] In team battles of multiplayer online competitive games, players need to cooperate closely as a team to complete tactical objectives. However, in actual gameplay, players often encounter situations where they are unable to control their virtual characters properly due to uncontrollable factors such as network fluctuations, unexpected events, and differences in operational abilities, which in turn affects the overall competitive performance of the team.

[0049] To address the aforementioned issues, some technical solutions utilize artificial intelligence (AI) programs to take over virtual characters when players are unable to operate them due to unexpected events such as network interruptions or device malfunctions. The AI ​​program performs basic operations such as movement and basic attacks on the virtual character, preventing the character from being attacked by the enemy or affecting the team's tactical execution while in a completely stationary state.

[0050] In addition, when high-level players are unable to continue playing their roles due to being knocked down and waiting for rescue, and the novice players on the same team lack operational skills, some technical solutions allow high-level players to directly requisition the novice players' game devices and manually operate the novice players' virtual characters to achieve tactical cooperation or make up for the novice players' operational shortcomings.

[0051] However, the AI ​​temporary takeover solution has limited intelligence. The AI ​​program's operation logic is based on a preset algorithm, lacking flexible judgment and tactical understanding of the real-time battle situation. Its gameplay is sluggish and mechanical, only able to complete simple basic operations, unable to cope with complex team battles, skill combos and other scenarios, and unable to solve the team disadvantage caused by the lack of player operation.

[0052] Furthermore, the physical equipment requisition scheme relies on the transfer of equipment within the physical space, which cannot meet the collaborative needs of remote team players. Moreover, for most player groups with varying skill levels, high-level players can only guide novice players through verbal communication, which cannot directly take over the operation level, resulting in low guidance efficiency. Novice players find it difficult to quickly master the operation skills and form effective tactical cooperation.

[0053] In addition, team-based competitive games usually follow the basic setting of one person controlling one virtual character, which limits the scope of gameplay expansion and makes it impossible to realize innovative gameplay such as one person controlling multiple virtual characters or two people cooperating to control the same virtual character. This reduces the strategic and fun aspects of the game, weakens the social interaction in team games, and makes it difficult to further enhance player team stickiness and game experience.

[0054] Please refer to the following for the above questions. Figure 2 , Figure 3 , Figure 4 and Figure 5 , Figure 2 This is a flowchart illustrating a virtual character control method in a game, as provided in an embodiment of this application. Figures 3 to 5 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application embodiment. It should be noted that the steps shown can be executed in a logical order different from that shown in the flowchart. The method provides a first graphical user interface through a first terminal device. The first graphical user interface displays a first scene area of ​​a virtual scene. The first scene area includes a first virtual character controlled and operated by the first terminal device, and a second virtual character belonging to the same faction as the first virtual character is controlled and operated by a second terminal device. The method includes: Step 200: In response to receiving a role control delegation request sent by the second terminal device, a delegation window pops up on the first graphical user interface; the delegation window includes an agreement control; Step 210: Respond to the trigger action of the consent control to obtain control permissions for the second virtual character.

[0055] Specifically, in team-based competitive games, when players are unable to control their virtual characters due to unexpected situations such as network lag, the temporary AI takeover method is sluggish and lacks intelligence, failing to flexibly handle complex game scenarios. Furthermore, when players need assistance from teammates, teammates can only guide them through verbal communication, unable to directly take over control at the operational level, resulting in low guidance efficiency and failing to meet the collaborative control needs of players. Based on these problems, this application provides a virtual character control method in games. A first terminal device and a second terminal device, controlling different virtual characters within the same faction, cooperate to manage virtual character control. The second terminal device sends a management request to the first terminal device. Upon receiving the request, the first terminal device displays a management window including an agreement control on its first graphical user interface. When the player on the first terminal device performs a valid trigger operation on the agreement control, the first terminal device gains control of the second virtual character, thereby achieving management of virtual character control among players within the same faction.

[0056] In some embodiments, the first terminal device can be understood as an electronic device capable of running game programs and controlling virtual characters, such as smartphones, tablets, game consoles, and other terminals that can carry and run games.

[0057] In some embodiments, the second terminal device can be understood as another game terminal that is in the same game faction as the first terminal device, and the device type of the second terminal device is the same as that of the first terminal device.

[0058] In some embodiments, the first graphical user interface can be understood as a visual operation interface displayed when the first terminal device runs a game, including the game's virtual scene, operation controls, and other content.

[0059] In some embodiments, a virtual scene can be understood as a virtual game environment constructed within a game through technical means, including game maps, scene elements, interactive nodes, and other content, which is the space where virtual characters move around.

[0060] In some embodiments, the first scene area can be understood as a specific part of the virtual scene displayed in the first graphical user interface, which is the range of the game environment that the player of the first terminal device can intuitively see.

[0061] In some embodiments, the first virtual character can be understood as a digital character in a game controlled by a first terminal device, and is the operating vehicle for the player of the first terminal device in the game.

[0062] In some embodiments, "fellow factions" can be understood as players and virtual characters who are on the same team in a game. Players and virtual characters on the same faction cooperate and work together to fight against other teams in the game.

[0063] In some embodiments, the second virtual character can be understood as a digital character in a game controlled by a second terminal device, belonging to the same faction as the first virtual character.

[0064] In some embodiments, character control can be understood as the right to operate and control a virtual character, including various operational permissions that can be performed on the virtual character, such as moving, attacking, releasing skills, and using items.

[0065] In some embodiments, a custodian request can be understood as an information request sent by a second terminal device to a first terminal device, requesting the first terminal device to temporarily control the second virtual character.

[0066] In some embodiments, the escrow window can be understood as a visual interactive window that pops up in the first graphical user interface for processing escrow requests.

[0067] In some embodiments, the consent control can be understood as an interactive element such as an interactive button set in the custodian window to confirm acceptance of the custodian request.

[0068] In some embodiments, the triggering operation can be understood as a valid operation performed by the player on controls in the first graphical user interface, such as clicking or touching.

[0069] In some embodiments, control permissions can be understood as the right to perform various operations on the second virtual character.

[0070] To more clearly illustrate the virtual character control method in the game provided in the embodiments of this application, please also refer to... Figure 3 , Figure 4 , Figure 5 And the following exemplary description, namely: During a game, the first terminal device runs the game program and provides a first graphical user interface 300. The first graphical user interface 300 displays the first scene area of ​​the game's virtual scene. The first virtual character 330, as the object of operation of the first terminal device, is located in the first scene area. Players of the first terminal device can perform various in-game control operations on the first virtual character 330 through the first terminal device.

[0071] A second virtual character 430, which is in the same game faction as the first virtual character 330, is controlled by a second terminal device. The second terminal device runs the game program and provides a second graphical user interface 400, which displays a second scene area of ​​the game's virtual scene. The second virtual character 430, as the object of operation of the second terminal device, is located in the second scene area. Players on the second terminal device can perform various in-game control operations on the second virtual character 430 through the second terminal device.

[0072] The first and second terminal devices are in the same team network in the game, enabling real-time interaction of game information.

[0073] When a player on the second terminal device encounters network lag, device failure, or other issues that prevent them from operating the second virtual character 430 normally, the second terminal device can send a request for the second virtual character 430 to the first terminal device through interactive elements such as in-game function buttons. The request is transmitted in the same faction's team network in the form of game data information.

[0074] The first terminal device receives various information from the team network in real time. When it receives a management request from the second terminal device, a management window 350 pops up at a designated location in the first graphical user interface 300. The management window 350 contains an agreement control 352, which is an interactive element such as a button for the player on the first terminal device to perform interactive operations.

[0075] Players on the first terminal device can view the managed window 350 and, based on their own game operation and game needs, click or touch the consent control 352 in the managed window 350 to trigger operations.

[0076] The first terminal device detects the control operations in the first graphical user interface 300 in real time. After detecting that the consent control 352 is effectively triggered, it obtains control permissions for the second virtual character 430. The first terminal device can perform various game control operations on the second virtual character 430, thereby realizing the management of the character control rights of the second virtual character 430.

[0077] Furthermore, the sending of the custody request and the triggering of the consent control are both completed through the in-game visual interface, namely the graphical user interface 300 or 400. Players do not need to perform complex operation settings, which improves the player's operation experience to a certain extent, ensures the rapid transfer of character control, reduces the problem of game operation interruption caused by permission transfer, and ensures the continuity of game battles.

[0078] Thus, in this embodiment, the first terminal device provides a first graphical user interface (GUI) including a first virtual character. The GUI displays a first scene area of ​​a virtual scene. In response to a character control delegation request sent by a second terminal device of the same faction, a delegation window including an agreement control pops up on the first GUI. Then, in response to a trigger operation on the agreement control, control over the second virtual character is obtained, thereby realizing the transfer of virtual character control between players of the same faction. Compared to solutions involving AI takeover or physical requisition of devices, directly transferring character control between different terminal devices solves the problem of players being unable to operate their characters normally in unexpected situations, ensuring the continuity of game battles and, to a certain extent, improving the fault tolerance and fun of team games.

[0079] Furthermore, the requirement that the first and second virtual characters belong to the same faction effectively ensures the security and cooperation of the transfer of control, avoiding the risk of control shifting to the opposing side to a certain extent, ensuring the stability of team battles. The designated management window provides a clear request processing entry point for the player on the first terminal device, and the consent control grants the player on the first terminal device the right to decide whether to take over, avoiding operational interference caused by passive takeover to a certain extent, ensuring the continuity of the player's own game operations, and thus achieving an orderly transfer of control to a certain extent. This effectively solves the problem of players being unable to control their characters normally due to unexpected events, network lag, etc., ensuring the continuity of game battles, improving the fault tolerance rate of team games, and enhancing the player's gaming experience and team collaboration.

[0080] In some embodiments provided in this application, the managed window further includes permission prompt information, which is used to identify the control permissions of the second virtual character that the first terminal device can obtain and / or the control permissions of the second virtual character that the first terminal device cannot obtain.

[0081] Specifically, when implementing delegated control of virtual characters, the player on the first terminal device cannot determine the scope of control permissions for the second virtual character they can obtain during the request processing phase. This leads to permission conflicts during the delegated control operation, reducing the efficiency of cooperation between players and affecting the game's control experience. Based on the above problems, in some embodiments provided in this application, permission prompt information is added to the pop-up delegated control window. This permission prompt information identifies the control permissions the first terminal device can and cannot obtain for the second virtual character. This allows the player on the first terminal device to understand the scope of permissions through the permission prompt information when processing the delegated control request, and then decide whether to accept the request based on their own needs, effectively avoiding misoperations or cooperation conflicts caused by information asymmetry.

[0082] In some embodiments, permission prompts can be understood as visual information displayed in the managed window, usually in the form of text, graphics, etc., used to identify the scope of control permissions and help players identify operable and non-operable permissions.

[0083] To more clearly illustrate the virtual character control method in the game provided in this application embodiment, please refer to the following exemplary description: During a game, the second terminal device sends a request to the first terminal device to take over the control of the second virtual character. After receiving the request, the first terminal device displays a takeover window with an agreement control in the first graphical user interface.

[0084] In addition to the consent control, the proxy window may also include permission prompts. The permission prompts indicate the control permissions that the first terminal device can obtain and the control permissions that it cannot obtain for the second virtual character. This allows the player on the first terminal device to understand the scope of the proxy permissions when viewing the proxy window, and to decide whether to accept the proxy request within the scope of permissions based on their own game operation skills and game needs.

[0085] In some embodiments, the permission prompt information may specify only the control permissions that the first terminal device can obtain for the second virtual character. For example, basic operation permissions such as movement and attack.

[0086] In some embodiments, the permission prompt information may also separately indicate the control permissions of the second virtual character that the first terminal device cannot obtain, such as advanced operation permissions such as item use and character upgrade.

[0087] If the player on the first terminal device agrees to the trusteeship request, the consent control will be triggered, and the first terminal device will then obtain the control permissions of the second virtual character that the first terminal device can obtain, as indicated in the permission prompt information.

[0088] Thus, in this embodiment, in response to receiving a character control delegation request from a second terminal device in the same faction, a delegation window including an agreement control and permission prompts pops up on the first graphical user interface. In response to the triggering of the agreement control, the first terminal device acquires the control permissions of the second virtual character that it is authorized to obtain, as indicated in the permission prompts. Compared to a delegation window with only an agreement control, the addition of permission prompts allows the first terminal device player to know the controllable permission boundaries and restricted permission range before deciding whether to agree to delegation. This avoids, to some extent, misoperations or collaborative conflicts caused by information asymmetry, protects the first terminal device player's right to make independent decisions, and enables the first terminal device player to judge whether to accept delegation based on their own operational capabilities and the game scenario. Simultaneously, it directly conveys the permission allocation intention of the second terminal device player without additional language communication costs, effectively improving the transparency and predictability of permission delegation. This, in turn, improves the collaborative efficiency between players in the same faction, reduces operational conflicts caused by permission misunderstandings, ensures the continuity and smoothness of game battles, and enhances the player's gaming experience and team collaboration stickiness.

[0089] Please refer to the embodiments provided in this application as well. Figure 3 , Figure 4 and Figure 6 , Figure 6 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application. The first graphical user interface further includes multiple first controls for controlling the virtual character. Each first control is bound to a control permission of the virtual character. The permission prompt information includes a first control identifier pattern and / or a second control identifier pattern. The first control identifier pattern is used to indicate the first control in the first graphical user interface that is bound to the control permission of the second virtual character that the first terminal device can obtain. The second control identifier pattern is used to indicate the first control in the first graphical user interface that is bound to the control permission of the second virtual character that the first terminal device cannot obtain.

[0090] Specifically, although the managed window adds permission prompts to identify the scope of control, these prompts are merely abstract text or categorization descriptions of permissions, not associated with the specific controls in the graphical user interface that actually manipulate the virtual character. This fails to visualize and concretize the scope of permissions, making it difficult for players to intuitively perceive the specific operable and non-operable entry points. Based on the above problems, in some embodiments provided in this application, multiple first controls for controlling the virtual character are set in the first graphical user interface, with each first control associated with a control permission of the virtual character. Simultaneously, the permission prompts are set to include first control identifiers and / or second control identifiers. The first and second control identifiers respectively indicate the operable and non-operable first controls in the first graphical user interface for the first terminal device. Players on the first terminal device can intuitively understand the permission status of each first control through the identifiers, transforming abstract permission information into concrete visual interface information.

[0091] In some embodiments, the first control can be understood as an interactive element set in the first graphical user interface for controlling the virtual character, and is the operation carrier for the player to control the virtual character. Each control corresponds to an independent virtual character control permission.

[0092] In some embodiments, the first control identifier pattern can be understood as a visual graphic identifier in the permission prompt information used to indicate the first control that the first terminal device can operate.

[0093] In some embodiments, the second control identifier pattern can be understood as a visual graphic identifier in the permission prompt information used to indicate that the first control is not operable by the first terminal device, and is different from the first control identifier pattern.

[0094] To more clearly illustrate the virtual character control method in the game provided in the embodiments of this application, please also refer to... Figure 3 , Figure 4 , Figure 6 And the following exemplary description, namely: During gameplay, after the first terminal device runs the game program, it provides the player with a first graphical user interface 300. The first graphical user interface 300 displays a first scene area of ​​the virtual scene in real time. The first virtual character 330, controlled by the first terminal device, is located within the first scene area. The first graphical user interface 300 is equipped with multiple first controls 341 to 349 for controlling the virtual character. Each first control, 341 to 349, is uniquely bound to a control permission of the first virtual character 330. The first terminal device can perform corresponding control actions on the first virtual character 330 by triggering different first controls, 341 to 349. For example, a skill control corresponds to skill release permission, and a basic attack control corresponds to character attack permission, etc.

[0095] After the second terminal device runs the game program, it provides the player with a second graphical user interface 400. The second graphical user interface 400 displays a second scene area of ​​the virtual scene in real time. The second virtual character 430, controlled by the second terminal device, is located within the second scene area. The second graphical user interface 400 is equipped with multiple first controls 441 to 449 for controlling the virtual character. Each first control, 441 to 449, is uniquely bound to a control permission of the second virtual character 430. The second terminal device can perform corresponding control actions on the second virtual character 430 by triggering different first controls, 441 to 449. For example, a skill control corresponds to skill release permission, and a basic attack control corresponds to character attack permission, etc.

[0096] When the player on the second terminal device is unable to control the second virtual character 430 independently due to unforeseen circumstances or insufficient operational ability, the second terminal device sends a request to the first terminal device to take over the control of the character.

[0097] After receiving the custodian request, the first terminal device pops up a custodian window 350 in the first graphical user interface 300. The custodian window 350 includes not only an agreement control 352 for confirming agreement to custodian, but also permission prompt information 354, and the permission prompt information 354 includes a first control identifier pattern and / or a second control identifier pattern.

[0098] In some embodiments, different visual features such as color and shape can be used to distinguish the first control identifier pattern and the second control identifier pattern. For example, the first control identifier pattern is a green square including a start button, and the second control identifier pattern is a red square including a disable button.

[0099] The first control identifier pattern points to a first control in the first graphical user interface 300 that is bound to the role control permissions of the second virtual character 430 that the first terminal device can obtain. Each operable first control corresponds to a matching first control identifier pattern. For example... Figure 6 The first controls in the text are 441, 442, 444 to 448, etc.

[0100] The second control identifier pattern points to the first control in the first graphical user interface 300 that is bound to the role control permissions of the second virtual character that the first terminal device cannot obtain. Each inoperable first control also corresponds to a matching second control identifier pattern. For example... Figure 6 The first controls in the text are 443, 449, etc.

[0101] In some embodiments, the identification pattern can be directly displayed in the permission prompt information area 354 of the managed window 350, corresponding to the corresponding control name. Alternatively, a pattern mapping method can be used, where the identification pattern is displayed in the managed window 350, and the corresponding first controls 341 to 349 in the first graphical user interface 300 will also display the identification pattern simultaneously.

[0102] Players on the first terminal device can intuitively and quickly identify, through the icons in the managed window 350, the first controls 441, 442, 444 to 448 that can be used to control the second virtual character 430, or the first controls 443, 449 that cannot be used to control the second virtual character 430, or simultaneously identify the first controls 441, 442, 444 to 448 that can be used to control the second virtual character 430 and the first controls 443, 449 that cannot be used to control the second virtual character 430.

[0103] When the player on the first terminal device performs a valid triggering operation such as clicking or touching the consent control 352 in the managed window 350, the first terminal device obtains the corresponding second virtual character 430's character control permissions. The first terminal device can only control the second virtual character 430 through the first controls 441, 442, 444 to 448 indicated by the first control icon.

[0104] Thus, in this embodiment, a first graphical user interface including a first virtual character is provided by a first terminal device. The first graphical user interface displays a first scene area of ​​a virtual scene and is provided with a plurality of first controls that are respectively bound to a control permission of the virtual character. In response to receiving a role control right management request sent by a second terminal device of the same faction, a management window including an agreement control and permission prompt information pops up on the first graphical user interface. The permission prompt information includes a first control identifier pattern and / or a second control identifier pattern, which are respectively used to indicate the first controls that the first terminal device can and cannot obtain the role control permissions of the second virtual character bound to. In response to the triggering operation of the agreement control, the first terminal device obtains control permissions for the second virtual character. In this way, by binding abstract permission scopes with specific control panels and visually corresponding permissions to controls through iconographic symbols, the problem of insufficient visualization of permission prompts is effectively solved. Furthermore, the clear indication of the first and second control icon patterns allows players on the first terminal device to intuitively identify operable and non-operable controls before triggering the consent control, effectively avoiding misoperations caused by ambiguous permission understanding. This enhances the clarity of permission transmission to a certain extent, reduces communication costs between players, and consequently improves the cooperation efficiency among players in the same faction, ensuring the smoothness of game battles, enriching the collaborative experience of team games, and increasing player engagement and acceptance of the game's collaborative mechanism.

[0105] In some embodiments provided in this application, responding to a trigger operation on a consent control to obtain control permissions over a second virtual character includes: responding to a trigger operation on a consent control to obtain target control permissions over the second virtual character; the target control permissions are at least a portion of all control permissions of the second virtual character.

[0106] Specifically, in actual game scenarios, players' delegation needs are diverse. In some scenarios, only basic control permissions need to be taken over by an ally, while the player retains core control permissions. However, a single "takeover" mode cannot adapt to diverse delegation needs, resulting in rigid permission allocation. Furthermore, it deprives players on the second terminal device of autonomy over the core operations of their virtual character, reducing the gaming experience. Based on the above problems, in some embodiments provided in this application, the scope of the character control permissions of the second virtual character obtained after triggering the consent control is defined. The obtained character control permissions of the second virtual character are set as target control permissions, and the target control permissions are at least a portion of the total control permissions of the second virtual character. Players on the second terminal device can flexibly allocate some or all control permissions according to the actual needs of the game, achieving flexible allocation of control permissions.

[0107] In some embodiments, the target control authority can be understood as the control authority of the second virtual character actually obtained by the first terminal device in this trusteeship operation. It is part or all of the total control authority of the second virtual character and can be flexibly allocated according to the actual needs of the game.

[0108] To more clearly illustrate the virtual character control method in the game provided in this application embodiment, please refer to the following exemplary description: During a game, the second terminal device sends a request to the first terminal device to take over the control of the second virtual character. The request includes a preset target control permission range, which is at least a part of the second virtual character's total control permissions. This range can be set in advance by the second terminal device according to its own needs. For example, it can set movement and attack permissions as the target control permissions, or it can set all control permissions as the target control permissions.

[0109] After receiving the management request, the first terminal device will pop up a management window with an agreement control in the first graphical user interface. The management window can simultaneously display the scope information of the target control permissions.

[0110] If a player on the first terminal device views the request and chooses to accept the management request and triggers the consent control, the first terminal device can only obtain the role control permissions of the second virtual character within the scope of the target control permissions, i.e., the target control permissions.

[0111] If the target control permission is partial, the second terminal device retains the remaining control permission and can continue to perform corresponding operations on the second virtual character. If the target control permission is full, the first terminal device obtains all control permissions for the second virtual character, and the second terminal device has no remaining control permissions and cannot perform control operations on the second virtual character.

[0112] In some embodiments, the scope of target control permissions can be adjusted by the second terminal device at any time before sending the management request to ensure adaptation to the dynamic changes in the game.

[0113] Understandably, the partial permission allocation method makes it possible for two people to cooperate in operating the same character, realizing the operation cooperation between players, enriching the operation form and gameplay, and breaking the limitation of one person controlling one character.

[0114] Thus, in this embodiment, in response to the triggering operation of the consent control, the first terminal device obtains target control permissions over the second virtual character, and the target control permissions are at least a part of the total control permissions of the second virtual character. This realizes the flexible allocation of character control rights, breaking the single form of overall transfer of control rights. It allows the player on the second terminal device to choose to allocate part or all of the control permissions according to the actual needs of the game, which improves the flexibility of character control management to a certain extent, adapts to the needs of diverse game scenarios, and the setting of target control permissions allows the player on the second terminal device to retain some control over the character when assistance is needed, maintain the initiative in the game, and avoid completely losing control of the character due to the transfer of all permissions. This improves the player's game experience and sense of participation to a certain extent, thereby enhancing the fun and collaborative stickiness of team games and optimizing the collaborative experience of multiplayer online games.

[0115] In some embodiments provided in this application, responding to a trigger operation for a consent control to obtain target control permissions for a second virtual character includes: responding to a trigger operation for a consent control to send a management confirmation request to a second terminal device to consent to the management of the virtual character, so that after receiving the management confirmation request, the second terminal device, in response to a permission configuration operation, determines the target control permissions that the first terminal device can obtain and sends a permission allocation request to the first terminal device; and responding to the permission allocation request to obtain control permissions for the second virtual character.

[0116] Specifically, the target control permissions are pre-set by the second terminal device before sending the management request. This can lead to inconsistencies in the permission scope due to real-time changes in the game, affecting the accuracy of the management operation. To address this issue, in some embodiments provided in this application, after the first terminal device triggers the consent control, an interactive process involving a management confirmation request, permission configuration, and permission allocation request is added. The determination of the target control permissions is placed after the first terminal device confirms acceptance of the management. The second terminal device then configures the permissions according to real-time game requirements and sends the configured target control permissions to the first terminal device via a permission allocation request. Upon receiving the request, the first terminal device obtains the corresponding control permissions, thus achieving dynamic permission configuration.

[0117] In some embodiments, the custody confirmation request can be understood as a confirmation request sent by the first terminal device to the second terminal device to accept custody information after the first terminal device triggers the consent control.

[0118] In some embodiments, the permission configuration operation can be understood as the operation of selecting and determining the target control permissions after the second terminal device receives the custody confirmation request, which is executed by the player of the second terminal device.

[0119] In some embodiments, a permission allocation request can be understood as a request, including target control permission information, sent by the second terminal device to the first terminal device after the second terminal device has completed permission configuration.

[0120] To more clearly illustrate the virtual character control method in the game provided in this application embodiment, please refer to the following exemplary description: During a game, the second terminal device sends a request to the first terminal device to take over the control of the second virtual character. The request is only a basic assistance request and does not pre-set a specific target control permission range.

[0121] After receiving the trusteeship request, the first terminal device will pop up a trusteeship window with an agreement control in the first graphical user interface. If the player on the first terminal device chooses to accept the trusteeship and triggers the agreement control, the first terminal device will send a trusteeship confirmation request to the second terminal device to agree to the trusteeship of the character control.

[0122] After the second terminal device receives the custody confirmation request, the second graphical user interface will pop up a permission configuration interface. The permission configuration interface displays all control permissions of the second virtual character and the corresponding operation options. The player of the second terminal device can perform permission configuration operations according to the needs of the current game, and independently select and determine the target control permissions that the first terminal device can obtain. The target control permissions are at least a part of all control permissions of the second virtual character.

[0123] In some embodiments, during the permission configuration process, the second terminal device player can adjust the permission selection at any time until the final target control permission range is determined.

[0124] After completing the permission configuration, the second terminal device sends a permission allocation request to the first terminal device, which includes the target control permission information. The permission allocation request clearly indicates the type and scope of the permissions to be allocated.

[0125] After receiving the permission allocation request, the first terminal device can obtain control permissions for the second virtual character and perform corresponding control operations.

[0126] In some embodiments, if the second terminal device finds that no management is required or that the object to be assisted needs to be adjusted during the permission configuration process, it can terminate the permission configuration operation and not send a permission allocation request, and the current management process will then terminate.

[0127] Thus, in this embodiment, the first terminal device responds to the trigger operation of the consent control and sends a custody confirmation request to the second terminal device. After the second terminal device responds to the permission configuration operation to determine the target control permission and sends a permission allocation request, the first terminal device responds to the permission allocation request to obtain control permission over the second virtual character. This realizes the autonomous allocation of virtual character control rights among players of the same faction, effectively ensuring the second terminal device player's dominant control over their own virtual character. This makes the allocation of target control permissions conform to the actual game needs of the second terminal device player. Furthermore, the bidirectional interaction process of custody confirmation request and permission allocation request between the first and second terminal devices constructs a standardized permission transfer mechanism, avoiding problems such as permission information transmission errors or untimely allocation. To a certain extent, this ensures the accuracy and stability of control transfer, thereby improving the targeting and reliability of virtual character control transfer, ensuring the continuity of game battles, improving the cooperation efficiency and strategic flexibility of team games, and enhancing the player's game experience and team stickiness.

[0128] In some embodiments provided in this application, please refer to Figure 7 , Figure 7 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application. The first graphical user interface further includes multiple first controls for controlling the virtual character, each first control being bound to a control permission of the virtual character. The method further includes: responding to a trigger operation on a control, controlling a first target control to display in a first display format to indicate that a second virtual character can be controlled through the first target control; the first target control is the control among the multiple first controls that is bound to the control permission obtained by the second virtual character.

[0129] Specifically, after the first terminal device gains control of the second virtual character, the controls in the first graphical user interface are not specially marked. Players on the first terminal device need to try each control individually to determine the operable first target control, increasing the cost of trial and error and increasing the likelihood of misoperation, affecting operational efficiency after takeover and reducing the gaming experience. Based on the above problems, in some embodiments provided in this application, multiple first controls bound to the virtual character's control permissions are set in the first graphical user interface. When a player on the first terminal device triggers the consent control, the first terminal device automatically identifies the first target control bound to the acquired control permissions of the second virtual character and controls the first target control to be displayed in a first display format. This specific display format identifies the operable controls, providing clear operation prompts for the player and allowing them to quickly identify operable controls.

[0130] In some embodiments, the first target control can be understood as a first control in the first graphical user interface that is bound to the role control permissions of the second virtual character obtained by the first terminal device, and is an interactive element for manipulating the second virtual character.

[0131] In some embodiments, the first display format can be understood as the interface display style used to identify the first target control, including visual features such as color, brightness, and special effects, which distinguish it from ordinary controls.

[0132] To more clearly illustrate the virtual character control method in the game provided in the embodiments of this application, please also refer to... Figure 3 , Figure 4 , Figure 6 , Figure 7 And the following exemplary description, namely: During a game, the first graphical user interface 300 is equipped with multiple first controls 341 to 349 for controlling virtual characters. Each first control is uniquely bound to the control permissions of a first virtual character 330. Players on the first terminal device can perform various operations on the first virtual character 330 by triggering different first controls.

[0133] The second graphical user interface 400 is provided with multiple first controls 441 to 449 that are uniquely bound to the character control permissions of the second virtual character 430. Each first control is uniquely bound to a control permission of the second virtual character 430. The player of the second terminal device can perform various operations on the second virtual character 430 by triggering different first controls.

[0134] The second terminal device sends a request to the first terminal device to take over the control of the second virtual character 430. After the player on the first terminal device triggers the consent control 352 in the takeover window 350, the first terminal device responds to the trigger operation. First, it determines the control permissions of the second virtual character 430 obtained by the first terminal device, and then matches the first controls 441, 442, 444 to 448 in the first graphical user interface 300 that are bound to the obtained control permissions, and determines these first controls 441, 442, 444 to 448 as the first target controls.

[0135] Subsequently, the first terminal device controls the first target controls 441, 442, 444 to 448 to display them in a first display format. The first display format is set with visual features different from ordinary controls. For example, as shown in the figure, the background of the first target controls 441, 442, 444 to 448 is set to highlight.

[0136] In some embodiments, the first display format has the characteristics of high recognizability and low visual impact, which allows players to quickly identify the display without affecting the overall visual effect of the first graphical user interface 300 and the operation of other controls.

[0137] The first display format of the first target controls 441, 442, 444 to 448, etc., takes effect immediately after the first terminal device obtains control rights over the second virtual character 430, and continues to be maintained during the trusteeship operation until the first terminal device releases control rights over the second virtual character 430.

[0138] Players on the first terminal device can quickly locate all operable first target controls 441, 442, 444 to 448 through the first display format, and directly perform corresponding control operations on the second virtual character 430 without having to perform trial and error operations.

[0139] Thus, in this embodiment, by responding to the trigger operation of the consent control, the first terminal device obtains control over the second virtual character, and simultaneously controls the first target control to be displayed in a first display format. The first display format identifies the operable first target control, providing clear and intuitive operation prompts to the player after the character control is transferred, allowing the player to quickly identify operable controls. This reduces the time spent on trial and error, improves the efficiency of operation after the character takes over, and allows the player to enter the operation state more quickly. This, in turn, ensures the continuity of game battles to a certain extent, improves the cooperation efficiency and strategic flexibility of team games, and enhances the player's gaming experience and team stickiness.

[0140] Please refer to the embodiments provided in this application as well. Figure 3 , Figure 4 and Figure 8 , Figure 8 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application. The method further includes: responding to a trigger operation on a first control, controlling a second target control among a plurality of first controls to display in a second display format to indicate that the second virtual character cannot be controlled by the second target control; the second target control is a control among a plurality of first controls that is distinct from the first target control.

[0141] Specifically, only the first target control that can control the second virtual character is marked with a display format, while no corresponding visual mark is set for the first control that cannot control the second virtual character. Distinguishing between them relies on their default state without special markings, resulting in weak visual contrast. This makes it easy for players on the first terminal device to accidentally touch uncontrollable controls, reducing the smoothness of assisted control. Based on the above problems, in some embodiments provided in this application, while controlling the first target control to display in a first display format, a second target control that is different from the first target control is identified among multiple first controls, and the second target control is controlled to display in a second display format. By using two different display formats to distinguish between operable and non-operable controls, the visual prompting effect of permissions is enhanced, and accidental operation is avoided.

[0142] In some embodiments, the second target control can be understood as the first control in the first graphical user interface that is distinct from the first target control, namely the first control that is bound to the role control permissions of the second virtual character not obtained by the first terminal device, and is the first control that the player of the first terminal device cannot operate.

[0143] In some embodiments, the second display format can be understood as an interface display style used to identify the second target control, possessing unique visual characteristics and differing from the first display format. Examples include dark, specific dark background, and grayscale display formats.

[0144] To more clearly illustrate the virtual character control method in the game provided in the embodiments of this application, please also refer to... Figure 3 , Figure 4 , Figure 8 The following is an example illustration: During the game, the first graphical user interface 300 is equipped with multiple first controls 341 to 349 that are uniquely bound to the first virtual character control 330, and the second graphical user interface 400 is equipped with multiple first controls 441 to 449 that are uniquely bound to the second virtual character 430's character control permissions.

[0145] The second terminal device sends a request to the first terminal device to take over the control of the second virtual character 430. After the player on the first terminal device triggers the consent control in the management window, the first terminal device responds to the trigger operation, determines the control permissions of the second virtual character 430 obtained by the first terminal device, matches and determines the corresponding first controls 441, 442, 444 to 448 as the first target controls, and determines the other first controls 443, 449, etc. that are different from the first target controls as the second target controls.

[0146] Subsequently, the first terminal device synchronously controls all first target controls 441, 442, 444 to 448 to display them in a first display format, using highlighted visual features to identify operable controls, and controls all second target controls 443, 449 to display them in a second display format. The second display format uses visual features different from the first display format, for example, such as... Figure 8 As shown, the background of the second target controls 443, 449, etc. is set to gray or dark. The setting of the second display format must ensure that the player of the first terminal device can recognize that the second target controls 443, 449, etc. are in an inoperable state, while not excessively affecting the overall visual effect of the first graphical user interface 300.

[0147] The first display format of the first target controls 441, 442, 444 to 448 and the second display format of the second target controls 443, 449, etc. take effect synchronously after obtaining control permissions, and remain continuously maintained during the trusteeship operation until the trusteeship operation ends.

[0148] During the entrusted operation, players on the first terminal device can quickly distinguish between operable and non-operable controls through the first and second display formats, intuitively grasp the permission boundaries, avoid accidental operation due to visual oversight triggering the second target control, and improve the accuracy of operation.

[0149] Thus, in this embodiment, by responding to the trigger operation of the consent control, the first terminal device obtains control rights over the second virtual character. Simultaneously, it controls the first target control to be displayed in a first display format and the second target control to be displayed in a second display format, respectively indicating the controllable and non-controllable controls of the second virtual character. This achieves differentiated visual identification of controllable and non-controllable controls, allowing the player on the first terminal device to clearly distinguish between controllable and non-controllable controls after obtaining control rights. Accurate control can be achieved without additional trial and error, avoiding accidental touches of non-controllable controls in tense battle scenarios. This improves the smoothness and accuracy of controlled operation, thereby ensuring the continuity of game battles to a certain extent, enhancing the collaborative efficiency and strategic flexibility of team games, and strengthening the player's gaming experience and team engagement.

[0150] In some embodiments provided in this application, the first graphical user interface further includes a first control for controlling a virtual character, and the method further includes: in response to a trigger operation on the consent control, switching the target virtual character currently controlled by the first control from a first virtual character to a second virtual character.

[0151] Specifically, after the first terminal device gains control of the second virtual character, the first control in the first graphical user interface still defaults to controlling the first virtual character. The player on the first terminal device needs to perform additional manual operations to switch the control object to the second virtual character, increasing the operation steps and causing operation interruptions after character takeover, affecting the timeliness of operations. Furthermore, the additional manual switching operation can distract the player and affect judgment during the game. Based on the above problems, in some embodiments provided in this application, a first control for controlling the virtual character is set in the first graphical user interface. When the player on the first terminal device triggers the control, the first terminal device automatically responds to the trigger operation, directly switching the target virtual character currently controlled by the first control from the first virtual character to the second virtual character, without requiring additional manual switching operations from the player, thus achieving automatic switching of the control object.

[0152] In some embodiments, the target virtual character can be understood as a virtual character currently controlled by a first control in a first graphical user interface, which is the direct object operated by the player of the first terminal device, and can be switched between a first virtual character and a second virtual character according to actual needs.

[0153] To more clearly illustrate the virtual character control method in the game provided in this application embodiment, please refer to the following exemplary description: During a game, the first graphical user interface is equipped with a first control for controlling the virtual character. In normal state, the first control controls the first virtual character of the first terminal device itself by default. Players on the first terminal device can perform various operations on the first virtual character by triggering the first control.

[0154] The second terminal device sends a request to the first terminal device to take over the control of the second virtual character. After the player on the first terminal device triggers the consent control in the management window, the first terminal device responds to the operation of triggering the consent control. While obtaining the control of the second virtual character, it automatically performs a switching operation on the target virtual character, directly switching the target virtual character currently controlled by all the first controls in the first graphical user interface from the first virtual character to the second virtual character.

[0155] After the switching operation is completed, all operation commands of the first control are directly applied to the second virtual character. Players on the first terminal device can control the second virtual character by triggering the first control without needing to perform any additional manual switching operations.

[0156] In addition, in some embodiments, after the trusteeship operation is completed, the first terminal device will automatically switch the target virtual character controlled by the first control back to the first virtual character and restore the normal operation state.

[0157] Thus, in this embodiment, by responding to the trigger operation of the consent control, the first terminal device obtains control permissions over the second virtual character, and simultaneously switches the target virtual character currently controlled by the first control from the first virtual character to the second virtual character. This achieves automatic linkage switching between the acquisition of management permissions and the control object, eliminating the need for players to perform additional manual switching operations. Players can control the second virtual character through the first control as soon as they obtain control permissions, which to some extent avoids the problem of delays caused by manual switching in tense battle scenarios, improves the smoothness and timeliness of management control, and the automatic switching of the control object reduces the player's operation steps, to some extent avoiding the problem of additional operations distracting the player's attention, allowing the player to focus more on the operation and judgment of the game, and improving the game experience.

[0158] In some embodiments provided in this application, the first virtual character is located in the center area of ​​the first scene area, and the method further includes: when the target virtual character is switched from the first virtual character to the second virtual character, controlling the first graphical user interface to switch the currently displayed scene area from the first scene area to the second scene area; the second virtual character is located in the center area of ​​the second scene area.

[0159] Specifically, when switching the target virtual character from the first virtual character to the second virtual character, the position of the second virtual character is not simultaneously adapted. The first graphical user interface still displays the first scene area centered on the first virtual character. When the player operates the second virtual character, they cannot see the game scene centered on the second virtual character, resulting in a mismatch between the operating perspective and the controlled object, which can easily lead to operational errors by the player on the first terminal device. Based on the above problems, in some embodiments provided in this application, while switching the target virtual character from the first virtual character to the second virtual character, the first terminal device simultaneously controls the first graphical user interface to switch the currently displayed scene area from the first scene area centered on the first virtual character to the second scene area centered on the second virtual character, thus achieving synchronous switching between the game scene perspective and the controlled character.

[0160] In some embodiments, the second scene area can be understood as a portion of the virtual scene displayed in the second graphical user interface, which is the range of the game environment that the player corresponding to the second terminal device can intuitively see.

[0161] To more clearly illustrate the virtual character control method in the game provided in this application embodiment, please refer to the following exemplary description: During the game, the first graphical user interface normally displays the first scene area of ​​the virtual scene, the first virtual character of the first terminal device is located in the first scene area, and the player of the first terminal device observes the surrounding scene of the first virtual character and performs operations through the first scene area.

[0162] The first control in the first graphical user interface controls the first virtual character by default. When the second terminal device sends a request to the first terminal device to take over the control of the second virtual character, after the player on the first terminal device triggers the consent control, the first terminal device first switches the target virtual character controlled by the first control from the first virtual character to the second virtual character, and at the same time performs the scene area switching operation.

[0163] Based on the real-time position of the second virtual character in the game's virtual scene, the first terminal device generates a second scene area centered on the second virtual character. The display range and viewing angle of the second scene area are consistent with those of the first scene area, ensuring a unified visual experience for players on the first terminal device.

[0164] Subsequently, the first terminal device controls the first graphical user interface to seamlessly switch the currently displayed scene area from the first scene area to the second scene area. After the scene area switch is completed, the second virtual character is located in the second scene area. The player on the first terminal device can observe the surrounding scene of the second virtual character through the second scene area, and the operation commands triggered by the first control will also be accurately applied to the second virtual character.

[0165] During the management process, the second scene area will be updated in real time as the second virtual character moves, always keeping the second virtual character within the second scene area.

[0166] When the current player finishes their operation, or when the player on the first terminal device switches the target virtual character back to the first virtual character, the first terminal device will simultaneously switch the scene area back to the first scene area, restoring the original viewpoint and operation state.

[0167] Thus, in this embodiment, in response to the trigger operation of the consent control, the target virtual character currently controlled by the first control is switched from the first virtual character to the second virtual character. At the same time, the first graphical user interface is controlled to switch the currently displayed scene area from the first scene area to the second scene area. This achieves synchronous linkage switching between the target virtual character and the scene area, solving the problem of scene perspective mismatch caused by only switching the control object. It reduces operational errors caused by perspective asynchrony to a certain extent, improves the accuracy of operation, and the synchronous switching between the scene area and the control object achieves seamless connection between permission acquisition, object switching and perspective adaptation. This improves the smoothness and timeliness of the managed control to a certain extent, thereby improving the collaborative efficiency and overall fun of team games, enhancing player stickiness and combat experience.

[0168] Please refer to the embodiments provided in this application as well. Figure 3 , Figure 4 and Figure 9 , Figure 9 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application. The method further includes: when switching the target virtual character from a first virtual character to a second virtual character, controlling a first graphical user interface to display a target window; the target window is used to display a first scene area.

[0169] Specifically, after switching the scene area to the second scene area, the first graphical user interface no longer displays the first scene area. When operating the second virtual character, the player on the first terminal device cannot monitor the scene status and surrounding conditions of their original controlled first virtual character in real time. If the first virtual character encounters danger, the player on the first terminal device cannot detect and respond in time, resulting in damage to their character, affecting the win rate of the game, and reducing their control over the game. Based on the above problems, in some embodiments provided in this application, while switching the target virtual character to the second virtual character and simultaneously switching to the second scene area, the first terminal device controls the first graphical user interface to display a target window. This target window is used to display the first scene area in real time, allowing the player on the first terminal device to check the scene status of the first virtual character at any time while operating the second virtual character.

[0170] In some embodiments, the target window can be understood as a visual sub-window set in the first graphical user interface, used to synchronously display the first scene area, and is an auxiliary interface for players to view the scene status of the first virtual character.

[0171] To more clearly illustrate the virtual character control method in the game provided in the embodiments of this application, please also refer to... Figure 3 , Figure 4 , Figure 9And the following exemplary description, namely: During the game, the second terminal device sends a request to the first terminal device to take over the control of the second virtual character 430. After the player on the first terminal device triggers the consent control, the first terminal device switches the target virtual character from the first virtual character 330 to the second virtual character 430, and at the same time switches the scene area of ​​the first graphical user interface 300 from the first scene area to the second scene area centered on the second virtual character 430.

[0172] Simultaneously, the first terminal device generates and displays a target window 360 at a designated location in the first graphical user interface 300. The target window 360 can be a small floating window, located in a non-core operation area of ​​the first graphical user interface 300, for example... Figure 9 As shown, the target window 360 is positioned in the upper right corner of the first graphical user interface 300 to ensure that it does not obscure the content of the second scene area and the operation area of ​​the first controls 441 to 449.

[0173] In some embodiments, the display size of the target window 360 can be optimized according to the first graphical user interface 300 to ensure that the player of the first terminal device can clearly view the content without occupying too much interface space.

[0174] The target window 360 displays the first scene area centered on the first virtual character 330 in real time. The screen of the first scene area is updated synchronously with the first scene area in the normal state, which can display the real-time position, health status and surrounding scene of the first virtual character 330, allowing the player on the first terminal device to intuitively grasp the status information of the first virtual character 330.

[0175] During the management process, the target window 360 remains on display. The screen of the first scene area is updated in real time as the first virtual character 330 moves and changes in status. When the player on the first terminal device is operating the second virtual character 430, they can quickly check the status of the first virtual character 330 through the target window 360.

[0176] Thus, in this embodiment, in response to the trigger operation of the consent control, the target virtual character currently controlled by the first control is switched from the first virtual character to the second virtual character. At the same time, the first graphical user interface is controlled to switch the currently displayed scene area from the first scene area to the second scene area. In addition, the first graphical user interface is controlled to display a target window for displaying the first scene area. By adding a target window, the visualization of the first scene area is preserved, which solves the problem of the original character's perspective being lost during the management process. This allows the player on the first terminal device to view the scene status and surrounding situation of the first virtual character they originally controlled in real time through the target window while taking over the operation of the second virtual character. This improves the safety and rationality of multi-character operation to a certain extent. Moreover, the parallel design of the target window and the main scene conforms to the player's multi-tasking habits. Dual scene observation can be achieved without switching interfaces, which reduces the complexity of operation and the cost of perspective switching to a certain extent. This allows the player on the first terminal device to more efficiently balance the needs of collaboration and the safety of their own character.

[0177] Please refer to the embodiments provided in this application as well. Figure 3 , Figure 4 , Figure 9 and Figure 10 , Figure 10 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application. The target window includes a switching control for switching the target virtual character. The method further includes: in response to a triggering operation of the switching control, switching the target virtual character from a first virtual character to a second virtual character, or from a second virtual character to a first virtual character; and replacing the scene area currently displayed in the first graphical user interface with the scene area currently displayed in the target window.

[0178] Specifically, while the player on the first terminal device can monitor the status of the first virtual character through the target window, there is a lack of a convenient way to quickly switch the controlled object. If the first virtual character encounters an emergency and needs to be controlled immediately, or if the second virtual character completes its task and needs to return to its own character, the player on the first terminal device needs to switch the controlled object and scene through complex operations, reducing the flexibility and timeliness of multi-character control. Based on the above problems, in some embodiments provided in this application, a switching control is added to the target window used to display the first scene area. The switching control is used to trigger the switching of the target virtual character. When the player on the first terminal device triggers the switching control, the first terminal device switches the target virtual character currently controlled by the first control between the first virtual character and the second virtual character, and swaps the main display scene area of ​​the first graphical user interface with the scene area displayed in the target window, realizing the linkage switching between the controlled object and the view scene.

[0179] In some embodiments, the switching control can be understood as an interactive element set within the target window to trigger the switching of the target virtual character.

[0180] To more clearly illustrate the virtual character control method in the game provided in the embodiments of this application, please also refer to... Figure 3 , Figure 4 , Figure 9 , Figure 10 And the following exemplary description, namely: During a game, after the player on the first terminal device triggers the consent control, the first terminal device switches the target virtual character to the second virtual character 430, switches the scene area to the second scene area, and displays a target window 360 on the first graphical user interface 300 to display the first scene area. The target window 360 includes the switching control.

[0181] During the entrusted operation, if the player on the first terminal device needs to switch the target virtual character from the second virtual character 430 to the first virtual character 330, they can directly trigger the switching control in the target window 360. The first terminal device immediately responds to the triggering operation of the switching control, first switching the target virtual character currently controlled by the first control from the second virtual character 430 to the first virtual character 330, and simultaneously performing a scene area replacement operation, swapping the second scene area currently displayed on the first graphical user interface 300 with the first scene area displayed in the target window 360. That is, the main interface of the first graphical user interface 300 displays the first scene area, while the target window 360 displays the second scene area, ensuring that the operation perspective and the controlled object are always matched.

[0182] If the player on the first terminal device needs to switch the target virtual character from the first virtual character 330 back to the second virtual character 430, they can trigger the switching control in the target window 360 again. The first terminal device will repeat the above operation, switching the first virtual character 330 to the second virtual character 430, and swapping the scene areas of the main interface and the target window 360 again, thus achieving bidirectional fast switching of the target virtual character.

[0183] Thus, in this embodiment, in response to the triggering operation of the switching control, the target virtual character can be switched between the first virtual character and the second virtual character, and the scene area displayed in the main display scene area and the target window can be replaced. This realizes the linkage switching between the target virtual character and the scene area, effectively solving the problems of cumbersome character switching process and easy misalignment of perspective and control object in multi-character control. Moreover, the design of the switching control enables the player of the first terminal device to quickly complete the switching of control object, effectively saving game time and avoiding character loss due to untimely switching to a certain extent.

[0184] In addition, the synchronous replacement of the main scene area of ​​the first graphical user interface with the target window scene ensures to a certain extent that the controlled object and the view scene always match after switching, avoiding operation errors caused by view misalignment and improving the smoothness and immersion of multi-character control.

[0185] In some embodiments provided in this application, the first graphical user interface further includes a first control for controlling a virtual character, and the method further includes: in response to a trigger operation on the consent control, determining both the first virtual character and the second virtual character as target virtual characters currently controlled by the first control.

[0186] Specifically, the first control can only control a single target virtual character, failing to simultaneously control two virtual characters. This limits the cooperative gameplay and strategic depth of the game, and also cannot meet the needs of some match scenarios where players require synchronized basic operations on two virtual characters using a single control. Based on these issues, in some embodiments provided in this application, a first control for controlling virtual characters is set in the first graphical user interface. When a player on the first terminal device triggers the consent control, the first terminal device identifies both the first and second virtual characters as the target virtual characters currently controlled by the first control, enabling simultaneous control of multiple virtual characters of the same faction by a single terminal's operation control.

[0187] To more clearly illustrate the virtual character control method in the game provided in this application embodiment, please refer to the following exemplary description: During a game, the first graphical user interface is equipped with multiple first controls that control the first virtual character, and each control is bound to a basic control permission of the first virtual character.

[0188] The second terminal device sends a request to the first terminal device to take over the control of the second virtual character. After the player on the first terminal device triggers the consent control in the takeover window, the first terminal device determines its own first virtual character and the second virtual character it takes over as the target virtual character currently controlled by all the first controls in the first graphical user interface.

[0189] At this time, all operation commands of the first control will be applied to the first virtual character and the second virtual character simultaneously, realizing synchronous control of the two characters. For example, if the player of the first terminal device triggers the movement control, the first virtual character and the second virtual character will move synchronously in the specified direction. If the player of the first terminal device triggers the stop control, the first virtual character and the second virtual character will stop moving simultaneously.

[0190] During the escrow operation, the first virtual character and the second virtual character are always the target virtual characters jointly controlled by the first control. Players on the first terminal device can perform basic synchronous operations on the two characters through the first control.

[0191] After the current management operation is completed, the first terminal device will automatically release control over the second virtual character, and the first control will revert to a state where it only controls the first virtual character.

[0192] Thus, in this embodiment, by responding to the trigger operation of the consent control, the first terminal device obtains control permissions over the second virtual character, and simultaneously determines the first and second virtual characters as the target virtual characters currently controlled by the first control. This enables a single terminal's operation control to simultaneously control multiple virtual characters of the same faction, which to some extent enhances the depth of cooperation between players and the strategic nature of the game. Furthermore, by performing basic operations on two characters simultaneously through a single control, the operational efficiency of the game is effectively improved, allowing for the rapid completion of operations such as adjusting the positions of multiple characters. This adapts to the special needs of some game scenarios, thereby expanding the forms of character control to some extent, realizing the synchronous control of multiple characters, effectively enriching the gameplay, and enhancing the cooperation and strategy of team games.

[0193] Please refer to the embodiments provided in this application as well. Figure 3 , Figure 4 and Figure 5 The managed window also includes a rejection control, and the method further includes: responding to a trigger action on the rejection control to reject the managed request.

[0194] Specifically, the proxy management window only provides an "agree" control and lacks a direct "reject" option. This forces players on the first terminal device to close the window or ignore the request if they do not wish to accept the proxy management request, resulting in inconsistent operation logic. Furthermore, the second terminal device cannot receive timely rejection feedback and remains in a waiting state, impacting the gaming experience. To address these issues, some embodiments provided in this application add a rejection control to the proxy management window. When a player on the first terminal device triggers the rejection control, the first terminal device responds and rejects the proxy management request.

[0195] In some embodiments, the rejection control can be understood as an interactive element set in the management window for rejecting management requests. It can be arranged side by side with the consent control and is the operation carrier for players to directly reject management requests.

[0196] To more clearly illustrate the virtual character control method in the game provided in the embodiments of this application, please also refer to... Figure 3 , Figure 4 , Figure 5 And the following exemplary description, namely: During a game, the second terminal device sends a request to the first terminal device to take over the control of the second virtual character 430. After receiving the request, the first terminal device displays a takeover window 350 on the first graphical user interface 300, which includes an agree control 352 and a refuse control 353.

[0197] Players on the first terminal device can decide on the appropriate course of action based on their current game status.

[0198] If the player chooses to reject the management request, the first terminal device player will perform a valid trigger operation such as clicking or touching the rejection control 353 in the management window 350. The first terminal device will respond immediately and generate a rejection command, terminating the subsequent processing of the management request. No permissions will be assigned, and the first terminal device will still maintain complete control over the first virtual character 330. The management request will then become invalid.

[0199] In some embodiments, after the player on the first terminal device performs a valid triggering operation such as clicking or touching the rejection control 353, the second terminal device will receive feedback that the proxy request has been rejected, and can choose to re-initiate the request at an appropriate time or seek assistance from other teammates. For example, a brief prompt such as "The other party has rejected your proxy request" will pop up in the second graphical user interface 400 to inform the player on the second terminal device that the proxy request has failed.

[0200] In some embodiments, during a 30-second skill cooldown period starting from the time the rejection operation of the custodian request is triggered, the second terminal device cannot send a custodian request to the first terminal device again. During the skill cooldown period, the corresponding operation entry such as the custodian request button on the second terminal device will be grayed out and cannot be clicked. After the skill cooldown period ends, the operation entry such as the custodian request button will return to its normal state.

[0201] Thus, in this embodiment, the first terminal device responds to a role control delegation request sent by a second terminal device in the same faction, and a delegation window including an agree control and a refuse control pops up on the first graphical user interface. The device responds to the trigger operation of the refuse control to reject the delegation request, allowing the first terminal device player to decide whether to accept the delegation request based on their actual game state. This solves the problem of the first terminal device player passively responding to delegation requests, improving the operational autonomy and gaming experience of the first terminal device player to a certain extent. Furthermore, the clear rejection feedback allows the second terminal device player to know the result of the delegation request in a timely manner, avoiding continuous waiting or repeated invalid requests, thus improving the efficiency of delegation request interaction and reducing communication costs between players. This balances the assistance needs of the second terminal device player with the autonomy of the first terminal device player, making cooperation between players in the same faction more flexible and reasonable, optimizing the cooperative ecosystem of multiplayer online games, and enhancing the user-friendliness of the game and the overall gaming experience for players.

[0202] Please refer to the embodiments provided in this application as well. Figure 3 , Figure 4 and Figure 5 The managed window is also used to display the character attribute information of the second virtual character.

[0203] Specifically, the current management window only provides an "agree" button and does not display the status information of the second virtual character. Before triggering the "agree" button, the player on the first terminal device cannot know the current status of the second virtual character. This makes it difficult for the player to determine whether they are capable of taking over the management, potentially leading to blindly accepting the request only to be unable to perform effective actions due to the character's poor condition, thus affecting the game's win rate. To address these issues, some embodiments provided in this application add a display area for the second virtual character's attribute information to the management window. This allows the player on the first terminal device to visually view the current status of the second virtual character through the management window and make a reasonable decision about whether to agree to management based on their own game situation, avoiding decision-making errors caused by information asymmetry.

[0204] In some embodiments, character attribute information can be understood as data that reflects the current state of the second virtual character, including but not limited to the character's current health, remaining mana, level, skill cooldown time, energy value, battlefield location, current health percentage, etc., which can be used by players to assess the difficulty and value of the entrusted management.

[0205] To more clearly illustrate the virtual character control method in the game provided in the embodiments of this application, please also refer to... Figure 3 , Figure 4 , Figure 5 And the following exemplary description, namely: During a game, the second terminal device sends a request to the first terminal device to take over control of the second virtual character 430. Upon receiving the request, the first terminal device displays a takeover window 350 in the first graphical user interface 300. In addition to consent controls, the takeover window 350 includes a character attribute information display area 410. The displayed content can be dynamically adjusted according to the game type and character characteristics. For example, it may display the character's current health percentage (from full health), current level, remaining skill cooldown time, and a brief indication of the battlefield area where the character is located.

[0206] In some embodiments, the character attribute information 410 is synchronized in real time with the latest status of the second virtual character 430 to ensure that the information obtained by the player on the first terminal device is accurate and effective.

[0207] After viewing the character attribute information 410, the player on the first terminal device can trigger the consent control if they determine that the character is in good condition and they are capable of operating the character. If they determine that the character is in extremely poor condition or they are unable to cope with the current situation, they can refuse to take over.

[0208] Thus, in this embodiment, in response to receiving a character control delegation request from a second terminal device in the same faction, the first terminal device pops up a delegation window on the first graphical user interface, including an agreement control and character attribute information of the second virtual character. Upon triggering the agreement control, the first terminal device gains control of the second virtual character. The display of the second virtual character's character attribute information provides the first terminal device player with a basis for decision-making regarding takeover, allowing the player to understand the current state of the second virtual character before accepting the delegation request. This effectively avoids operational errors caused by blind takeover, improves the effectiveness of accepting delegation requests and the win rate in games, and thus optimizes the cooperative experience of multiplayer online competitive games, enhancing the game's strategy and fun.

[0209] Please refer to the embodiments provided in this application as well. Figure 3 , Figure 4 , Figure 11 and Figure 12 , Figure 11 and Figure 12 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application embodiment. The method further includes: in response to a triggering operation requesting to take over control of a second virtual character, sending a takeover request to a second terminal device, so as to obtain control over the second virtual character when the second terminal device responds with an instruction agreeing to the takeover request.

[0210] Specifically, the current approach, which only supports the second terminal device initiating a takeover request and prevents the first terminal device from actively sending a takeover request to the second terminal device, fails to meet the needs of scenarios where skilled players proactively guide novice players or offer assistance when teammates encounter operational difficulties. This limits the flexibility of character control interaction and reduces the collaborative efficiency of team games. Based on the above issues, in some embodiments provided in this application, after the first terminal device player executes the trigger operation to request takeover of the second virtual character's control, the first terminal device sends a takeover request to the second terminal device. After the second terminal device responds with an agreement instruction, the first terminal device gains control of the second virtual character, realizing a two-way collaborative mode from passively receiving requests to actively initiating requests.

[0211] In some embodiments, a takeover request can be understood as an information request sent by the first terminal device to the second terminal device, requesting to take over the control of the second virtual character. This is consistent with the logic of the management request initiated by the second terminal device, and constitutes a two-way request cooperation mode.

[0212] In some embodiments, the consent instruction can be understood as a confirmation message sent by the second terminal device player to the first terminal device after agreeing to the takeover request of the first terminal device.

[0213] To more clearly illustrate the virtual character control method in the game provided in the embodiments of this application, please also refer to... Figure 3 , Figure 4 , Figure 11 , Figure 12 And the following exemplary description, namely: After the first terminal device runs the game program, it provides the player with a first graphical user interface 300. The first graphical user interface 300 displays a first scene area centered on the first virtual character 330 in real time. The player on the first terminal device can perform various operations on the first virtual character 330 through the control elements within the first graphical user interface 300. Simultaneously, the first graphical user interface 300 can also be set with an entry point for actively initiating takeover requests, for example... Figure 11 As shown, a "Request Access" button (370, etc.) is set on the right side of the teammate list.

[0214] When the player on the first terminal device observes that the second virtual character 430 needs assistance, they can click the request access function button 370 to send a takeover request from the first terminal device to the second terminal device.

[0215] like Figure 12 As shown, after receiving the takeover request, the second terminal device can pop up a prompt window through the second graphical user interface 400 to inform the player on the second terminal device that a teammate has requested to take over the control of the second virtual character 430. The player on the second terminal device can choose whether to agree according to their own needs.

[0216] If the player on the second terminal device agrees to the player on the first terminal device managing the second virtual character 430, they can click on [the appropriate action]. Figure 12 The "Agree" button shown triggers the agreement action, sending an agreement command to the first terminal device.

[0217] After receiving the consent instruction, the first terminal device obtains control over the second virtual character 430. At this time, the player of the first terminal device can control the second virtual character 430 through its own first graphical user interface 300 and control elements.

[0218] Meanwhile, in some embodiments, the first terminal device retains control over the first virtual character 330 and can flexibly switch the control object according to the game situation.

[0219] Thus, in this embodiment, by responding to the triggering operation of requesting to take over control of the second virtual character, a takeover request is sent to the second terminal device. Upon receiving a consent instruction from the second terminal device, control of the second virtual character is obtained. This breaks through the single passive receiving of management requests mode and constructs a two-way collaborative request mode. It effectively avoids the problem of team interests being damaged due to missed opportunities, improves the timeliness and flexibility of team collaboration, and the effectiveness of the takeover request depends on the consent instruction from the second terminal device, effectively protecting the second terminal device player's dominant control over their own character. To a certain extent, it avoids the game experience problems caused by forced takeover, improves the fairness and rationality of team collaboration, and thus enriches the collaborative gameplay to a certain extent, strengthens the interaction and cooperation between players, and optimizes the overall game experience.

[0220] Please refer to the embodiments provided in this application as well. Figure 3 , Figure 4 and Figure 13 , Figure 13 This is a schematic diagram illustrating an application scenario of the virtual character control method in a game provided in this application. The method further includes: upon obtaining control permissions for a second virtual character, controlling a first graphical user interface to display a second control; the second control being used to release control permissions for the second virtual character; and releasing control permissions for the second virtual character in response to a triggering operation on the second control.

[0221] Specifically, after acquiring control of the second virtual character, the first terminal device cannot actively release this control. When the player on the first terminal device needs to focus on their own first virtual character, or when the second virtual character is out of danger, the inability to release control in a timely manner can easily lead to scattered operations or control hogging, affecting the gaming experience between players. Based on the above problems, in some embodiments provided in this application, after the first terminal device acquires control of the second virtual character, a second control is displayed in the first graphical user interface. When the player triggers the second control, the first terminal device immediately responds, actively releasing control over the second virtual character and terminating the proxy operation.

[0222] In some embodiments, the second control can be understood as an interactive element displayed in the first graphical user interface after the first terminal device obtains the role control permission of the second virtual character, and is used by the first terminal device to actively release the role control permission of the second virtual character.

[0223] To more clearly illustrate the virtual character control method in the game provided in the embodiments of this application, please also refer to... Figure 3 , Figure 4 , Figure 13 And the following exemplary description, namely: When the first terminal device obtains control permissions for the second virtual character 430, the first terminal device automatically displays the second control 380 at a designated location on the first graphical user interface 300, for example, such as... Figure 13 As shown, the second control 380 is displayed in the function bar on the right side of the player on the second terminal device, corresponding to the team panel in the upper left corner of the first graphical user interface 300.

[0224] In some embodiments, the second control 380 may be designed with text such as "Release Control" and an icon to visually distinguish it from other controls and prevent players from accidentally touching it.

[0225] In some embodiments, the second control 380 is displayed when it obtains control of the second virtual character 430 from the first terminal device, and is hidden after the first terminal device releases control over the second virtual character 430.

[0226] During the trusteeship process, when the player of the first terminal device believes that it is no longer necessary to take over the second virtual character 430, they can perform effective triggering operations such as clicking or touching on the second control 380. The first terminal device will respond to the triggering operation on the second control 380 and release all control permissions of the first terminal device over the second virtual character 430.

[0227] Thus, in this embodiment, when the first terminal device obtains control over the second virtual character, it controls the first graphical user interface to display a second control for releasing control. In response to the triggering of the second control, the first terminal device releases control over the second virtual character, granting the player the right to actively release control. This allows the player to flexibly terminate the takeover operation based on the actual situation of the game, improving the flexibility and autonomy of character control to a certain extent. Furthermore, the active release function enables the player to promptly return control when needing to focus on their first virtual character or when the second virtual character does not require assistance, thus avoiding operational distraction or resource waste caused by control occupation and ensuring the smoothness of the game.

[0228] Furthermore, the design of the second control makes the permission release operation intuitive and convenient, effectively reducing the player's operational costs, ensuring the smoothness of permission handover, and thus optimizing the collaborative experience of multiplayer online games to a certain extent. This avoids conflicts caused by long-term permission occupation, enhances the practicality of the game's collaborative mechanism, and improves the overall smoothness of team games and player satisfaction.

[0229] In some embodiments provided in this application, the method further includes: in response to receiving a termination request from a second terminal device to terminate the management of the role control of the second virtual character, releasing the control rights over the second virtual character.

[0230] Specifically, in actual game scenarios, players on the second terminal device may need to promptly reclaim control of their second virtual character due to reasons such as network recovery, completion of emergency tasks, desire to control the character independently, or dissatisfaction with the custodian's operations. However, some of the aforementioned embodiments lack a clear trigger mechanism for reclaiming control, preventing players on the second terminal device from reclaiming control in a timely manner, thus affecting the game experience and decision-making. Based on the above issues, in some embodiments provided in this application, when the first terminal device has already obtained control of the second virtual character and is controlling it, the player on the second terminal device can send a custodian stop request to the first terminal device according to their needs. Upon receiving the custodian stop request, the first terminal device, without additional operation, directly responds and releases control over the second virtual character, fully returning control to the second terminal device and terminating the custodian operation, thereby ensuring the game experience and operational autonomy of the player on the second terminal device.

[0231] In some embodiments, a cessation of management request can be understood as a request initiated by the player on the second terminal device to the first terminal device, requesting the first terminal device to terminate the management operation of the second virtual character's control and reclaim control.

[0232] To more clearly illustrate the virtual character control method in the game provided in this application embodiment, please refer to the following exemplary description: During a game, once the first terminal device gains control of the second virtual character, it can set up a stop management operation entry in the graphical user interface of the second terminal device. For example, in the upper left corner of the team panel of the second graphical user interface, corresponding to the function bar on the right side of the player on the first terminal device, a "Stop Management" button can be displayed.

[0233] When a player on the second terminal device has regained control or is dissatisfied with the takeover operation on the first terminal device and needs to reclaim control, they can trigger an operation at the "Stop Management" entry point to send a management stop request to the first terminal device, including the termination intention and character identifier. For example, clicking the "Stop Management" button triggers the operation.

[0234] After receiving the request to stop the hosting, the first terminal device releases control of the second virtual character directly, terminating the control of the second virtual character, without requiring any additional operation from the player on the first terminal device.

[0235] In some embodiments, the first terminal device may also send a permission revoke confirmation message to the second terminal device. The second graphical user interface of the second terminal device will then display a prompt informing the second terminal device that the player's permissions have been restored. For example, a prompt such as "Control has been successfully revoked" will appear in the second graphical user interface.

[0236] After the first terminal device releases its control over the second virtual character, the second terminal device regains full control over the second virtual character, and the player on the second terminal device can perform various control operations on the second virtual character normally.

[0237] Thus, in this embodiment, by responding to the cessation request sent by the second terminal device, the control authority over the second virtual character is released, granting the second terminal device player the right to terminate the cessation independently. This solves the problem of the second terminal device player passively waiting for the first terminal device player to release character control or being unable to intervene in the cessation behavior, effectively improving the gaming experience and operational autonomy of the second terminal device player. Furthermore, the response to the cessation request does not require additional confirmation from the first terminal device player; the first terminal device directly releases control authority upon receiving the cessation request, effectively ensuring the timeliness and smoothness of control authority recovery, reducing communication costs and operational delays between players, and to a certain extent improving the fairness and flexibility of virtual character cessation. This allows cooperation between players in the same faction to adapt to the dynamic changes of the actual game scenario, thereby enhancing the scientific and practical nature of game cooperation and improving player game satisfaction and team stickiness.

[0238] Please refer to the following for the above questions. Figure 3 , Figure 4 , Figure 5 and Figure 14 , Figure 14 This is a flowchart illustrating a virtual character control method in a game provided in an embodiment of this application. It should be noted that the steps shown may be executed in a different logical order than those shown in the flowchart. The method provides a second graphical user interface (GUI) through a second terminal device. The GUI displays a second scene area of ​​a virtual scene, which includes a second virtual character controlled and operated by the second terminal device. A first virtual character, belonging to the same faction as the second virtual character, is controlled and operated by the first terminal device. The method includes: Step 220: Send a management request for the second virtual character's role control to the first terminal device, so that the first terminal device responds to the received management request by popping up a management window including an agreement control on the first graphical user interface provided by the first terminal device, and by responding to a trigger operation for the agreement control, so as to obtain control permissions for the second virtual character.

[0239] Specifically, in actual game scenarios, when a player on a second terminal device needs assistance from a friend due to unforeseen circumstances, network lag, or insufficient operational skills, there is a lack of clear trigger signals for this assistance. To address this issue, in some embodiments provided in this application, the second terminal device acts as the initiator, displaying a second virtual character and its surrounding scene area through a second graphical user interface provided by the second terminal device. The second terminal device proactively sends a request for assistance with the second virtual character to the first terminal device, triggering the first terminal device to display an assistance window with an agreement control on its first graphical user interface. Once the player on the first terminal device triggers the agreement control, the transfer of control over the second virtual character is completed, achieving full collaboration from the initiator to the receiver.

[0240] In some embodiments, the second graphical user interface can be understood as a visual operation interface displayed when the second terminal device runs a game, including virtual scenes corresponding to the second virtual character, operation controls, and other content.

[0241] To more clearly illustrate the virtual character control method in the game provided in the embodiments of this application, please also refer to... Figure 3 , Figure 4 , Figure 5 And the following exemplary description, namely: During the game, the second terminal device runs the game program and provides a second graphical user interface 400. The second graphical user interface 400 displays a second scene area of ​​the virtual scene. The second virtual character 430, as the object of operation of the second terminal device, is located in the second scene area and is in the same game camp as the first virtual character 330 of the first terminal device. Real-time information interaction is achieved through the team network.

[0242] In some embodiments, the second graphical user interface 400 may also display the association information of the first virtual character 330 of the same faction in the form of a team list, character identifier, etc., so that the player of the second terminal device can clearly identify the collaborating partner.

[0243] When a player on the second terminal device encounters network lag, urgent matters, or operational difficulties, and needs the assistance of the first terminal device to control the second virtual character 430, they can initiate a management request to the first terminal device through the designated operation entry of the second graphical user interface 400.

[0244] In some embodiments, a "Request Cooperation" function button 450 can be set on the right side of the teammate column corresponding to the player on the first terminal device. The player on the second terminal device can click the "Request Cooperation" function button 450 to perform the proxy request sending operation. The second terminal device responds and sends a role control proxy request including information such as the second virtual character identifier and proxy intention to the first terminal device. The proxy request can be transmitted through the team network to ensure the real-time nature and security of the information.

[0245] After receiving the custody request, the first terminal device pops up a custody window 350 on the first graphical user interface 300, which includes an agreement control 352.

[0246] If the player of the first terminal device agrees to manage the control of the second virtual character 430, they can obtain control of the second virtual character 430 by performing effective triggering operations such as clicking or touching the consent control 352.

[0247] In some embodiments, the second graphical user interface 400 of the second terminal device will synchronously provide a prompt message indicating that the custodian request has been agreed to, so as to inform the player on the second terminal device that the custodian collaboration has taken effect.

[0248] In addition, in some embodiments, the "Request Cooperation" button 450 of the second terminal device will be temporarily grayed out after the custodian request is sent and before the first terminal device responds, in order to prevent the player of the second terminal device from sending the custodian request repeatedly.

[0249] In some embodiments, if the player on the first terminal device rejects the custodian request sent by the player on the second terminal device, a rejection prompt will pop up on the interface of the second terminal device, and the "Request Cooperation" button 450 will become clickable again after a 30-second skill cooldown period.

[0250] In some embodiments, if the first terminal device fails to respond to the custodian request sent by the player on the second terminal device within a specified time, the custodian request automatically expires, and a prompt such as "Request timed out" pops up on the second graphical user interface 400 of the second terminal device, and the "Request Collaboration" function button returns to normal.

[0251] Thus, in this embodiment, the second terminal device sends a request for the management of the second virtual character's control to the first terminal device. The first terminal device responds to the request by displaying a management window with an agreement control on its graphical user interface. The first terminal device then triggers an operation on the agreement control to gain control over the second virtual character. In this way, the second terminal device's management request serves as the trigger signal for collaboration, driving the first terminal device to display the corresponding management window. No additional verbal communication or manual intervention is required, which reduces the operational and communication costs of initiating management collaboration to a certain extent. This allows players of different skill levels to easily and quickly initiate management collaboration, thereby ensuring the continuity of game battles, strengthening player interaction and collaboration, and enhancing the fun and player engagement of team games.

[0252] To more clearly illustrate the virtual character control method in the game provided in the embodiments of this application, please also refer to... Figures 3 to 13 And the following exemplary description, namely: like Figure 3 As shown, in the game scenario of a team-based competitive game, the first terminal device provides a first graphical user interface 300 including a first virtual character 330. The first graphical user interface 300 displays a first scene area centered on the first virtual character 330, and is configured with multiple first controls 341 to 349 that are bound to a single control permission of the first virtual character 330.

[0253] like Figure 4 As shown, the second virtual character 430, which is in the same camp as the first virtual character 330, is controlled by the second terminal device. The second terminal device provides a second graphical user interface 400 including the second virtual character 430. The second graphical user interface 400 displays a second scene area centered on the second virtual character 430, and is also configured with multiple first controls 441 to 449 that are bound to the single control authority of the second virtual character 430.

[0254] The first and second terminal devices achieve real-time information interaction through the game team network.

[0255] like Figure 4 As shown, when the player on the second terminal device is unable to control the second virtual character 430 normally due to network lag, sudden events, or other reasons, they can send a request for the management of the second virtual character 430 to the first terminal device through the "Request Cooperation" button 450 and other operation entry points on the second graphical user interface 400.

[0256] like Figure 5 As shown, after receiving the management request, the first terminal device will pop up a management window 350 in the first graphical user interface 300. The basic configuration of the management window 350 includes an agree control 352 and a refuse control 353. It can also display permission prompt information 354 and the character attribute information 410 of the second virtual character 430. The character attribute information 410 includes data such as health, providing the player of the first terminal device with a reliable basis for taking over the management decision.

[0257] The player on the first terminal device can choose to trigger the consent control 352 to accept the trusteeship or trigger the rejection control 353 to refuse the trusteeship, depending on their own operation status and the situation of the second virtual character 430. If the rejection control 353 is triggered, the first terminal device will directly terminate the trusteeship process.

[0258] In some embodiments, the second terminal device will receive a rejection feedback and will be unable to initiate a management request to the first terminal device again within 30 seconds. The corresponding operation entry such as the "Request Collaboration" button 450 will be grayed out and cannot be clicked.

[0259] If the player on the first terminal device triggers the consent control 352, they can directly obtain control permissions for the second virtual character 430.

[0260] In some embodiments, if the custodian request initiated by the second terminal is only a basic assistance request and no specific target control permission range is preset, if the player of the first terminal device triggers the consent control 352, the first terminal needs to send a custodian confirmation request to the second terminal device first. After receiving the request, the second graphical user interface 400 will pop up a permission configuration interface. The player of the second terminal device can choose to assign some or all of the control permissions of the second virtual character 430 as the target control permissions in the permission configuration interface. After completing the configuration, the player sends a permission allocation request to the first terminal device. After receiving the permission allocation request, the first terminal device obtains the corresponding target control permissions.

[0261] like Figure 6 As shown, if the management window 350 is configured with permission prompt information 354, the permission prompt information 354 can indicate the first controls 441, 442, 444 to 448 that the first terminal device can control through the first control identification pattern, and the first controls 443, 449 that cannot be controlled through the second control identification pattern, so that the player of the first terminal device can intuitively know the permission boundaries before taking over the permissions.

[0262] like Figure 7 and Figure 8 As shown, the first terminal device will also distinguish the display format of the first controls of the first graphical user interface 300. The first target control bound to the target control permission will be displayed in a first display format such as highlighting, while the other second target controls will be displayed in a second display format such as graying. This will enable players to accurately distinguish between operable first controls 441, 442, 444 to 448 and inoperable first controls 443, 449, etc., and avoid players accidentally touching them.

[0263] After obtaining control permissions for the target, the first terminal device will automatically complete the linkage switching between the controlled object and the scene perspective, switching the target virtual character currently controlled by the first controls 441, 442, 444 to 448 from the first virtual character 330 to the second virtual character 430, and at the same time switching the display scene of the first graphical user interface 300 from the first scene area to the second scene area centered on the second virtual character 430, thus achieving the matching of control and perspective.

[0264] like Figure 9 and Figure 10 As shown, in order to enable the player of the first terminal device to still monitor the status of their own first virtual character when taking over the second virtual character 430, the first graphical user interface 300 will simultaneously display the target window 360. The target window 360 displays the first scene area in real time, and the target window 360 is configured with switching controls.

[0265] When the player on the first terminal device triggers the switching control, the first terminal device can switch between the first virtual character 330 and the second virtual character 430 in both directions. At the same time, the scene area displayed on the main interface and the scene area displayed in the target window 360 are interchanged, realizing the quick switching control of the two characters and meeting the need for flexible adjustment of the control object in the game.

[0266] In addition, in some embodiments, it is also possible to simultaneously set the first virtual character 330 and the second virtual character 430 as the control objects of the first control. When the player of the first terminal device triggers the first control, the operation command will be applied synchronously to the first virtual character 330 and the second virtual character 430, realizing the synchronous basic control of the two characters and enriching the cooperative gameplay.

[0267] like Figure 13As shown, after the first terminal device obtains the role control permission of the second virtual character 430, the first graphical user interface 300 will display the second control 380 for releasing control. When the player of the first terminal device believes that it is no longer necessary to take over the second virtual character 430, or needs to focus on controlling their own first virtual character 330, the second control 380 can be triggered to actively release the control permission of the second virtual character 430 and terminate the management operation.

[0268] Meanwhile, the second terminal device always retains the dominant control. If the player on the second terminal device regains the ability to operate, is dissatisfied with the managed operation, or wants to regain independent control of the character, they can send a management stop request to the first terminal device through the operation entry of the second graphical user interface 400. After receiving the management stop request, the first terminal device will release all control permissions over the second virtual character 430 without any additional operation, and return the control to the second terminal device. The second terminal device will then regain all control over the second virtual character 430 and will receive a confirmation prompt of permission revocation.

[0269] like Figure 11 and Figure 12 As shown, in addition, in some embodiments, a two-way collaborative mode in which the first terminal device actively initiates a takeover request is also supported. When the player of the first terminal device observes that the second virtual character 430 is difficult to operate and needs assistance, the player can trigger the "Request Intervention" and other operation entry 370 in the first graphical user interface 300 to send a takeover request to the second terminal device. After receiving the request, the second terminal device will pop up a prompt window. After the player of the second terminal device triggers the consent operation, the player will provide a consent instruction.

[0270] After receiving the feedback consent instruction, the first terminal device can obtain control permissions for the second virtual character 430. The subsequent processes such as permission configuration, control display, perspective switching, and release of control are completely consistent with the implementation logic of the second terminal device initiating the trusteeship request, which meets the needs of high-level players to actively guide novice players and provide timely team collaboration.

[0271] Furthermore, all the aforementioned virtual character control technologies are applicable to team-based games with three or more players. They support one player simultaneously taking over the virtual characters of multiple teammates, as well as multiple players collaboratively controlling the same virtual character. The specific implementation method is exactly the same as the logic of dual-character control and dual-player collaborative control. Multiple permissions can be allocated and control objects can be switched by simply configuring permissions multiple times and triggering controls multiple times. This meets the diverse collaborative needs in team games and further enhances the strategy and fun of team games.

[0272] All of the above technical solutions can be combined in any way to form optional embodiments of this application, and will not be described in detail here.

[0273] To facilitate better implementation of the virtual character control method in games according to the embodiments of this application, the embodiments of this application also provide a virtual character control device in games. Please refer to... Figure 15 , Figure 15 This is a schematic diagram of the structure of a virtual character control device in a game provided in an embodiment of this application. The virtual character control device 500 in the game can provide a first graphical user interface through a first terminal device. The first graphical user interface displays a first scene area of ​​a virtual scene. The first scene area includes a first virtual character controlled and operated by the first terminal device, and a second virtual character in the same faction as the first virtual character is controlled and operated by the second terminal device. The virtual character control device 500 in the game may include: The pop-up window module 510 is used to pop up a management window on the first graphical user interface in response to receiving a management request for role control sent by the second terminal device; the management window includes an agreement control; The operation response module 520 is used to respond to the trigger operation of the consent control in order to obtain control permissions for the second virtual character.

[0274] In some embodiments, the managed window further includes permission prompt information, which is used to identify the control permissions of the second virtual character that the first terminal device can obtain and / or the control permissions of the second virtual character that the first terminal device cannot obtain.

[0275] In some embodiments, the first graphical user interface further includes a plurality of first controls for controlling a virtual character, each first control being bound to a control permission of the virtual character, and the permission prompt information including a first control identifier pattern and / or a second control identifier pattern, the first control identifier pattern being used to indicate the first control in the first graphical user interface that is bound to the control permission of the second virtual character that the first terminal device can obtain, and the second control identifier pattern being used to indicate the first control in the first graphical user interface that is bound to the control permission of the second virtual character that the first terminal device cannot obtain.

[0276] In some embodiments, the first graphical user interface further includes a plurality of first controls for controlling the virtual character, each first control being bound to a control permission of the virtual character. The window pop-up module 510 can also be used to respond to a trigger operation for the consent control and control the first target control to be displayed in a first display format to prompt the second virtual character that it can be manipulated through the first target control. The first target control is the control among the plurality of first controls that is bound to the control permission of the obtained second virtual character.

[0277] In some embodiments, the operation response module 520 can also be used to respond to a trigger operation for the consent control, and control the second target control among the plurality of first controls to be displayed in a second display format, so as to prompt that the second virtual character cannot be controlled by the second target control; the second target control is a control among the plurality of first controls that is different from the first target control.

[0278] In some embodiments, the first graphical user interface further includes a first control for controlling a virtual character, and the operation response module 520 can also be used to respond to a trigger operation on the consent control to switch the target virtual character currently controlled by the first control from the first virtual character to the second virtual character.

[0279] In some embodiments, the first virtual character is located in the center of the first scene area, and the operation response module 520 can also be used to control the first graphical user interface to switch the currently displayed scene area from the first scene area to the second scene area when the target virtual character is switched from the first virtual character to the second virtual character; the second virtual character is located in the center of the second scene area.

[0280] In some embodiments, the operation response module 520 can also be used to control the first graphical user interface to display a target window when the target virtual character is switched from the first virtual character to the second virtual character; the target window is used to display a first scene area.

[0281] In some embodiments, the target window includes a switching control for switching the target virtual character. The operation response module 520 can also be used to switch the target virtual character from a first virtual character to a second virtual character or from a second virtual character to a first virtual character in response to the triggering operation of the switching control, and replace the scene area currently displayed by the first graphical user interface with the scene area currently displayed by the target window.

[0282] In some embodiments, the first graphical user interface further includes a first control for controlling the virtual character, and the operation response module 520 can also be used to respond to a trigger operation on the consent control, and determine both the first virtual character and the second virtual character as the target virtual character currently controlled by the first control.

[0283] In some embodiments, the custodian window also includes a rejection control, and the operation response module 520 can also be used to respond to a trigger operation on the rejection control to reject the custodian request.

[0284] In some embodiments, the managed window is also used to display the character attribute information of the second virtual character.

[0285] In some embodiments, the operation response module 520 may also be used to send a takeover request to the second terminal device in response to a triggering operation that requests to take over the role control of the second virtual character, so as to obtain control rights over the second virtual character when the second terminal device responds with an instruction to agree to the takeover request.

[0286] In some embodiments, the operation response module 520 may also be used to control the first graphical user interface to display a second control when it has obtained control permissions over the second virtual character, and to release control permissions over the second virtual character in response to the triggering operation of the second control; the second control is used to release control permissions over the second virtual character.

[0287] In some embodiments, the operation response module 520 may also be used to release control permissions over the second virtual character in response to a request from the second terminal device to stop managing the role control of the second virtual character.

[0288] On the other hand, to facilitate better implementation of the virtual character control method in games according to the embodiments of this application, the embodiments of this application also provide a virtual character control device in games. Please refer to... Figure 16 , Figure 16 This is a schematic diagram of the structure of a virtual character control device in a game provided in an embodiment of this application. The virtual character control device 600 in the game can provide a second graphical user interface through a second terminal device. The second graphical user interface displays a second scene area of ​​a virtual scene. The second scene area includes a second virtual character controlled and operated by the second terminal device, and a first virtual character in the same faction as the second virtual character is controlled and operated by the first terminal device. The virtual character control device 600 in the game may include: The request sending module 610 is used to send a management request for the role control of the second virtual character to the first terminal device, so that the first terminal device responds to the received management request by popping up a management window including an agreement control on the first graphical user interface provided by the first terminal device, and by responding to the trigger operation of the agreement control to obtain control rights over the second virtual character.

[0289] Each unit in the virtual character control device 500 or 600 in the aforementioned game can be implemented entirely or partially through software, hardware, or a combination thereof. These units can be embedded in or independent of the processor in the electronic device in hardware form, or stored in the memory of the electronic device in software form, so that the processor can call and execute the operations corresponding to each unit.

[0290] The virtual character control device 500 or 600 in the game can be integrated into a terminal or server that has storage and a processor and thus computing power, or the virtual character control device 500 or 600 in the game can be the terminal or server.

[0291] Optionally, this application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0292] Figure 17 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may be a terminal or a server. Figure 17 As shown, the electronic device 700 includes a processor 701 with one or more processing cores, a memory 702 with one or more computer-readable storage media, and a computer program stored on the memory 702 and executable on the processor. The processor 701 and the memory 702 are electrically connected. Those skilled in the art will understand that the electronic device structure shown in the figures does not constitute a limitation on the electronic device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0293] The processor 701 is the control center of the electronic device 700. It connects various parts of the electronic device 700 through various interfaces and lines. By running or loading software programs and / or modules stored in the memory 702, and calling data stored in the memory 702, it executes various functions of the electronic device 700 and processes data, thereby performing overall processing of the electronic device 700.

[0294] In this embodiment, the processor 701 in the electronic device 700 loads the instructions corresponding to the processes of one or more computer programs into the memory 702 according to the following steps, and the processor 701 runs the computer programs stored in the memory 702 to realize various functions: In response to receiving a role control delegation request sent by a second terminal device, a delegation window pops up on the first graphical user interface; the delegation window includes an agreement control; Respond to the triggering action of the consent control to gain control over the second virtual character.

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

[0296] Optional, such as Figure 17As shown, the electronic device 700 also includes: a display screen 703, a radio frequency circuit 704, an audio circuit 705, an input unit 706, and a power supply 707. The processor 701 is electrically connected to the display screen 703, the radio frequency circuit 704, the audio circuit 705, the input unit 706, and the power supply 707. Those skilled in the art will understand that... Figure 17 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

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

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

[0299] Audio circuitry 705 can be used to provide an audio interface between a user and an electronic device via a speaker and a microphone. Audio circuitry 705 converts received audio data into electrical signals, transmits them to the speaker, and the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuitry 705, converted back into audio data, and then processed by processor 701 before being transmitted via radio frequency circuitry 704 to, for example, another electronic device, or output to memory 702 for further processing. Audio circuitry 705 may also include an earphone jack to facilitate communication between peripheral headphones and electronic devices.

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

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

[0302] although Figure 17 As not shown in the diagram, the electronic device 700 may also include a camera, sensor, wireless fidelity module, Bluetooth module, etc., which will not be described in detail here.

[0303] This application also provides a computer-readable storage medium for storing a computer program. This computer-readable storage medium can be applied to an electronic device, and the computer program causes the electronic device to execute the corresponding flow in the virtual character control method in the game described in this application embodiment; for brevity, further details are omitted here.

[0304] This application also provides a computer program product including computer instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the corresponding flow in the virtual character control method in the game as described in this application embodiment. For simplicity, further details are omitted here.

[0305] This application also provides a computer program that includes computer instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the corresponding flow in the virtual character control method in the game described in this application. For the sake of brevity, further details are omitted here.

[0306] It should be understood that the processor in this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0307] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0308] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0309] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0310] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0311] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0312] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0313] In addition, the functional units in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0314] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer or a server) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0315] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for controlling a virtual character in a game, characterized in that, A first graphical user interface is provided through a first terminal device. The first graphical user interface displays a first scene area of ​​a virtual scene. The first scene area includes a first virtual character controlled and operated by the first terminal device, and a second virtual character of the same faction as the first virtual character is controlled and operated by a second terminal device. The method includes: In response to receiving a role control delegation request sent by the second terminal device, a delegation window pops up on the first graphical user interface; the delegation window includes an agreement control; The system responds to a triggering action on the consent control to gain control over the second virtual character.

2. The method according to claim 1, characterized in that, The managed window also includes permission prompt information, which is used to identify the control permissions of the second virtual character that the first terminal device can obtain and / or the control permissions of the second virtual character that the first terminal device cannot obtain.

3. The method according to claim 2, characterized in that, The first graphical user interface further includes a plurality of first controls for controlling virtual characters. Each first control is bound to a control permission of the virtual character. The permission prompt information includes a first control identifier pattern and / or a second control identifier pattern. The first control identifier pattern is used to indicate the first control in the first graphical user interface that is bound to the control permission of the second virtual character that the first terminal device can obtain. The second control identifier pattern is used to indicate the first control in the first graphical user interface that is bound to the control permission of the second virtual character that the first terminal device cannot obtain.

4. The virtual character control method in a game according to claim 2, characterized in that, The first graphical user interface further includes a plurality of first controls for controlling the virtual character, each of the first controls being bound to a control permission of the virtual character, and the method further includes: In response to the triggering operation of the consent control, the first target control is controlled to be displayed in a first display format to indicate that the second virtual character can be controlled through the first target control; the first target control is the control among the plurality of first controls that is bound to the control permissions of the second virtual character obtained.

5. The virtual character control method in a game according to claim 4, characterized in that, The method further includes: In response to the trigger operation of the consent control, the second target control among the plurality of first controls is controlled to be displayed in a second display format to indicate that the second virtual character cannot be controlled by the second target control; the second target control is a control among the plurality of first controls that is different from the first target control.

6. The virtual character control method in a game according to claim 1, characterized in that, The first graphical user interface further includes a first control for controlling the virtual character, and the method further includes: In response to the trigger operation of the consent control, the target virtual character currently controlled by the first control is switched from the first virtual character to the second virtual character.

7. The virtual character control method in a game according to claim 6, characterized in that, The first virtual character is located in the center area of ​​the first scene area, and the method further includes: When the target virtual character is switched from the first virtual character to the second virtual character, the first graphical user interface is controlled to switch the currently displayed scene area from the first scene area to the second scene area; the second virtual character is located in the center area of ​​the second scene area.

8. The virtual character control method in a game according to claim 7, characterized in that, The method further includes: When the target virtual character is switched from the first virtual character to the second virtual character, the first graphical user interface is controlled to display a target window; the target window is used to display the first scene area.

9. The virtual character control method in a game according to claim 8, characterized in that, The target window includes a switching control for switching the target virtual character, and the method further includes: In response to the triggering operation of the switching control, the target virtual character is switched from the first virtual character to the second virtual character, or from the second virtual character to the first virtual character; Replace the scene area currently displayed in the first graphical user interface with the scene area currently displayed in the target window.

10. The virtual character control method in a game according to claim 1, characterized in that, The first graphical user interface further includes a first control for controlling the virtual character, and the method further includes: In response to the triggering operation of the consent control, both the first virtual character and the second virtual character are identified as the target virtual characters currently controlled by the first control.

11. The virtual character control method in a game according to claim 1, characterized in that, The managed window also includes a rejection control, and the method further includes: The response to the triggering action of the rejection control is to reject the escrow request.

12. The virtual character control method in a game according to claim 1, characterized in that, The managed window is also used to display the character attribute information of the second virtual character.

13. The virtual character control method in a game according to claim 1, characterized in that, The method further includes: In response to a triggering operation that requests to take over control of the second virtual character, a takeover request is sent to the second terminal device, so as to obtain control over the second virtual character when the second terminal device responds with an instruction to agree to the takeover request.

14. The virtual character control method in a game according to claim 1, characterized in that, The method further includes: Upon gaining control over the second virtual character, the first graphical user interface is controlled to display a second control; the second control is used to release control over the second virtual character. In response to a triggering operation on the second control, control permissions on the second virtual character are released.

15. The virtual character control method in a game according to claim 1, characterized in that, The method further includes: In response to receiving a termination request from the second terminal device to stop managing the role control of the second virtual character, the control permissions over the second virtual character are released.

16. A method for controlling a virtual character in a game, characterized in that, A second graphical user interface is provided through a second terminal device. The second graphical user interface displays a second scene area of ​​a virtual scene. The second scene area includes a second virtual character controlled and operated by the second terminal device, and a first virtual character of the same faction as the second virtual character is controlled and operated by the first terminal device. The method includes: A request for the management of the second virtual character's role control is sent to the first terminal device, so that the first terminal device responds to the received management request by popping up a management window including an agreement control on the first graphical user interface provided by the first terminal device, and by responding to a trigger operation for the agreement control, so as to obtain control permissions for the second virtual character.

17. A virtual character control device for a game, characterized in that, A first graphical user interface is provided through a first terminal device. The first graphical user interface displays a first scene area of ​​a virtual scene. The first scene area includes a first virtual character controlled and operated by the first terminal device, and a second virtual character of the same faction as the first virtual character is controlled and operated by a second terminal device. The device includes: A pop-up window module is used to pop up a management window on the first graphical user interface in response to receiving a management request for role control sent by the second terminal device; the management window includes an agreement control; An operation response module is used to respond to a trigger operation on the consent control in order to obtain control permissions for the second virtual character.

18. A virtual character control device for a game, characterized in that, A second graphical user interface is provided through a second terminal device. The second graphical user interface displays a second scene area of ​​a virtual scene. The second scene area includes a second virtual character controlled and operated by the second terminal device. A first virtual character, which is in the same faction as the second virtual character, is controlled and operated by the first terminal device. The device includes: The request sending module is used to send a management request for the role control of the second virtual character to the first terminal device, so that the first terminal device responds to the received management request by popping up a management window including an agreement control on a first graphical user interface provided by the first terminal device, and by responding to a trigger operation for the agreement control to obtain control rights over the second virtual character.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted for loading by a processor to execute the virtual character control method in a game according to any one of claims 1-16.

20. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing a computer program, and the processor executing the virtual character control method in the game according to any one of claims 1-16 by calling the computer program stored in the memory.

21. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the virtual character control method in the game as described in any one of claims 1-16.

Images