Role collaborative interaction method and device, equipment and medium

Abstract

The invention relates to a role cooperative interaction method and device, equipment and a medium. The method comprises the steps that in response to a state switching event, collected by a first role, of an interaction element, an attribute sequence of the interaction element is recorded, and the game state of the first role is switched to a first state from an initial state; when a skill release operation triggered by the first role in the first state is monitored, switching the game state of the first role to a second state, and instantiating a second role in the game scene; determining a game engagement mode during which the first character is in the second state to execute a character control logic of the second character based on the game engagement mode; when the role control logic executed by the second role meets a preset ending condition, the attribute sequence is cleared, and the game state of the first role is correspondingly switched to the initial state. Unification of control efficiency and strategy depth in a multi-role cooperation scene is realized, and efficient utilization of system resources is guaranteed while user interaction experience is optimized.

Description

Technical Field

[0001] This application relates to the field of game interaction technology, and in particular to a method, apparatus, device, and medium for character collaborative interaction. Background Technology

[0002] In today's large-scale open-world role-playing games, to enrich the player's combat experience, game developers often design characters with complex skill mechanics. Different characters often possess multiple states and corresponding skill combinations. Players need to trigger different skill effects through a series of commands to gain an advantage in combat. Traditional game interaction control technology typically uses preset, fixed response patterns when handling such complex characters. Players collect game resources or meet specific conditions to put the character into a certain state and activate corresponding skills. This condition-triggered interaction method can meet basic needs in simple scenarios with a single character. However, in some situations, existing technology still has limitations.

[0003] Traditional game design typically employs a fixed control scheme, where players can only control one of multiple characters or summoned creatures in the current game scene at a time using a single method. This prevents players from flexibly adjusting their control strategies according to changes in the combat environment, leading to frequent switching of control targets in complex battles, increasing the operational burden and reducing interaction efficiency. Furthermore, the limitations of traditional methods stem from their underlying event handling mechanisms. Current technologies usually treat each player action as an independent event, generating fixed responses for each event, lacking comprehensive utilization of action sequences and historical data. Simultaneously, in scenarios involving multi-character collaboration, current technology's state management is relatively simple, unable to dynamically adjust the behavioral logic of collaborating characters. This forces players to resort to numerous redundant operations to achieve the desired effect in combat scenarios requiring precise control and strategic cooperation, thus impacting the smoothness of the user's gameplay.

[0004] Therefore, existing technologies urgently need a role-based collaborative interaction solution that can address the aforementioned shortcomings. Summary of the Invention

[0005] The purpose of this application is to solve the above-mentioned problems by providing a role-based collaborative interaction method and corresponding apparatus, devices, non-volatile readable storage media, and computer program products.

[0006] According to one aspect of this application, a role-based collaborative interaction method is provided, comprising: In response to a state switching event where a first character in its initial state collects a preset number of interactive elements in the game scene, the attribute sequence of the interactive elements associated with the event is recorded, and the game state of the first character is switched from the initial state to the first state. When a skill casting operation triggered by the first character in the first state is detected, the game state of the first character is switched to the second state, and a second character is instantiated in the game scene. The game participation mode of the first character during the second state is determined, and the character control logic of the second character is executed accordingly based on the game participation mode. When the second character's execution of the character control logic meets a preset termination condition, the attribute sequence is cleared, and the game state of the first character is switched back to the initial state.

[0007] According to another aspect of this application, a role-cooperative interaction device is provided, comprising: An event response module is configured to respond to a state switching event in which a first character in its initial state collects a preset number of interactive elements in the game scene, record the attribute sequence of the interactive elements associated with the event, and switch the game state of the first character from the initial state to the first state. A collaborative triggering module is configured to switch the game state of the first character to the second state and instantiate a second character in the game scene when a skill casting operation triggered by the first character in the first state is detected. A character control module is configured to determine the game participation mode of the first character during the second state and execute the character control logic of the second character accordingly based on the game participation mode. A state recovery module is configured to clear the attribute sequence when the second character executes the character control logic and meets a preset termination condition, and switch the game state of the first character back to the initial state accordingly.

[0008] According to another aspect of this application, a role-cooperative interaction device is provided, including a central processing unit and a memory, wherein the central processing unit is used to invoke and run a computer program stored in the memory to perform the steps of the method described in this application.

[0009] According to another aspect of this application, a non-volatile readable storage medium is provided, which stores a computer program implemented according to the described role-based collaborative interaction method in the form of computer-readable instructions, wherein the computer program, when invoked by a computer, executes the steps included in the method.

[0010] According to another aspect of this application, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the method.

[0011] First, this application optimizes the user experience in multi-character collaborative scenarios by introducing differentiated control logic based on game participation modes. In traditional game interaction design, players can only control multiple characters or summoned creatures in the current scene in a single way at the same time. This fixed control mode forces players to frequently switch operation targets in complex combat scenarios, which not only increases the operational burden but also reduces interaction efficiency. The technical solution of this application executes the character control logic of the second character according to the game participation mode of the first character during the second state, allowing players to flexibly choose different collaborative control methods according to the current combat scenario and strategic needs. This dynamic adjustment mechanism based on participation modes avoids redundant operation switching and effectively improves the smoothness and efficiency of game interaction. Second, this application achieves refined control of character behavior by comprehensively utilizing operation sequences and historical data. Traditional technologies usually treat each player operation as an independent event and generate a fixed response for each event, lacking comprehensive utilization of operation sequences and historical data. This forces players to use a large number of redundant operations to achieve the expected results when facing combat scenarios that require precise control. This application records the attribute sequence of interactive elements associated with state transition events and executes corresponding control logic based on this attribute sequence in subsequent character control. This allows the behavior of the second character to be associated with the historical operation sequence of the first character. This data processing mechanism based on operation history makes the collaborative interaction of characters more in-depth and strategic, avoiding the problem of low interaction efficiency caused by an overly simplistic event response mechanism. Simultaneously, this application solves the problem of overly simplistic state management in traditional technologies for multi-character collaborative scenarios through a refined state management mechanism. Existing technologies typically employ only simple state management methods in scenarios involving multi-character collaboration, failing to dynamically adjust the behavioral logic of collaborative characters based on the player's participation state. This results in players struggling to achieve ideal interactive effects in combat scenarios requiring strategic cooperation. This application, however, achieves refined management and automated flow of character states by orderly switching the first character's game state between the initial state, the first state, and the second state, and clearing the attribute sequence and returning to the initial state based on preset termination conditions. This state management mechanism allows the behavioral logic of collaborative characters to dynamically adapt to the player's participation state, ensuring interactive flexibility while also improving the resource utilization efficiency and operational stability of the game system. Attached Figure Description

[0012] Figure 1 This application provides an exemplary network architecture; Figure 2 This is a flowchart illustrating one embodiment of the role-based collaborative interaction method of this application; Figure 3 This is a schematic diagram of the role-based collaborative interaction device of this application; Figure 4 This is a schematic diagram of the structure of a role-based collaborative interaction device used in this application. Detailed Implementation

[0013] The technical solution presented in this application can be widely deployed in computing architectures that support large-scale interactive virtual worlds. In a typical implementation environment, such as... Figure 1 As shown, the player's client electronic device 80 connects to a service cluster 81 consisting of multiple server nodes via a network. The client electronic device 80 is primarily responsible for player interaction and local presentation processing. A computer program implementing the character collaborative interaction method of this application runs on the electronic device 80. This program can render game scenes, generate graphical user interfaces, and receive local input operations from the player. When the player controls the first character to collect interactive elements or trigger skill releases in the game scene, the client electronic device 80 monitors these operation commands and updates the first character's game state in real time. It also generates corresponding action control signals based on the first character's game participation mode to drive the second character to perform corresponding actions. Simultaneously, the client electronic device 80 manages the storage and release of the first character's attribute sequence in local memory and drives the second character's animation state machine to achieve specific animation performances. The service cluster 81 is primarily responsible for global state management and data synchronization between multiple users. The service cluster 81 can adopt a distributed or microservice architecture, where different service instances can be responsible for the core logic and global state management of the virtual environment, respectively. Furthermore, service cluster 81 centrally manages the character status data, attribute sequences of interactive elements, and instantiation information of the second character reported by different clients, forming a unified data resource library. When a state switching event triggered by client reporting or server logic is detected, service cluster 81 determines the state data to be synchronized according to preset logic and sends it to the relevant client electronic devices 80. In addition, service cluster 81 is also responsible for coordinating the state synchronization of virtual characters among multiple clients, ensuring that in a distributed environment, especially when the first character is in a non-participation mode, events in which other game characters perform preset types of actions can be accurately captured and trigger the corresponding response of the second character, thereby ensuring the consistency of game performance in multi-player scenarios.

[0014] This application can be deployed in various large-scale multiplayer online role-playing game systems based on a client-server architecture, and is also suitable for single-player game environments that support complex character interactions. In a typical implementation architecture, the game system can be operated collaboratively by a game client and a game server. The client is mainly responsible for receiving player input commands, rendering game scenes, and processing local character states and animations, while the server coordinates and manages global game state data, real-time synchronization between multiple players, and authoritative calculation of core combat logic. When a player controls a character to perform a specific operation in the game scene, the client will trigger the corresponding character state transition and skill response process based on the input event. The corresponding process may include the game engine monitoring the character state, capturing interactive events, instantiating virtual characters, and the collaborative processing of the animation system.

[0015] In one exemplary implementation of this application, game characters in a virtual environment achieve orderly switching between different game states through a state machine mechanism. The state data associated with the first character can be stored in the client's memory as runtime data. This data management method allows the character's state transitions and historical operation records to participate in the calculation of subsequent control logic in real time. When the player causes the first character to collect a preset number of interactive elements through operations, the game system captures this state transition event through an event listening mechanism and synchronously records the attribute sequence of the collected interactive elements. This attribute sequence is persistently stored in the memory space of the current session as the first character's historical operation data, providing a data foundation for the subsequent behavior of the second character. After the second character is instantiated, the game system dynamically allocates control permissions according to the first character's game participation mode and responds to the player's operation commands or the action events of other characters in the game scene through an event-driven mechanism, thereby driving the second character to execute the corresponding action sequence.

[0016] As one interpretation of the fundamental concepts involved in this application, character state machine management can refer to the standardized management of a character's behavioral permissions and performance characteristics at different game stages through a finite state machine model, ensuring that the character can respond to corresponding operation commands and produce expected behavioral outputs in different states; event-driven interactive response mechanism can refer to the system listening to player operation events or action events triggered by other characters in the game, generating corresponding control signals according to predefined response logic to achieve real-time control of virtual characters; behavior control of instantiated objects can refer to assigning independent behavioral logic to dynamically generated virtual characters, enabling them to execute preset actions or respond to external commands according to the needs of the current scene; dynamic performance generation based on historical data can refer to the system inputting previously recorded operation sequences as parameters into subsequent behavior generation logic, so that the virtual character's action performance can be associated with the character's historical operations, thereby presenting a more coherent and strategic interactive effect, which together constitute an implementation basis for the technical solution of this application.

[0017] In a typical game scenario, after a player-controlled character enters a combat area, the game screen displays the character's basic status information, including health, energy, and currently available skill icons. At this point, the character is in a normal combat state, and the player can use input devices to control the character's movement, jumping, or casting basic attack skills to interact with enemy characters in the environment. When the player successfully collects a certain number of specific interactive elements in the game environment, these elements can manifest as collectible items scattered throughout the scene, with corresponding collection effects displayed on the screen each time they are picked up, and a progress indicator showing the current number collected appearing near the character's status bar; alternatively, they can be accumulated through certain skill casting actions within the game environment. When the collection reaches a preset requirement, a previously inactive skill icon on the game screen will change its display status, for example, from gray to highlighted or gaining special lighting effects. Simultaneously, a brief effect change may occur around the character, indicating that the character has entered a new preparation state. The player can then choose whether to trigger the skill. If the player does not trigger it, the character will remain in the current preparation state, and the collected interactive elements and their related information will be temporarily stored.

[0018] When a player activates a skill and presses the corresponding skill button, the game screen displays a unique animation of the character casting the skill. A system-controlled combat partner then spawns near the character. This combat partner's appearance may differ slightly from the character's, and it will float around the character or move with them after spawning. The character's status bar will update again, indicating that the character has entered a special cooperative combat state. The original skill icons may change again, or new operation prompts may appear. In cooperative combat state, the game determines the combat partner's behavior based on whether the player continues to control the current character. If the player continues to control the current character, the game screen will display operation commands for the current character, which will also affect the combat partner's prompts. For example, additional icons may appear near the basic attack, dodge, or jump buttons, indicating that these actions can now be simultaneously commanded by the combat partner. When the player clicks the basic attack button, the current character will perform a basic attack, and the combat partner will simultaneously perform its corresponding attack action. After a combat partner performs two consecutive basic attacks, their third attack will automatically become a more spectacular enhanced attack. At this time, the screen will display special effects related to the attributes of the previously collected interactive elements. For example, depending on the collection order, the enhanced attack may come with different control effects, such as briefly stunning enemy characters or pulling them towards the center.

[0019] If the player chooses to switch to another character in the team for combat, the current character will remain in the background. At this time, the combat partner's behavior will automatically switch. In the background state, the combat partner will continuously and automatically attack nearby enemy characters. Its attack frequency and performance are controlled by preset logic. When the player-controlled character uses a specific type of skill, the combat partner will immediately respond and unleash an enhanced attack. The screen will display the same attribute-related effects as before, possibly accompanied by a brief camera shake or time slowdown effect to emphasize the visual impact of this coordinated attack. During the coordinated combat state, the player can manually end the state at any time through specific actions, such as long-pressing a skill button or pressing the summon skill button again. When the state ends, the screen will display a finishing animation of the character or combat partner, dealing area damage to surrounding enemy characters. Afterward, the combat partner will disappear from the scene, the character's state will return to the normal combat state, the previously collected information on interactive elements will be cleared, and the skill icons will also return to their initial inactive state. If the cooperative combat state ends naturally due to other conditions, such as the duration reaching the limit or the player character being knocked down, the state clearing process will also be executed to ensure that the complete interactive process can be restarted the next time the state is entered.

[0020] After providing a general overview of the exemplary network architecture and application scenarios of this application, as well as some basic concepts, the following will continue to describe several specific embodiments of this application.

[0021] Please see Figure 2 The role-based collaborative interaction method of this application, in some embodiments, includes the following steps: Step S3100: In response to the state switching event of the first character in the initial state collecting a preset number of interactive elements in the game scene, record the attribute sequence of the interactive elements associated with the event, and switch the game state of the first character from the initial state to the first state.

[0022] In the game system deployed by the technical solution of this application, players can control a first character to explore and fight in the game scene through a client electronic device. The client electronic device is responsible for receiving player input commands, rendering game screens, and updating character status in real time, while maintaining data synchronization with the service cluster via the network. The service cluster adopts a distributed architecture and centrally manages the global state data of the game world, including character attribute information, the distribution and location of interactive elements in the scene, and state synchronization between multiple players. When a player controls the first character to enter a specific area or triggers a specific event, the character collaborative interaction method of this application is executed.

[0023] At the start of the game, the first character is in an initial state, possessing basic movement, attack, and jumping abilities. Multiple interactive elements can be pre-configured in the game scene, and these elements can be presented in different forms according to the game design requirements. Interactive elements can appear as floating points of light in the scene, with fixed locations or dynamically generated when the character approaches; they can also appear as fragments dropped after defeating specific enemies; or they can appear as counters generated when the character hits enemies consecutively. Players control the first character to interact with or collect these interactive elements. Each successful collection records the attribute identifier corresponding to the interactive element and generates an attribute sequence according to the collection order. When the number of collected interactive elements reaches a preset threshold, the system triggers a state transition event.

[0024] When the player-controlled first character is in the initial state, they can freely explore the game scene and interact with various elements within it. The initial state is the normal state before the character enters any special preparation phase, and in this state, the first character's skill system primarily consists of basic operation commands. While moving through the game scene, the first character can collect interactive elements in various ways. These interactive elements are collectible objects scattered throughout the game scene or generated through specific actions. Depending on the game's theme and art style, they can be represented as musical note-shaped light spots floating in the air, displaying different colors such as red, purple, or rainbow depending on their origin or attributes. Interactive elements can also appear as fragments or crystals dropped after defeating enemies, counters generated around the character after completing specific combos, or interactive points located in specific locations within the scene. The first character automatically completes one of these collection tasks upon approaching them.

[0025] The process of the first character collecting interactive elements is continuously monitored by the game system. Each time the first character successfully collects an interactive element, its attribute identifier is recorded. Attribute identifiers are numeric or character labels that distinguish different types of interactive elements. These attribute identifiers are stored sequentially in an ordered list, which is the attribute sequence. The data structure of the attribute sequence can be implemented using an array, linked list, or queue. Its core characteristic is maintaining the sequential relationship between elements. Each position in the attribute sequence corresponds to one collection action, and the length of the sequence is the number of interactive elements currently collected.

[0026] When the first character collects a preset number of interactive elements, the state transition condition is met. This preset number is a fixed value, such as six, determined during the game design phase. The game system internally records the collected number in real time using a counter. After each collection operation, the count is compared to the preset number. When the count reaches the preset number, a state transition event is generated. This event can be an internal signal indicating that the first character has met the necessary conditions to enter the next stage, triggering subsequent data processing and state update procedures.

[0027] In response to this state transition event, the game system permanently stores the recorded attribute sequence, making it a data resource that can be called upon in subsequent processes. At this point, the attribute sequence will no longer change with subsequent operations, and each attribute identifier and its order are locked. Furthermore, the game system switches the first character's game state from the initial state to the first state. The first state is an intermediate transitional state relative to the initial state, and its specific manifestation varies in different embodiments.

[0028] In one embodiment, the first state is characterized by a continuous glowing effect around the first character, while a previously grayed-out skill icon becomes highlighted. In another embodiment, the first state is characterized by a change in the first character's animation module, adding a new executable preparation action. In yet another embodiment, the first state is characterized by the appearance of prompt text or a progress indicator on the game interface, informing the player that the conditions for using a special skill have been met.

[0029] After the first character enters the first state, they can still perform basic actions such as movement and attack. However, at this time, the first character has additional access to trigger specific skills. The first state can last for a preset time window, such as thirty seconds. If the player does not trigger any subsequent actions within the time window, the first character will automatically exit the first state and return to the initial state, and the recorded attribute sequence will be cleared. If the player triggers a specific action within the time window, the subsequent state transition logic will continue. The attribute sequence is retained as key data at this time to determine the specific performance effect when the second character performs enhancement actions. For example, if the first attribute in the attribute sequence is red, the subsequent enhancement action will have a stagnation effect; if the first attribute in the attribute sequence is purple, the subsequent enhancement action will have a traction effect; if the first attribute in the attribute sequence is colored, the subsequent enhancement action will have both stagnation and traction effects. Furthermore, other attribute markers in subsequent positions of the attribute sequence will take effect in subsequent enhancement actions, thus realizing the impact of the player's collection order on combat performance.

[0030] Step S3200: When a skill casting operation triggered by the first character in the first state is detected, the game state of the first character is switched to the second state, and the second character is instantiated in the game scene.

[0031] After the first character switches from the initial state to the first state and records the attribute sequence, the game system enters the stage of waiting for the player to trigger subsequent operations. At this time, the first character is in the first state. The character in this state presents characteristics on the game screen that are different from the initial state, such as skill icons being highlighted, special light effects surrounding the character, or prompt text appearing on the interface to inform the player that the conditions for casting a specific skill have been met. At this time, the system continuously monitors the player's input commands to determine whether the operation to cast that specific skill has been triggered.

[0032] In this embodiment, a skill casting operation refers to a specific instruction issued by the player through an input device. This instruction directs the first character to execute a preset core skill. The specific implementation of the skill casting operation depends on the game platform and interaction design. It can manifest as the player pressing a specific key on the keyboard, pressing a combination key on the game controller, clicking a highlighted skill icon in the graphical user interface on the touchscreen, or performing a specific gesture or voice command, such as making a designated action on a device that supports motion control. By capturing this operation through an event listening mechanism, the skill casting operation can be identified. When a skill casting operation is detected to be triggered, the game state of the first character can be switched from a first state to a second state, and a second character can be instantiated in the game scene. These two processes can be executed in parallel or sequentially.

[0033] The transition from the first state to the second state signifies that the character has moved from the preparation phase to the formal cooperative combat phase. The second state can be configured to differ from the first state in terms of gameplay. In one embodiment, the first character's action module changes in the second state, for example, switching from a standing posture to a floating posture, or having enhanced ambient effects. In another embodiment, the first character's skill icon set changes in the second state, with the original skill icons being replaced by new ones to reflect the available operation commands in the current state. In yet another embodiment, the first character's position or movement method changes in the second state; for example, the character can hover in the air or gain new movement abilities. Thus, entering the second state also means that the character's subsequent behavioral logic will follow a new set of rules; for example, the game system can begin executing the cooperative control logic for the second character.

[0034] Instantiating a second character refers to dynamically creating and displaying a computer-controlled virtual character entity in the three-dimensional space of the game scene. The second character can be a separate game character, or it can appear as a combat partner or summoned creature of the first character. Its appearance and attributes can be related to the first character but also have certain differences. During the instantiation process, the second character's 3D model, textures, animation data, and related sound effects resources are first loaded from the resource manager. After loading, the initial position of the second character is determined in the scene. The initial position of the second character can be set at a specified offset coordinate next to the first character, such as floating above and to the right, or it can be set near the nearest enemy character to the first character, or it can be automatically calculated by the game system based on the current combat scene, such as selecting an open location that will not collide with the scene terrain. After the second character is instantiated, it can appear in the game screen as a visible entity and begin to participate in the physical simulation and interaction logic of the game world.

[0035] In one implementation, the second character acts as an independent game entity, possessing its own attribute data and behavioral logic. Its attribute data can inherit some attributes from the first character, such as attack and defense, or it can have independent attribute configurations. For example, the second character's attack power could be set to 120% of the first character's attack power, and its health could be set to infinite, meaning it cannot be destroyed by attacks. After instantiation, the second character will be in a standby state or perform a preset entrance action. Subsequent behavioral logic will be differentiated based on the first character's game participation mode. The technical implementation of instantiating the second character can utilize the object instantiation interface provided by the game engine, such as creating a preset object in the Unity engine or generating a character instance in the Unreal Engine. During instantiation, a unique identifier needs to be assigned to the second character and added to the scene manager for subsequent collision detection, rendering updates, and network synchronization. In multiplayer online games, the instantiation of the second character can be synchronized to the server and broadcast to other clients to ensure that all players see a consistent game world state.

[0036] Thus, once the skill casting operation is triggered, the first character enters the second state, and the second character is instantiated and appears in the scene. At this point, the first and second characters can coexist in the game world. The state change of the first character and the generation of the second character together constitute the turning point from the preparation phase to the execution phase. Players can observe the action effects of skill casting and the appearance of summoned creatures on the screen and receive immediate visual feedback. Meanwhile, the state management module inside the game system updates the state flag of the first character and stores the instance reference of the second character in the context of the current session so that the subsequent control logic can accurately address and control the character.

[0037] Step S3300: Determine the game participation mode of the first character during the second state, and execute the character control logic of the second character based on the game participation mode.

[0038] During the duration of the second state, the game system needs to determine the actual participation status of the first character in the current game scene. This status determines the behavioral rules that the second character should follow. The first character's game participation mode is essentially a state identifier used to distinguish whether the first character is in a foreground state directly controlled by the player or in a standby state in the background of the team. This determination process depends on the underlying architecture of the game team system. For example, in a multi-character team system, usually only one character is currently on the field and directly controlled by the player at any given time, while other characters are in the background and execute simplified automatic logic. This information can be obtained by querying the character index of the current team or monitoring the allocation of player input focus. For example, when the player has just transferred control to another character in the team through a character switching operation, the first character changes from the on-field participation mode to the off-field participation mode.

[0039] Determining the game participation mode is a continuously monitored and dynamic process. In one implementation, a mode determination is performed at the start of the second state, and this mode serves as the control benchmark for the entire second state. In another implementation, character switching events are continuously monitored during the second state, and the real-time participation status of the first character is retrieved and the mode identifier is updated whenever the player presses the character switching button or forcibly switches characters using a specific skill. A third implementation employs a timed polling mechanism, checking the participation status of the first character every frame or at fixed time intervals to ensure that the control logic can respond promptly to character switching operations. Regardless of the monitoring method used, a clear mode identifier can ultimately be obtained, which serves as the basis for subsequent branch selection in the control logic.

[0040] In this embodiment, executing the second character's control logic based on the determined game participation mode means that the system selects the corresponding scheme from multiple preset control schemes according to the mode identifier and applies it to the second character's behavior management. The difference in control logic can be reflected in the source of the second character's received instructions and the triggering mechanism for action execution. In one embodiment, the second character's control logic is driven by the player's real-time operation commands. A mapping relationship is established between the first character's input and the second character's action response. When the player clicks the basic attack button, the first character performs the basic attack action while simultaneously generating a corresponding control signal and sending it to the second character's instantiated object, driving it to execute a specific action associated with it. During this process, the second character's behavior remains synchronized with the player's operation rhythm, forming a visual feedback of coordinated combat. In another embodiment, the second character's control logic switches to an automatic response-based driving mode. In this case, the player no longer directly controls the first character, and therefore the first character's operation commands are no longer used as the source of instructions for the second character. Instead, a preset automatic combat logic is enabled. In this mode, the second character automatically executes basic attack actions according to the system-set cycle, without requiring additional input from the player. At the same time, the game system continuously monitors the actions and events performed by other characters in the game scene, especially those specific skill types that are preset to trigger synergy effects. When it detects that another character has released a skill that meets the preset conditions, it immediately interrupts the automatic attack cycle of the second character and generates a trigger command to drive it to execute an enhanced attack action. This allows the second character to still form combat cooperation with the currently active characters in the team even in the background.

[0041] In one implementation, the execution of the control logic relies on the attribute sequence of interactive elements associated with state transition events. This attribute sequence serves as data input and plays a decisive role when an enhancement action is triggered. When the second character is about to execute an enhancement action, the attribute identifier at the current effective position is read from the attribute sequence. Based on this identifier, the specific effect of the enhancement action can be determined. For example, when the attribute identifier is red, the enhancement action causes the enemy character to freeze; when the attribute identifier is purple, the enhancement action pulls the enemy character towards the center; when the attribute identifier is colored, the enhancement action has both freezing and pulling effects. The consumption order of the attribute sequence is consistent with the collection order. Each enhancement action consumes one attribute identifier until the entire sequence is consumed. This ensures that regardless of whether the player chooses to control the first character throughout the battle or switches to another character, the order in which the player collects interactive elements in the early stages will have a substantial impact on subsequent cooperative battles.

[0042] Step S3400: When the second character executes the character control logic and meets the preset termination condition, the attribute sequence is cleared, and the game state of the first character is switched to the initial state accordingly.

[0043] After the second character runs according to the predetermined character control logic for a period of time, the game system needs to determine whether this cooperative combat phase should be terminated. Upon termination, the system performs corresponding data cleanup and state reset operations, thus forming a complete closed loop for the entire character cooperative interaction method. The first character starts from the initial state, goes through the first state and the second state, and finally returns to the initial state, preparing for the next cooperative combat session. In this application, the preset termination condition refers to one or more logical rules set internally by the system to determine whether the second state should terminate. These rules can be set based on various factors, from the simplest duration to complex counting conditions, all of which can serve as the basis for determining the termination condition. The termination condition can be set to a fixed time length, such as automatically triggering the termination judgment after 24 seconds from the start of the second state; it can also be set to the number of times the second character performs enhanced actions, such as triggering the termination judgment after the second character completes 10 enhanced attacks; or it can be set to a specific operation triggered by the player, such as the player pressing the button to prematurely end a skill, or the player switching the first character to the background and then switching it back to the foreground. Furthermore, the ending condition is set as either the first or second character receiving fatal damage, such as the first character's health reaching zero or the second character being eliminated by the enemy, or the second character's attribute sequence being completely consumed, meaning all attribute markers in the sequence have been used to enhance actions. In actual game design, these conditions can be used individually or in combination; for example, a 24-second duration can be set while also allowing players to manually end the game early.

[0044] During the second state, the game system continuously monitors whether these termination conditions are met. The monitoring method depends on the specific type of condition. For time-related conditions, a timer can be started, updating the remaining time every second or every frame. When the timer reaches zero, the condition is considered met. For count-related conditions, a counter is maintained, updating the count each time the second character performs a specific action. When the count reaches a preset threshold, the condition is considered met. For operation-related conditions, an event listener for the corresponding input event is registered. When the player presses a specified key, the judgment is triggered. Once any preset condition is detected to be met, the termination process is immediately initiated.

[0045] The first task at the end of the processing flow is to clear the attribute sequence. The attribute sequence is a data resource recorded and continuously stored in memory. It is used throughout the second state to determine the performance effect of enhanced actions. When the second state is about to end, the sequence no longer has any value, so a cleanup operation is performed to release the memory resources it occupies. The specific implementation of clearing the attribute sequence depends on the game engine's data management mechanism. It can directly delete the array object storing the attribute sequence, marking its occupied memory as reclaimable; it can also call a function to clear the array contents, setting the array length to zero and releasing the references occupied by each element; or it can set the attribute sequence reference to null, waiting for the garbage collection mechanism to automatically reclaim it. Clearing the attribute sequence has a dual significance: from a data management perspective, it promptly releases memory resources that are no longer needed, preventing memory leaks; from a game logic perspective, it ensures that the first character can start recording a new attribute sequence the next time it enters the first state, without confusion with the residual data from the previous state. The second task in the process is to switch the first character's game state back to its initial state. This state rollback operation marks the official end of the entire cooperative combat phase. After switching back to the initial state, the first character reverts to its most basic normal state, with its executable skill system, visual characteristics, and operational permissions all returning to their default settings. In one implementation, the special effects around the first character in the initial state disappear, skill icons return to gray, and the animation module switches back to normal mode. In another implementation, the first character in the initial state falls back to the ground from its hovering state, and its movement method reverts to normal running and jumping. In a third implementation, the status bar information for the first character in the initial state is updated, informing the player that they have exited the special state.

[0046] In this implementation, the second character is removed from the game scene simultaneously with the state transition. The instantiated object of the second character is destroyed when the termination condition is met, releasing its occupied resources such as models, textures, and animations, and disappearing from the screen. This process corresponds to the instantiation process of the second character, ensuring that no uncontrolled summoned creatures are left in the game world. Before disappearing, the second character can perform a finishing move, such as playing a dissipation animation or emitting a long howl, and then gradually fading out of the screen. Alternatively, the second character can deal area damage to surrounding enemy characters as a final contribution before leaving the game. The visual effect of this finishing damage can be associated with an attribute sequence; for example, the damage effect type can be determined based on the last attribute identifier in the sequence, or a uniform default effect can be used.

[0047] In one implementation, there is a clear temporal relationship between the operations of clearing the attribute sequence and switching back to the initial state. The clearing of the attribute sequence must be completed before or simultaneously with the state switch to ensure that the first character does not carry any residual data from the previous round when entering the initial state. If the state switch is performed before the sequence is cleared, there may be an abnormal situation where the first character in the initial state still has the attribute sequence, leading to data corruption when entering the first state again. Therefore, game systems typically implement the clearing operation as a pre-step for state switching, first generating a state reset instruction, which includes two sub-tasks: clearing the sequence and reverting to the state, executed sequentially. This design of the end-processing flow reflects the game system's emphasis on resource management and state consistency. The timely release of the attribute sequence avoids the invalid occupation of memory resources, the state reversion ensures that the first character can face the next challenge in a clean state, and the removal of the second character maintains a reasonable control of the number of entities in the game world. Thus, through this finishing step, the character cooperative interaction method of this application forms a repeatable closed-loop process. Players can restart collecting interactive elements, summoning the second character, and experiencing cooperative combat after a battle. The entire process is smooth and will not affect the game experience due to data residue or state corruption.

[0048] As demonstrated by the above embodiments, this application achieves refined control of game characters in multi-state transitions and cooperative combat scenarios. By recording the attribute sequence of interactive elements, the player's collection order is transformed into data resources that can be subsequently called upon, allowing the player's operation history to have a substantial impact on subsequent combat performance, thereby enhancing the strategic depth of game interaction. Switching character states and instantiating a second character based on skill casting operations transforms a single button press by the player into the appearance of a physical character in the game world, enabling instantaneous response from command input to visual feedback. Furthermore, the control logic of the second character is automatically adapted to the real-time participation mode of the first character. Whether it's manual command mapping when the player controls the first character or automatic event response when the first character is in the background, the second character can cooperate in a manner appropriate to the current scenario. Players can obtain a smooth multi-character cooperative experience without manually switching control modes. Finally, by triggering the clearing of attribute sequences and the reset of states through preset termination conditions, memory resources are promptly released, ensuring that the first character is in a clean state for the next cooperative combat, thus avoiding logical chaos caused by data residue. The entire process organically combines player operation, state management, entity control, and resource recycling, improving interaction efficiency while ensuring the operational stability of the game system.

[0049] Based on any embodiment of the method in this application, determining the game participation mode of the first character during the second state, and executing the character control logic of the second character based on the game participation mode, includes: Step S3110: When the first character is in the participation mode, in response to the operation command for the first character, the action signal generated based on the command controls the second character to perform the first action.

[0050] When a player chooses to keep their primary character on the field and control them in combat, the game system can activate a real-time mapping mechanism driven solely by player commands. In this mode, the primary character acts as the interaction bridge between the player and the secondary character; every action the player takes is simultaneously transmitted to the secondary character. When the player presses the basic attack button, the system first checks if an active secondary character instance exists. If so, instead of simply having the primary character play an attack animation, a specific action control signal for the secondary character is generated. The generation rules for this signal depend on a pre-established command mapping table. For example, clicking the basic attack button is mapped to the secondary character's basic attack; holding down the basic attack button is mapped to the secondary character's charged attack; clicking the dodge button is mapped to the secondary character's movement evasion; and clicking the basic attack button twice consecutively may be recognized as a special command. This mapping relationship can be static and fixed, requiring the player to learn the corresponding synergistic effects of specific commands. Alternatively, the mapping relationship can be dynamically adjusted based on the secondary character's current state. For instance, when the secondary character is in a strengthened state, the original basic attack mapping will temporarily be replaced with a stronger attack form.

[0051] After the action signal is generated, it can be sent to the instantiated object of the second character via the game engine's message system or direct function calls. Upon receiving the signal, the second character immediately executes the corresponding action sequence, including playing animations, triggering attack judgments, and generating special effects. The entire process can be completed within a single frame, making the player feel as if they are controlling two characters simultaneously. In some online games, this process also needs to consider latency compensation. The client sends operation commands to the server, and the server synchronously forwards them to other clients to ensure that all players see consistent coordinated actions.

[0052] Step S3120: When the second character has accumulated the execution of the first action until the preset action execution condition is met, the next action to be executed by the second character is replaced with the second action, wherein the visual effect of the second action is determined according to the attribute sequence.

[0053] While the player controls the second character to perform the first action via commands, the game system continuously tracks a key statistic in the background: the cumulative number of times the second character has performed the first action. This cumulative count forms a dynamic monitoring mechanism; each time the second character completes a full first action, the current count is compared with the preset action execution conditions.

[0054] In this implementation, the action execution condition is a threshold parameter, representing the basic number of attacks required to trigger the enhanced attack. In a common configuration, this threshold is set to two, meaning that for every two normal attacks the second character completes, the third attack will automatically upgrade. This threshold can be configured during development based on game balance requirements, or it can be dynamically adjusted by the server during runtime. When the cumulative number of attacks reaches the preset threshold, the game system can not immediately have the second character execute the second action, but instead perform a replacement operation: replacing the entire instruction content of the next first action that the second character is about to execute with the instruction content of the second action. This replacement operation is implemented by replacing the next normal action entry to be executed in the second character's action queue with an enhanced action entry. The replaced second action is not a fixed skill; its visual effect is then determined by the previously recorded attribute sequence.

[0055] The attribute sequence remains ready after activation. When a second action is about to be executed, it retrieves the attribute identifier at the currently pointed-to position from the attribute sequence. This identifier determines the visual effect of the second action. For example, if the attribute identifier contains color information, the second action's special effects will display the corresponding color; if the attribute identifier contains shape information, the animation skeleton of the second action will adjust to the corresponding attack stance. In one implementation, the attribute sequence pointer is automatically moved forward one position after each second action is executed, ensuring that the next second action uses the next attribute identifier. Once the attribute sequence is exhausted, the system can choose to continue executing the second action with the default effect, or pause triggering until a new attribute sequence is generated, depending on the design.

[0056] Step S3130: When the first character is in the non-participation mode, the second character is driven to perform the first action based on the preset character logic. When the game character currently in the game scene performs a preset type action, the next action of the second character is replaced with the second action.

[0057] When a player switches control from the primary character to another character in the team, the primary character, while still present in the game scene, no longer receives direct commands from the player. At this point, the control logic of the secondary character switches to a completely different operating mechanism. The core of this mechanism is to allow the secondary character to continue participating in the battle even without player input, while maintaining potential synergy with the currently active characters on the field.

[0058] Character logic serves as the foundation for driving the automatic operation of a second character. This logic is essentially a set of built-in behavioral rules that dictate how the second character should act when idle. The most common implementation involves starting a separate action loop thread or coroutine, allowing the second character to automatically execute the first action at fixed time intervals. For example, it could be set to perform a normal attack every two seconds, with the default target being the enemy currently locked onto by the first character. If the first character has no target locked, it would choose the nearest enemy. In more complex implementations, character logic can include simple tactical judgments, such as prioritizing a certain attack method when an enemy enters a specific range, or switching attack targets when multiple enemies are nearby.

[0059] However, simply allowing the second character to attack automatically is insufficient to demonstrate the synergy effect. Therefore, this embodiment includes a more crucial triggering rule: when the game character currently in the game scene performs a preset type of action, the behavior of the second character will be temporarily intervened. The game character currently in the game scene can be a new foreground character after the player switches, another member of the team, or even a character controlled by another player. The type of action refers to a specific skill type marked by the system as capable of triggering a synergy effect, such as vocal skills, ultimate skills, or certain special attacks. By continuously monitoring the execution events of these actions in the background, the automatic action loop of the second character is immediately interrupted once a matching event is detected.

[0060] After an interruption occurs, the game system performs operations similar to the replacement logic in the participation mode, replacing the second character's next automatic action with the second action. However, the replacement mechanism here has subtle differences. The second character might be in the interval between two automatic actions or in the recovery phase of the previous action. Therefore, it's necessary to decide whether to execute the second action immediately or wait for the current action to finish, depending on the current state. A priority preemption strategy can be used: regardless of the second character's state, as soon as a trigger event is detected, the current action is forcibly canceled and the second action's animation is immediately played. Alternatively, a queue insertion strategy can be used, inserting the second action at the front of the action queue and executing it immediately after the current action completes. Thus, even when controlling other characters, players can still command the background second character to unleash enhanced attacks by releasing specific skills. Players can enjoy multi-character cooperation without switching back to their first character, while the second character's automatic attacks continuously output damage, creating a dual-output combat rhythm both on and off the field. Attribute sequences also play a role in this mode; each time the second action is triggered, an attribute token is consumed sequentially to determine the second action's effect, ensuring that the interactive elements collected by the player on the first character remain valuable even in the background.

[0061] Through the above-described embodiments, the present application achieves the unity of manipulation efficiency and strategy depth in the multi-role collaboration scenario. The appearance participation mode converts a single input into a dual response, enabling players to obtain a combat experience of multi-role linkage without switching the operation target, thereby reducing the operation burden in complex scenarios. The rule design of triggering the second action by accumulating the execution of the first action, combined with the decisive effect of the attribute sequence on the performance effect of the second action, makes each ordinary operation of the player a cumulative process leading to a strengthened attack, and the order selection during the collection of interaction elements is thus transformed into a visible differential effect in combat. The non-appearance participation mode ensures the continuous output ability of the background character, and at the same time triggers the second action by monitoring the event that other characters execute preset type actions, enabling players to indirectly command the second character to perform a strengthened attack even when manipulating other characters, allowing players to freely switch the foreground character without losing collaborative combat power. The skill release of the characters on the field and the strengthened attack of the second character off the field form a dual strike rhythm, further enriching the strategic level of combat. The two modes are贯穿始终 by the same set of attribute sequence mechanisms, ensuring that no matter which manipulation method the player chooses, the operation of collecting interaction elements in the early stage will not be in vain, thus兼顾操控灵活性、策略深度与战斗连贯性 in the multi-role collaboration scenario.

[0062] Based on any embodiment of the method of the present application, when the first character is in the appearance participation mode, in response to an operation instruction for the first character, controlling the second character to execute a first action based on the action signal generated by the instruction includes: Step S3210, establish a mapping relationship between the operation instruction for the first character and the action type of the second character. When detecting an operation instruction for the first character, determine the corresponding target action type of the second character according to the mapping relationship.

[0063] In the appearance participation mode, each button pressed by the player when manipulating the first character needs to be converted into an instruction that the second character can understand and execute. This conversion cannot be random and must rely on a pre-established corresponding rule, which is the mapping relationship.

[0064] The work of establishing the mapping relationship occurs in the preparation stage after the second character is instantiated and before the player starts to manipulate. The game system will read the ability configuration table of the second character, which defines all the action types that the second character can execute, such as basic attack, heavy attack, dodge, and defense, etc.; at the same time, it also obtains the current operation configuration of the first character, such as what instruction the normal attack button corresponds to, what instruction the dodge button corresponds to, and what instruction the long-press skill button corresponds to. The process of establishing the mapping relationship is to pair these two tables and determine which action type of the second character should be triggered by each operation instruction of the first character.

[0065] In one implementation, the mapping relationship uses a simple one-to-one correspondence: the first character's basic attack button is mapped to the second character's basic attack, and the dodge button is mapped to the second character's movement evasion. In another implementation, the mapping relationship can include combined commands; for example, clicking the basic attack button while the first character is moving is mapped to the second character's dash attack, while clicking the basic attack button while stationary is mapped to a ranged attack. In more complex implementations, the mapping relationship can even dynamically switch based on the second character's current state; for example, when the second character is in a strengthened state, the original basic attack mapping will be temporarily replaced with a stronger attack form.

[0066] Once the mapping relationship is established, the game system enters a real-time monitoring phase. When the player presses an action button for the first character, the system first captures the action command, then immediately consults the mapping table to find the corresponding target action type for the second character based on the current action command. This lookup process is completed the instant the player presses the button, usually returning a result within one game frame. The found target action type serves as the basis for generating the next action signal, but is not executed directly, as the execution conditions and resource consumption of the action also need to be considered. Therefore, when controlling the first character, the player does not need to learn the independent control method of the second character; they only need to play the game according to their familiar control habits, and their intentions will be automatically transmitted to the second character.

[0067] Step S3220: Generate an action control signal based on the target action type, and send the action control signal to the instantiated object of the second character to drive it to execute the first action corresponding to the target action type.

[0068] Once the target action type for the second character is determined, the game system's task is to translate this abstract action type into physical commands that the second character can understand and execute. This involves the data transmission and control processes within the game engine. Generating the action control signal is equivalent to creating a unique execution command for the second character. This command not only includes the target action type but also various parameters required to execute the action. For example, if the target action type is a basic attack, the signal needs to include the attack direction, attack strength, and whether a combo check is triggered. If the target action type is a movement evasion, the signal needs to include parameters such as the evasion direction, invincibility frame duration, and movement distance. These parameters are calculated by the system based on the real-time state of the current game scene, including the first character's facing direction, the locked enemy target's position, and the second character's own spatial coordinates.

[0069] The way motion control signals are generated depends on the game engine's architecture. In one implementation, the game system generates signals by calling a dedicated motion control function. This function receives the target motion type as input parameters, encapsulates the complete logic of parameter calculation and instruction formatting, and finally outputs a standardized data packet. In another implementation, the game system uses the command pattern to create a corresponding command object for each motion type. The command object is responsible for collecting the required parameters and generating the final execution instruction.

[0070] Once the signal is generated, it needs to be sent. The target is the instantiated object of the second character. Since this object has been created and exists in the game scene, it has an independent memory address and object identifier. The action control signal can be passed to this instance by finding it through an object reference or global identifier. In single-player games, this transmission can be a direct function call. The second character's control script will have a dedicated receiving function that calls this function and passes the signal as a parameter. In online games, the transmission process can be relayed through a server. The client uploads the operation command to the server, which verifies it, generates a standardized action signal, and then broadcasts it to all relevant clients. The second character instance on each client then executes the corresponding action based on the signal.

[0071] After receiving the action control signal, the instantiated object of the second character begins to execute the first action of the corresponding target action type. The execution process involves calling the animation system, loading the corresponding animation sequence from the resource manager according to the action type, driving the second character's skeletal model to play the animation, and at the same time, the physics system intervenes to handle attack judgment, detecting which frames in the animation process need to trigger damage calculation, and which frames need to enable or disable colliders; the special effects system synchronously plays light and sound effects that match the action. The entire process is completed in collaboration with multiple subsystems of the engine, and what is finally presented to the player is the smooth action of the second character as expected.

[0072] The above embodiments provide players with a multi-character control method that requires no additional learning cost. By pre-establishing a mapping relationship between operation commands and action types, every key operation performed by the player on the first character is translated in real time into specific action commands that the second character can understand and execute. Players do not need to learn the operation keys of the second character separately, nor do they need to switch control targets. They only need to play the game according to the habits of controlling the first character, and the recognition, conversion, and transmission of commands will be completed automatically. This mapping mechanism significantly reduces the operation threshold in multi-character cooperative scenarios, allowing players to focus on the combat strategy itself rather than complex key memorization. When the player presses the basic attack button, the target action type that the second character should execute can be quickly determined through the mapping relationship, and an action control signal containing complete execution parameters is immediately generated and sent to the instantiated object of the second character. This process completes the closed loop within a single frame. Players do not perceive the delay caused by command conversion and obtain a smooth experience of synchronous response from both characters. The final effect is that a single operation by the player drives the action performance of both characters simultaneously, improving combat efficiency without increasing the amount of operation.

[0073] Based on any embodiment of the method in this application, the action control signal is sent to an instantiated object of the second role to drive it to execute a first action corresponding to the target action type, including: Step S3310: Obtain the animation state machine associated with the instantiated object of the second character, wherein the animation state machine includes multiple animation state nodes and state switching conditions.

[0074] In this implementation, in the participation mode, when an action control signal is generated and prepared to be sent to the second character, the core mechanism driving the second character to move on screen is the animation state machine. Here, the animation state machine is not an abstract concept, but rather a data structure and logic module within the game engine. It is attached to each character instance with animation capabilities and is responsible for managing all visual expressions of the character, from stillness to movement and from attack to being attacked. Obtaining the animation state machine associated with the instantiated object of the second character means that the system first needs to obtain a complete reference to this character instance in memory, then access its animation component through the interface provided by the engine, and then obtain the currently running animation state machine instance from the animation component. This acquisition operation can occur during the initialization phase after the second character is instantiated and before the player begins control, or it can be dynamically acquired each time an action needs to be performed.

[0075] The animation state machine contains multiple animation state nodes, each corresponding to a specific performance state of the character. For example, the standing node manages the character's breathing cycle animation when stationary, the walking node manages the gait animation when moving, the attack node contains a complete sequence of attack actions, and the hit node records the character's reaction animation when hit. These nodes are not isolated; they are interconnected through state switching conditions, forming a complete animation performance network. The switching conditions can take many forms: logical judgments, such as whether an attack command has been received or whether movement input has been detected; numerical thresholds, such as switching from walking to running when the movement speed exceeds a certain value; or event triggers, such as automatically switching back to the standing state after the attack animation finishes playing.

[0076] In a specific implementation of a game engine, each node of the animation state machine can contain more refined sub-state machines. For example, the attack node can be further divided into three sub-stages: the starting stance, the combo phase, and the finishing stance. Each sub-stage corresponds to a different animation segment. This layered design makes the character's movements more delicate and natural. When the action control signal is input to this animation state machine, the target action type contained in the signal will serve as a trigger condition, driving the state machine to switch from the current node to the corresponding target node, thereby playing the expected animation sequence.

[0077] Step S3320: Based on the target animation node determined by the target action type, generate a corresponding action driving instruction containing the target animation node identifier, and input the action driving instruction into the animation state machine to drive the animation state machine to switch from the current animation state node to the target animation node.

[0078] In order to truly translate the defined target action type into the dynamic performance of the second character's body, a translation process is required. This is because the target action type is just a logical label, while the second character's body is controlled by the animation state machine. The state machine only recognizes the specific animation node name, so it is necessary to first find the corresponding target animation node based on the target action type. This can be done through a pre-configured mapping table, which records which animation node name corresponds to each action type.

[0079] Once the target animation node is located, the action-driven instructions can be assembled. This instruction is a structured data packet, the core of which is the identifier of the target animation node. However, the identifier alone is not enough. The instruction also needs to include other parameters required to execute the animation, such as the animation playback speed, whether to loop, from which frame to start playback, and whether to allow mixing with other animations. The values ​​of these parameters depend on the current game scene. For example, when the character is in an accelerated state, the animation playback speed can be adjusted to 1.2 times; when the character is in the air, some attack animations need to start from a specific frame to avoid clipping.

[0080] After the action-driven command is generated, the game system inputs it into the animation state machine through the interface provided by the engine. Input can be done by directly calling the state machine's switching function, passing the target node identifier as a parameter, or by sending an event containing the command to the state machine, which then parses and executes it during the event handling phase of the next frame. Upon receiving the command, the animation state machine immediately begins the state switching process. It first checks whether the current animation state node can be interrupted; if so, it exits the current node and performs cleanup operations. Then, it loads the corresponding animation resources based on the target node identifier in the command, and finally hands control over to the target node, which then begins playing the animation sequence. The entire switching process is completed within a single frame or a few frames, resulting in the player seeing the second character smoothly transition from one action to another.

[0081] Step S3330: Based on the switching result of the animation state machine, drive the skeletal model of the second character to execute the first action of the animation sequence corresponding to the target action type.

[0082] Once the animation state machine completes the transition from the current node to the target animation node, this transition result is applied to the visual presentation of the second character. This is because the animation state machine itself doesn't directly control the character's body; it merely issues commands and records states. The actual execution of actions is done by the skeletal model system to which the character is attached. The skeletal model in this application is the underlying architecture used in the game engine to drive character movement. It binds the character's appearance mesh to a set of virtual bones. Each bone represents a movable part of the character's body, such as the upper arm, forearm, hand, and head bones. These bones are connected hierarchically to form a complete skeletal tree. The movement of higher-level bones causes lower-level bones to move as well. When the character needs to perform an action, the game engine adjusts the rotation angle and position of each bone in this skeletal tree to drive the deformation of the mesh attached to the bones, thus presenting a coherent movement on the screen. An animation sequence is a set of data stored in an animation resource file. It records the rotation angle, displacement offset, and scaling ratio that each bone should be in at each frame on a specific timeline. For example, in an attack animation sequence, at frame zero on the timeline, the right-hand bone is in a backward swing position. At 0.2 seconds, the right-hand bone swings forward. At 0.4 seconds, it reaches its maximum extension and triggers the attack judgment. At 0.6 seconds, it returns to the idle posture. When the motion-driven command is input into the animation state machine and the switch is completed, the animation system will load the animation sequence of the corresponding target animation node and begin to read these bone data frame by frame according to the timeline. The process of driving the skeletal model to execute the animation sequence is a continuous computational loop. Every time the game engine renders a frame, it interpolates and calculates the target pose of each bone in the current frame from the animation sequence based on the current animation playback time. This interpolation calculation is to ensure a smooth transition in the animation, because the animation sequence itself only records the data of key frames, and the intermediate state between two frames needs to be completed by the algorithm. After the calculation is completed, the engine applies the final transformation matrix of each bone to the corresponding vertex of the character mesh. The position of the vertex is adjusted according to the transformation of the bound bone, and finally the character image of the current frame is rendered.

[0083] During the animation process, the animation system can also handle additional logic. For example, when a specific time point in the animation sequence is marked as an attack judgment frame, a collision detection system is triggered upon reaching that frame to detect whether the character's attack area overlaps with the enemy's hit area, thus determining whether damage is inflicted. When a specific time point in the animation sequence is marked as an effect trigger point, the effects system generates light effects, particles, or sound effects at the corresponding skeletal position. This logic executes in parallel with the skeletal drive, collectively forming the complete action performance that the player ultimately sees. After the second character successfully completes the full animation sequence of the first action, the animation state machine determines which node to enter next based on preset rules. If the player continues to input operation commands, the state machine will respond again and switch to a new target node; if the player stops operating, the state machine will put the character into a standby node or select the next action according to preset automatic logic. The entire process repeats, allowing the second character to present continuous and smooth behavior under the player's command.

[0084] The above embodiments construct a complete execution chain from logical instructions to visual presentation, transforming abstract action types into smooth, realistic visual representations on the character's screen. By obtaining the animation state machine associated with the second character's instantiated object, the basic architecture for managing all character actions is obtained. Multiple pre-configured animation state nodes and state switching conditions within the animation state machine provide a structured execution environment for the precise triggering of corresponding actions. Determining the target animation node based on the target action type and generating action-driven instructions containing node identifiers decouples the logic layer from the presentation layer. The game system only needs to send the correct instructions without needing to intervene in the underlying details of animation playback. After inputting the action-driven instructions into the animation state machine, the state machine smoothly switches from the current node to the target node according to its internal rules, avoiding abrupt jumps between actions. Finally, based on the switching result, the second character's skeletal model executes the corresponding animation sequence, ensuring accurate visual feedback for every player command. From basic attacks to dodges, each action is presented naturally as expected, ensuring the second character responds to player commands quickly and accurately, with smooth, uninterrupted action transitions, thus guaranteeing the quality of visual presentation during multi-character collaborative operations.

[0085] Based on any embodiment of the method in this application, when the first character is in a non-participation mode, the second character is driven to perform the first action based on preset character logic. Correspondingly, when a game character currently in the game scene performs a preset type action, the next action of the second character is replaced with the second action, including: Step S3410: During the period when the first character is in the non-participation mode, start the automatic battle logic of the second character to drive the second character to periodically perform the first action.

[0086] When a player switches control from the primary character to another character in the team, the primary character retreats to the background and no longer receives direct player commands. However, the secondary character cannot cease activity simply because the primary character is inactive; otherwise, a significant gap in the combat rhythm would occur. Therefore, an automatic operating mechanism independent of player input is needed—this is the automatic combat logic. The automatic combat logic is activated the instant the primary character enters non-participation mode. Upon detecting that the currently active character is no longer the primary character, the system immediately loads the secondary character's automatic behavior configuration from background resources. This configuration is a behavior tree or rule set pre-written during game development and stored in the character's data assets. After loading, the game system switches the secondary character's control from player command listening mode to automatic execution mode. The core task of the automatic combat logic is to drive the secondary character to periodically execute the primary action. Periodic execution means that the second character's behavior is no longer a discrete response triggered by the player's key presses, but rather a continuous operation according to a fixed time rhythm. The system will create an independent timer or coroutine for the second character. This timer will trigger an action execution command every fixed time interval. For example, in one configuration, the interval is set to two seconds, so the second character will automatically execute the first action every two seconds. The setting of the interval depends on the intention of the game designer. For offensive summons, a shorter attack interval can be set, while for support summons, a longer interval can be set.

[0087] The first action is executed in the same way as when triggered by a player command in automatic mode. The game system calls the same action execution interface to send the same control signals, driving the same animation playback and attack judgment process. The only difference is that the source of the command changes from player input to an internal system timer. To ensure that the automatic execution process does not conflict with other logic, the automatic combat logic continuously monitors the current state of the second character. If the character is performing an action or is in a hitstun state, the command triggered by the timer will be suspended until the character is idle.

[0088] In more complex implementations, the automatic combat logic can also include a simple target selection mechanism. Each time it is triggered, the game system can automatically select an attack target according to preset priority rules. For example, it can prioritize attacking the enemy currently locked by the first character. If there is no such enemy, it can select the closest enemy. If there is still no such enemy, it can select the enemy with the lowest health. This allows the second character to not just mechanically swing around in automatic mode, but to truly participate in the battle and pose a threat to the enemy. The entire process does not require player intervention. The second character can continuously contribute output, filling the combat gaps when the player controls other characters.

[0089] Step S3420: Monitor the action type performed by the game character currently in the game scene. When the action type performed by the game character matches the preset type, interrupt the current cycle of the automatic combat logic so that the next action to be performed by the second character is replaced by the second action instead of the first action.

[0090] The game system continuously monitors every action performed by the currently active game character in the background, obtaining the type identifier of each action. When the detected action type matches a pre-set trigger type, such as when another character uses a special skill, the system immediately intervenes in the second character's auto-battle logic. At this time, the auto-battle logic may be in the interval between two attacks, so it doesn't forcibly cancel the second character's current action. Instead, it directly intervenes in the scheduling of its next action, replacing the originally planned first action with the second action. After the replacement, the original auto-execution cycle remains unchanged. When the timer triggers the next action, the second character will automatically execute an enhanced attack, forming a coordinated attack with other characters' skill releases.

[0091] Through the above embodiments of this application, the automatic combat logic of the second character in non-participation mode fills the control gap after the player switches characters. By periodically executing the first action, the second character can continuously output damage or provide combat support even in the background, avoiding the interruption of the combat rhythm caused by character switching. Monitoring the action types executed by other characters and intervening in a timely manner when matching preset conditions allows the player to indirectly command the second character to deliver enhanced attacks through the skill releases of other characters, even without directly controlling the first character. This creates a linkage between skill releases on the field and coordinated responses off the field, allowing the player to obtain a double attack effect without additional operation. The method of interrupting the automatic cycle without forcibly interrupting the current animation ensures the smoothness of action transitions and avoids visual frame skipping. This reduces the operational burden while enriching the strategic dimensions of multi-character cooperation, making the background character an integral part of the combat rhythm.

[0092] Based on any embodiment of the method in this application, in response to a state switching event where a first character in an initial state collects a preset number of interactive elements in the game scene, the attribute sequence of the interactive elements associated with the event is recorded, including: Step S3510: Monitor the first character's collection behavior of the interactive elements in the game scene, and trigger the state switching event when the number of collected interactive elements reaches a preset number of interactions.

[0093] During gameplay, the game system maintains a continuous real-time monitoring loop in the background, focusing on the interaction between the first character and the interactive elements scattered throughout the game scene. When the first character moves near an interactive element and triggers a collection check, the system immediately records the collection action and updates a counter to indicate the current number of items collected. This counter doesn't simply increment; each increment is compared to a preset interaction threshold. For example, if the preset threshold is 6, the system will continuously compare the counter at 3, 4, and 5 until it jumps from 5 to 6. The instant the counter changes from "less than" to "equal to," it indicates that the preset interaction threshold has been reached. This triggers an internal signal—the state transition event. The event signifies that the first character has fulfilled all the prerequisites for entering the next state, and the game system no longer waits for any additional input but proceeds directly to the next processing step. To ensure the accuracy of the judgment, the design can eliminate the possibility of repeatedly collecting the same interactive element. Each interactive element will disappear from the scene or be marked as uncollectible after being collected, preventing players from repeatedly entering and leaving the same location to farm the count.

[0094] In one implementation, the monitoring mechanism uses collision detection. Each interactive element is equipped with a trigger component, and collection is determined when the first character's collider enters the trigger's range. In another implementation, the monitoring mechanism uses distance determination. Each frame calculates the straight-line distance between the first character and each interactive element, and collection is automatically completed when the distance is less than a threshold. In a third implementation, the collection behavior does not depend on static objects in the scene but is bound to the character's actions. For example, when the first character completes a specific combo, an interactive element is generated and automatically added to the count. The core logic of the monitoring always revolves around the accumulation of quantities and comparison with a threshold. Once the condition is met, a state transition event is generated.

[0095] Step S3520: In response to the state switching event, obtain the attribute identifiers corresponding to each of the collected interactive elements, and generate the attribute sequence based on the collection order of the attribute identifiers.

[0096] Once the state transition event is triggered, it's necessary to trace back which interactive elements the first character encountered during the collection process, and what attributes each element carries. Each interactive element is assigned a unique attribute identifier upon creation. This identifier might be an enumeration value, such as zero for red, one for purple, and two for colored, or it could be a string label, or even a composite structure containing multiple pieces of information. The core function of the attribute identifier is to abstract the interactive element from its visual representation into a data type that the program can recognize.

[0097] The game system retrieves the attribute identifiers corresponding to each interactive element in the order they are collected, and adds these identifiers one by one to a newly created queue or array structure. The construction process of this structure strictly follows the chronological order. The attribute identifier of the first collected interactive element occupies the first position in the sequence, the identifier of the second collected element occupies the second position, and so on until the last one. Thus, when the second character performs an enhancement action, these identifiers can be consumed one by one in the exact same order. The order in which the player operates during the collection phase will directly translate into the order in which different enhancement effects appear in battle.

[0098] The attribute sequence can exist in memory as a linked list, a dynamic array, or a fixed-length array. The specific implementation depends on the game engine's data structure preferences and performance requirements. After the sequence is generated, the game system will bind it to the first character. It is stored in the current character's session data or attached to the configuration information of the second character to be summoned. This sequence will survive until it is explicitly consumed or reclaimed by a clearing operation. At this time, the attribute sequence is ready and waiting for each enhanced attack of the second character to awaken it in sequence.

[0099] The embodiments described above can transform a player's free exploration behavior in a game scene into structured data that the system can use subsequently. By monitoring the first character's collection behavior of interactive elements in real time and triggering a state switching event when the quantity reaches a preset threshold, a precise correspondence between player actions and character states can be established, ensuring that each collection has clear feedback and meaning. After the state switching event is triggered, the attribute identifiers of each interactive element are extracted and an attribute sequence is generated according to the order of collection. This process transforms the player's unconscious action sequence into a numerical structure with practical effect. The preservation of the collection order means that every choice the player makes during the exploration phase will affect the performance in subsequent battles. Players can adjust the collection order to plan the arrangement of subsequent enhanced attack effects, thus laying the groundwork for strategy before the battle begins. The generation method of the attribute sequence is simple and efficient, ensuring data integrity and providing a reliable data foundation for the differentiated performance of the second character.

[0100] Based on any embodiment of the method in this application, when the second character executes the character control logic and satisfies a preset termination condition, the attribute sequence is cleared, and the game state of the first character is switched to the initial state accordingly, including: Step S3610: Monitor the running status of the second role executing the role control logic to determine whether the preset termination condition is met. When the preset termination condition is met, generate a status reset instruction.

[0101] Throughout the second character's execution of control logic, a state monitoring mechanism runs in the background. This mechanism continuously observes various operational metrics of the second character, including but not limited to the remaining value of the duration timer, the number of enhanced actions performed, whether a manual termination command has been received from the player, and whether the first character has re-entered the game. Monitoring is a continuous process performed every frame or at fixed intervals, ensuring that the game system can capture any situation where preset conditions are met. Termination conditions are stored in the system's condition configuration table as logical expressions. When the monitoring mechanism collects current operational data, it substitutes the data into each preset condition for calculation. For example, for time-related conditions, it compares the current timer value with the set duration threshold; for count-related conditions, it compares the number of enhanced actions performed with the set trigger limit; and for operation-related conditions, it checks whether the player has pressed the early termination shortcut key. If any conditional expression evaluates to true, the preset termination condition is considered met. The moment the judgment is successful, a state reset command is immediately generated. This command is a dedicated data packet containing the core identifier that "the current state needs to be ended," along with auxiliary information such as whether the end reason is time exhaustion or player-initiated termination, so as to execute differentiated ending behaviors based on different end reasons. The generated state reset command is sent to a message queue, waiting for the corresponding processing module to retrieve and execute the state rollback operation.

[0102] Step S3620: In response to the state reset instruction, release the memory resources occupied by the attribute sequence to clear the attribute sequence, and accordingly revert the game state of the first character from the second state to the initial state according to the state reset instruction.

[0103] Upon receiving the state reset command, the game system immediately begins to execute two core operations: resource cleanup and state rollback. The first thing to be processed is the attribute sequence. This sequence has been occupying memory space since its generation. Now that it has completed its mission, continuing to retain it would only waste resources. Therefore, the game system finds the memory address where the sequence is stored and performs a release operation according to the game engine's memory management mechanism. The result of the release operation is that the memory occupied by the attribute sequence is returned to the system, and the data in the sequence is no longer available.

[0104] Following this, the game system executes a state rollback operation based on the information carried in the state reset command. The first character's game state switches from the second state back to the initial state, involving a reset of various aspects such as character appearance, skill permissions, and physical attributes. For example, visually, the floating effects or light effects unique to the second state gradually disappear, and the character falls back to the ground from the air; logically, skill permissions granted during the second state are revoked, and previously highlighted skill icons return to gray or disappear; data-wise, all currently bound temporary state variables of the character are cleared, thus allowing the first character to completely return to a relatively initialized state. The execution order of the state reset command is carefully considered: the attribute sequence must be released before the state rollback, because after the state rollback, the character may immediately begin a new round of collection. If the attribute sequence still remains, the newly generated sequence may be confused with the old data. By releasing the sequence first and then rolling back the state, it ensures that the first character is in a "completely clean" state to welcome the next cooperative combat cycle.

[0105] Through the synergistic effect of the above embodiments, this application ensures that the entire collaborative interaction method can operate healthily and sustainably in a loop. By continuously monitoring the running status of the second character and promptly determining the preset termination conditions, it can accurately grasp when to terminate the current collaborative phase, avoiding resource waste or logical chaos caused by the infinite continuation of the state. Once the termination condition is met, a state reset instruction is immediately generated, and memory release operations of the attribute sequence are executed in response to the instruction. This action promptly reclaims the resources occupied by data that is no longer needed, preventing the risk of memory leaks. Subsequently, according to the reset instruction, the game state of the first character is reverted from the second state to the initial state, so that the character's visual performance, skill permissions, and attribute data are completely restored to the pure state before the start of collaboration. This not only ensures the resource efficiency of game operation but also prepares for the next entry into the collaborative state, allowing players to repeatedly experience the complete collection, summoning, collaboration, and termination process without data residue or state conflicts.

[0106] Please see Figure 3According to one aspect of this application, a character collaborative interaction device includes an event response module 4100, a collaborative triggering module 4200, a character control module 4300, and a state recovery module 4400. The event response module 4100 is configured to respond to a state switching event in which a first character in an initial state collects a preset number of interactive elements in a game scene, record the attribute sequence of the interactive elements associated with the event, and switch the game state of the first character from the initial state to a first state. The collaborative triggering module 4200 is configured to switch the game state of the first character to a second state and instantiate a second character in the game scene when a skill casting operation triggered by the first character in the first state is detected. The character control module 4300 is configured to determine the game participation mode of the first character during the second state and execute the character control logic of the second character accordingly based on the game participation mode. The state recovery module 4400 is configured to clear the attribute sequence when the second character executes the character control logic and satisfies a preset termination condition, and correspondingly switch the game state of the first character back to the initial state.

[0107] Based on any embodiment of the device in this application, the character control module 4300 includes: a first mode unit, configured to, when the first character is in the participation mode, respond to an operation command for the first character and control the second character to perform a first action based on an action signal generated by the command; an action replacement unit, configured to, when the second character has accumulated the execution of the first action until a preset action execution condition is met, replace the next execution action of the second character with a second action, wherein the visual performance effect of the second action is determined according to the attribute sequence; and a second mode unit, configured to, when the first character is in the non-participation mode, drive the second character to perform the first action based on a preset character logic, and replace the next execution action of the second character with the second action when a game character currently in the game scene performs a preset type action.

[0108] Based on any embodiment of the device in this application, the first mode unit includes: a mapping establishment subunit, configured to establish a mapping relationship between operation instructions for the first character and action types for the second character, and when an operation instruction for the first character is detected, determine the target action type of the corresponding second character according to the mapping relationship; and a signal sending subunit, configured to generate an action control signal based on the target action type, and send the action control signal to an instantiated object of the second character to drive it to perform a first action corresponding to the target action type.

[0109] Based on any embodiment of the device in this application, the signal transmission subunit includes: a state machine acquisition component, configured to acquire the animation state machine associated with the instantiated object of the second character, wherein the animation state machine includes multiple animation state nodes and state switching conditions; an instruction input component, configured to generate an action driving instruction containing a target animation node identifier according to the target animation node determined by the target action type, and input the action driving instruction to the animation state machine to drive the animation state machine to switch from the current animation state node to the target animation node; and an action driving component, configured to drive the skeletal model of the second character to execute the first action of the animation sequence corresponding to the target action type based on the switching result of the animation state machine.

[0110] Based on any embodiment of the device in this application, the second mode unit includes: a logic activation subunit, configured to activate the automatic combat logic of the second character during the period when the first character is in the non-participation mode, so as to drive the second character to periodically execute the first action; and an action replacement subunit, configured to monitor the action type executed by the game character currently in the game scene, and interrupt the current cycle of the automatic combat logic when the action type executed by the game character matches a preset type, so as to replace the first action with the second action for the next execution action of the second character.

[0111] Based on any embodiment of the device in this application, the event response module 4100 includes: an event triggering unit, configured to monitor the collection behavior of the first character on the interactive elements in the game scene, and trigger the state switching event when the number of collected interactive elements reaches a preset number of interactions; and a sequence generation unit, configured to, in response to the state switching event, obtain the attribute identifiers corresponding to each of the collected interactive elements, and generate the attribute sequence based on the collection order of the attribute identifiers.

[0112] Based on any embodiment of the device in this application, the state recovery module 4400 includes: an instruction generation unit, configured to monitor the running state of the second character executing the character control logic to determine whether a preset termination condition is met, and generate a state reset instruction when the preset termination condition is met; and an instruction response unit, configured to, in response to the state reset instruction, release the memory resources occupied by the attribute sequence to clear the attribute sequence, and correspondingly revert the game state of the first character from the second state to the initial state according to the state reset instruction.

[0113] Another embodiment of this application also provides a role-based collaborative interaction device. For example... Figure 4The diagram shows the internal structure of a role-based collaborative interaction device. This device includes a processor, a computer-readable storage medium, a memory, and a network interface connected via a system bus. The computer-readable, non-volatile storage medium stores an operating system, a database, and computer-readable instructions. The database stores information sequences, and when executed by the processor, these computer-readable instructions enable the processor to implement a role-based collaborative interaction method.

[0114] The processor of this role-playing interactive device provides computing and control capabilities to support the operation of the entire device. The memory of this device can store computer-readable instructions, which, when executed by the processor, cause the processor to perform the role-playing interactive method of this application. The network interface of this device is used for communication with a terminal.

[0115] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the solution of this application and does not constitute a limitation on the role-cooperative interaction device to which the solution of this application is applied. The specific role-cooperative interaction device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0116] In this embodiment, the processor is used to execute... Figure 3 The specific functions of each module are described, and the memory stores the program code and various data required to execute the aforementioned modules or sub-modules. The network interface is used to enable data transmission between user terminals or servers. In this embodiment, the non-volatile readable storage medium stores the program code and data required to execute all modules in the role-based collaborative interaction device of this application. The server can call the server's program code and data to execute the functions of all modules.

[0117] This application also provides a non-volatile readable storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the role-cooperative interaction method of any embodiment of this application.

[0118] This application also provides a computer program product, including a computer program / instructions that, when executed by one or more processors, implement the steps of the method described in any embodiment of this application.

[0119] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a computer-readable storage medium such as a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM).

Claims

1. A method for role-based collaborative interaction, characterized in that, include: In response to a state switching event where a first character in the initial state collects a preset number of interactive elements in the game scene, the attribute sequence of the interactive elements associated with the event is recorded, and the game state of the first character is switched from the initial state to the first state. When a skill casting operation triggered by the first character in the first state is detected, the game state of the first character is switched to the second state, and the second character is instantiated in the game scene; Determine the game participation mode of the first character during the second state, and execute the character control logic of the second character based on the game participation mode; When the second character executes the character control logic and meets the preset termination condition, the attribute sequence is cleared, and the game state of the first character is switched to the initial state accordingly.

2. The role-based collaborative interaction method according to claim 1, characterized in that, The step of determining the game participation mode during which the first character is in the second state, and executing the character control logic of the second character based on the game participation mode, includes: When the first character is in the participation mode, in response to the operation command for the first character, the action signal generated based on the command controls the second character to perform the first action; When the second character has accumulated the execution of the first action until the preset action execution condition is met, the next action to be executed by the second character will be replaced by the second action, wherein the visual effect of the second action is determined according to the attribute sequence; When the first character is in a non-participation mode, the second character is driven to perform the first action based on the preset character logic. When the game character currently in the game scene performs a preset type action, the next action of the second character is replaced with the second action.

3. The role-based collaborative interaction method according to claim 2, characterized in that, When the first character is in the participation mode, in response to the operation command for the first character, the action signal generated based on the command controls the second character to perform a first action, including: Establish a mapping relationship between operation commands for the first character and action types for the second character. When an operation command for the first character is detected, determine the target action type for the corresponding second character based on the mapping relationship. An action control signal is generated based on the target action type, and the action control signal is sent to the instantiated object of the second character to drive it to execute the first action corresponding to the target action type.

4. The role-based collaborative interaction method according to claim 3, characterized in that, Sending the action control signal to the instantiated object of the second character to drive it to execute the first action corresponding to the target action type includes: Obtain the animation state machine associated with the instantiated object of the second character, wherein the animation state machine includes multiple animation state nodes and state switching conditions; Based on the target animation node determined by the target action type, a corresponding action driving instruction containing the target animation node identifier is generated, and the action driving instruction is input to the animation state machine to drive the animation state machine to switch from the current animation state node to the target animation node; Based on the switching result of the animation state machine, the skeletal model of the second character is driven to execute the first action of the animation sequence corresponding to the target action type.

5. The role-based collaborative interaction method according to claim 2, characterized in that, When the first character is in a non-participation mode, the second character is driven to perform the first action based on preset character logic. Correspondingly, when a game character currently in the game scene performs a preset type action, the next action of the second character is replaced with the second action, including: The automatic combat logic of the second character is activated while the first character is in non-participation mode, so as to drive the second character to periodically perform the first action; The system monitors the action type performed by the game character currently in the game scene. When the action type performed by the game character matches a preset type, the current cycle of the automatic combat logic is interrupted so that the next action to be performed by the second character is replaced by the second action instead of the first action.

6. The role-based collaborative interaction method according to claim 1, characterized in that, The state transition event in response to the first character in its initial state collecting a preset number of interactive elements in the game scene records the attribute sequence of the interactive elements associated with the event, including: The system monitors the first character's collection behavior of the interactive elements in the game scene, and triggers the state switching event when the number of collected interactive elements reaches a preset number of interactions. In response to the state switching event, the attribute identifiers corresponding to each of the collected interactive elements are obtained, and the attribute sequence is generated based on the collection order of the attribute identifiers.

7. The role-based collaborative interaction method according to any one of claims 1-6, characterized in that, The step of clearing the attribute sequence when the second character executes the character control logic and satisfies the preset termination condition, and correspondingly switching the game state of the first character to the initial state, includes: Monitor the running status of the second role executing the role control logic to determine whether the preset termination condition is met; when the preset termination condition is met, generate a status reset instruction. In response to the state reset instruction, the memory resources occupied by the attribute sequence are released to clear the attribute sequence, and the game state of the first character is reverted from the second state to the initial state according to the state reset instruction.

8. A role-playing collaborative interaction device, characterized in that, include: The event response module is configured to respond to a state switching event in which a first character in the initial state collects a preset number of interactive elements in the game scene, record the attribute sequence of the interactive elements associated with the event, and switch the game state of the first character from the initial state to the first state. The collaborative triggering module is configured to switch the game state of the first character to the second state when a skill casting operation triggered by the first character in the first state is detected, and instantiate the second character in the game scene. The character control module is configured to determine the game participation mode of the first character during the second state, and execute the character control logic of the second character based on the game participation mode. The state recovery module is configured to clear the attribute sequence when the second character executes the character control logic and meets the preset termination condition, and correspondingly switch the game state of the first character to the initial state.

9. A role-playing interactive device, comprising a central processing unit and a memory, characterized in that, The central processing unit is used to invoke and run a computer program stored in the memory to perform the steps of the method as described in any one of claims 1 to 7.

10. A non-volatile readable storage medium, characterized in that, It stores, in the form of computer-readable instructions, a computer program implemented according to any one of claims 1 to 7, which, when invoked by a computer, executes the steps included in the corresponding method.

Images