Multi-role collaborative management method and device

Abstract

An embodiment of the present disclosure provides a multi-role collaborative management method, comprising: obtaining collaborative behavior data of a plurality of associated roles of a target game account in a game; determining a dependency relationship between the plurality of associated roles based on the collaborative behavior data, and constructing a collaborative profile of the target game account; opening corresponding collaborative management permissions for the plurality of associated roles according to the permission level of the collaborative profile, and outputting a collaborative management interface; and in response to a collaborative operation request for the collaborative management interface, performing a corresponding collaborative management operation under the rule constraint of the collaborative management permission. In this way, it helps to reduce frequent switching and repeated operations between roles, reduce redundant interaction between the terminal and the server, improve the processing efficiency of multi-role collaborative management, and help to alleviate the data processing pressure of the server caused by high-frequency state requests.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to multi-role collaborative management methods, apparatus, storage media, and electronic devices. Background Technology

[0002] In massively multiplayer online games (MMORPGs), some users may simultaneously control multiple related characters to perform activities such as resource production, task execution, and item transfer. In related technologies, the operational data of each character is typically recorded and managed independently. Users need to frequently switch between accounts or character identities on their devices and manually control and view the status of each character on different interfaces.

[0003] However, in the above approach, the terminal needs to make frequent status requests and command interactions with the server, which can easily generate redundant data streams and consume a lot of network and computing resources, increasing the data processing pressure on the server and the overall system load, and also increasing the information synchronization delay in multi-role collaborative states. Summary of the Invention

[0004] This disclosure provides a multi-role collaborative management method, apparatus, computer-readable storage medium, and electronic device to at least partially solve the aforementioned problems existing in the related art.

[0005] According to one aspect of this disclosure, a multi-role collaborative management method is provided, comprising: acquiring collaborative behavior data of multiple associated roles of a target game account in the game; wherein the multiple associated roles include a main role and at least one auxiliary role; determining the dependency relationship between the multiple associated roles based on the collaborative behavior data, and constructing a collaborative profile of the target game account; granting corresponding collaborative management permissions to the multiple associated roles according to the permission level of the collaborative profile, and outputting a collaborative management interface; wherein the collaborative management permissions include task progress sharing permissions and resource scheduling permissions; and responding to collaborative operation requests for the collaborative management interface, executing corresponding collaborative management operations under the rule constraints of the collaborative management permissions.

[0006] According to one aspect of this disclosure, a multi-role collaborative management device is provided. The device includes: an acquisition module, used to acquire collaborative behavior data of multiple associated characters of a target game account in the game; wherein the multiple associated characters include a main character and at least one auxiliary character; a construction module, used to determine the dependency relationship between the multiple associated characters based on the collaborative behavior data, and construct a collaborative profile of the target game account; an output module, used to grant corresponding collaborative management permissions to the multiple associated characters according to the permission level of the collaborative profile, and output a collaborative management interface; wherein the collaborative management permissions include task progress sharing permissions and resource scheduling permissions; and an execution module, used to respond to collaborative operation requests for the collaborative management interface, and execute corresponding collaborative management operations under the rule constraints of the collaborative management permissions.

[0007] According to one aspect of this disclosure, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements any of the above-described multi-role collaborative management methods.

[0008] According to one aspect of this disclosure, an electronic device is provided, comprising: a processor and a memory; the memory for storing a computer program; and the processor for executing the computer program stored in the memory to cause the electronic device to perform any of the above multi-role collaborative management methods.

[0009] One embodiment of this disclosure provides a multi-role collaborative management method, comprising: acquiring collaborative behavior data of multiple associated characters of a target game account in the game; wherein the multiple associated characters include a main character and at least one auxiliary character; determining the dependency relationship between the multiple associated characters based on the collaborative behavior data, and constructing a collaborative profile of the target game account; opening corresponding collaborative management permissions to the multiple associated characters according to the permission level of the collaborative profile, and outputting a collaborative management interface; wherein the collaborative management permissions include task progress sharing permissions and resource scheduling permissions; and executing corresponding collaborative management operations in response to collaborative operation requests to the collaborative management interface, under the rule constraints of the collaborative management permissions. Thus, opening progress sharing and resource scheduling based on hierarchical permissions of the collaborative profile helps reduce frequent switching and repetitive operations between characters, reduces redundant interactions between the terminal and the server, improves the processing efficiency of multi-role collaborative management, and helps alleviate the data processing pressure on the server caused by high-frequency status requests. Attached Figure Description

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

[0011] Figure 1 A schematic diagram of a system architecture is shown in one exemplary embodiment of this disclosure. Figure 2 A flowchart illustrating a method in one exemplary embodiment of this disclosure is shown; Figure 3 A schematic diagram of a multi-opening assistance rule mechanism in one exemplary embodiment of this disclosure is shown; Figure 4 A schematic diagram illustrating a collaborative management interface in one exemplary embodiment of this disclosure is shown; Figure 5 This diagram illustrates a role grouping management area in one exemplary embodiment of the present disclosure; Figure 6 This diagram illustrates an apparatus configuration in one exemplary embodiment of the present disclosure. Figure 7 A schematic diagram of the structure of an electronic device is shown in one exemplary embodiment of the present disclosure. Detailed Implementation

[0012] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0013] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0014] It should be noted that the information (including but not limited to user input information, such as information entered by the user into input boxes), data (including but not limited to data used for analysis, stored data, and displayed data, such as context code, all code of the current project, the service pressure corresponding to operations performed on all code of the current project, and the code development status of the current project), and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with relevant laws, regulations, and standards. For example, the context code, operations performed on all code of the current project, the corresponding service pressure, and the code development status involved in this application were all obtained with full authorization.

[0015] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of the invention described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0016] It should also be noted that the various trigger events disclosed in this manual can be preset, and different trigger events can trigger the execution of different functions.

[0017] The method in one embodiment of this disclosure can run on a terminal device or a server. The terminal device can be a local terminal device. When the method in the embodiment runs on a server, the method can be implemented and executed based on a cloud interaction system, wherein the cloud interaction system includes a server and client devices. Figure 1 The figure shows a cloud interaction system architecture diagram provided in this disclosure. As shown, the cloud interaction system may include: a client device 10 and a server 20, wherein the client device 10 can be connected to the server 20 via a network 30.

[0018] In an optional implementation, various cloud applications, such as cloud gaming, can run under the cloud interaction system. Taking cloud gaming as an example, cloud gaming refers to a gaming method based on cloud computing. In the cloud gaming operation mode, the game program's execution and the game screen presentation are separate. The storage and execution of the method provided in this embodiment are completed on the cloud gaming server. The client device is used for receiving and sending data and presenting the game screen. For example, the client device can be a display device with data transmission capabilities located close to the user, such as a mobile terminal, television, computer, or PDA; however, the terminal device for information processing is the cloud gaming server in the cloud. When playing the game, the player operates the client device to send operation commands to the cloud gaming server. The cloud gaming server runs the game according to the operation commands, encodes and compresses the game screen and other data, returns it to the client device via the network, and finally, the client device decodes and outputs the game screen.

[0019] In an alternative implementation, the terminal device can be a local terminal device. Taking a game as an example, the local terminal device stores the game program and is used to display the game screen. The local terminal device is used to interact with the player through a graphical user interface, that is, conventionally downloading, installing, and running the game program via an electronic device. The local terminal device can provide the graphical user interface to the player in various ways, such as rendering it on the terminal's display screen, or providing it to the player through holographic projection. For example, the local terminal device can include a display screen for displaying the graphical user interface, which includes game screens, and a processor for running the game, generating the graphical user interface, and controlling the display of the graphical user interface on the display screen.

[0020] According to one embodiment of the multi-role collaborative management method of this disclosure, such as Figure 2 As shown, the method may include: Step S210: Obtain collaborative behavior data of multiple related characters in the game for the target game account; wherein, the multiple related characters include one main character and at least one auxiliary character; Step S230: Based on collaborative behavior data, determine the dependency relationships between multiple related roles and construct a collaborative profile for the target game account; Step S250: Based on the permission level of the collaborative file, grant corresponding collaborative management permissions to multiple associated roles and output the collaborative management interface; wherein, the collaborative management permissions include task progress sharing permissions and resource scheduling permissions; Step S270: In response to a collaborative operation request for the collaborative management interface, execute the corresponding collaborative management operation under the rules of collaborative management permissions.

[0021] According to one embodiment of this disclosure, the hierarchical permission opening progress sharing and resource scheduling based on collaborative archives can help reduce frequent switching and repetitive operations between roles, reduce redundant interactions between terminals and servers, improve the processing efficiency of multi-role collaborative management, and help alleviate the data processing pressure on the server caused by high-frequency status requests.

[0022] The embodiments of this disclosure will now be further described.

[0023] In step S210, collaborative behavior data of multiple related characters in the game for the target game account is acquired; wherein, the multiple related characters include one main character and at least one auxiliary character. This systematic collection of behavioral data from multiple related characters under the same account, clearly distinguishing between the main and auxiliary characters, provides a precise data foundation for subsequent collaborative profile building and differentiated support strategies, effectively improving the efficiency of multi-character management. In one implementation, the system detects that a user simultaneously maintains a warrior character A and a healer character B on the client, where character A is designated as the main character and character B as the auxiliary character. During the player's multi-account operation, the system continuously records the online time, task execution sequence, and resource transfer direction and quantity between character A and character B for the two related characters, and packages and archives this data as collaborative behavior data for the day, so as to subsequently identify the degree of dependence of character A on the output of character B. It should be noted that the number of related characters can be more than two; for example, the same account can also include a dedicated production character for gathering resources and a trading character for setting up stalls.

[0024] Optionally, the aforementioned collaborative behavior data includes, but is not limited to, the online duration of associated roles, task execution sequences, resource transfer records, and role switching pulses, which are used to quantify the collaborative relationships and labor intensity among multiple roles.

[0025] Optionally, the aforementioned collaborative behavior data can be a multi-dimensional operation dataset generated by the system through front-end tracking and back-end log collection. Considering that multi-account players often switch frequently between several characters to complete daily tasks, to avoid losing the switching context due to simply recording static logs, as a possible implementation, the data can include switching pulse records. These records can capture the source character, target character, switching interval, and the context of unfinished tasks before the switch when the user completes a character switching action. Furthermore, the collaborative behavior data can also cover resource flow data, such as recording the transfer of herbs, gold coins, or equipment from a secondary character to the primary character, as well as the number of times each character repeats a behavior in different gameplay modules. It should be understood that the granularity of collaborative behavior data collection can be dynamically adjusted according to account activity or storage costs. For example, the sampling frequency can be increased when high-frequency switching segments are detected, while the reporting frequency of unnecessary fields can be reduced when a single character is idle for a long time.

[0026] Optionally, the aforementioned associated roles refer to multiple game characters under the same user control with primary and secondary functions. The primary character carries the core growth progress, while the secondary character provides resources or assists with tasks. Optionally, these associated roles can be actively created or designated by the user during multi-account operation, or automatically identified and labeled by the system based on historical behavior. It should be noted that the identities of primary and secondary characters are not permanently fixed; the system can dynamically adjust them based on resource aggregation direction, equipment enhancement bias, or dungeon participation frequency within a preset period. For example, when the system detects that a mage character under an account has received more than 80% of the transferred resources within the account for seven consecutive days, and its online time percentage is higher than other characters, the mage character can be marked as the primary character, while the artisan character, who mainly performs gathering and potion-making operations, can be marked as a secondary character. Furthermore, a target game account can contain multiple secondary characters, such as a dedicated combat support buff character and an economic character responsible for market transactions. Horizontal resource transfers can also exist between different secondary characters. The above description of the number and division of labor of main and auxiliary roles is only one example. In actual implementation, it can be determined according to the characteristics of the game category or the operation strategy.

[0027] In step S230, based on collaborative behavior data, the dependencies between multiple related roles are determined, and a collaborative profile of the target game account is constructed. In this way, by analyzing collaborative behavior data to determine dependencies and construct collaborative profiles, not only can the resource supply structure between multiple roles be accurately depicted, but also a reliable basis for differentiated permission granting can be provided, thereby supporting the server-side's refined identification and controllable assistance of multi-account behavior.

[0028] In one implementation, the system acquires collaborative behavior data of three associated roles under the same user over seven consecutive days. The primary combat role receives daily transfers of medicinal herbs and gold coins from the production role, and the user switches between the primary combat role and the production role more than twenty times daily. Based on resource flow records, the system calculates the primary combat role's dependency to be 75%, and determines a repetitive labor intensity index of 68 by combining switching pulse records and the number of repeated actions. Further, the system generates a dependency graph containing resource supply chains and high-frequency operation paths based on the primary role's dependency and the repetitive labor intensity index. It then archives the primary / secondary relationships, role divisions, and repetitive labor intensity into a collaborative profile for that account, and marks its collaborative maturity as stable collaboration based on continuous data collection duration and the stability of the division of labor.

[0029] Optionally, dependencies are used to characterize the degree of mutual support between related roles in resource flow and operational coordination, providing a basis for subsequent permission classification. Optionally, the above dependencies can be reflected as the dependency degree of multiple related roles in supplying resources to the main role, or as the repetitive labor intensity index determined based on switching pulse records and task execution records. Optionally, the collaboration profile is used to record the division of labor and dependency structure of multiple roles under the same account, serving as a benchmark for subsequent permission opening and risk control. Optionally, the aforementioned collaboration profile may include, but is not limited to, multi-dimensional profile information such as primary / secondary account identification results, functional role division, repetitive labor intensity index, and dungeon and competitive time compression index. In one implementation, the system classifies collaboration profiles into different collaboration maturity levels, such as basic collaboration, stable collaboration, or deep collaboration, based on the continuous collection duration of collaboration behavior data, the stability of role division, and abnormal risk scores. Simultaneously, when the maturity of a collaboration profile jumps, the system can display a jump prompt in the form of a banner on the collaboration panel page, and simultaneously unlock the corresponding group slot and linked task group preview. Considering the differences in multi-account usage habits among different accounts, the aforementioned profile dimensions can also be dynamically expanded according to actual business needs, such as adding auxiliary indicators like transaction activity or social interaction frequency, thereby providing richer decision-making basis for subsequent differentiated permission opening and risk control.

[0030] In an optional implementation, collaborative behavior data includes role switching records, resource flow records, and task execution records; role switching records include switching pulse records; determining the dependencies between multiple related roles includes: calculating the primary role dependency degree based on resource flow records, whereby the primary role dependency degree characterizes the proportion of resource supply from each related role to the primary role; determining the repetitive labor intensity index based on switching pulse records and task execution records; and generating a dependency graph of multiple related roles based on the primary role dependency degree and the repetitive labor intensity index. Thus, by collecting collaborative data containing switching pulses and quantifying the primary role dependency degree and repetitive labor intensity, a dependency graph is generated, providing a dynamic basis for the hierarchical classification of collaborative archive permissions, and improving the accuracy of multi-role collaborative identification and assistance matching.

[0031] In one implementation, a single user in the game controls three associated roles: a main combat role, a support gathering role, and a trading role. The system continuously collects collaborative behavior data for this account. Character switching records not only document the time of switching from the gathering role to the main role but also capture high-frequency switching events with 15-second intervals via a pop-up switching pulse bar. Resource flow records track the amount of ores and herbs transferred from the support gathering role to the main combat role over the past seven days. Task execution records the number of times each character repeatedly performs dungeon support, wilderness gathering, and town stall activities daily. Based on this data, the system calculates the main character's dependency at 0.82, indicating that the main character's growth is highly dependent on the support character's supply. Simultaneously, due to the cumulative 40 repeated operations per day and frequent high-frequency switching, the repetitive labor intensity index is rated at 75 points. Finally, the system generates a visualized dependency graph with the main character as the central node, using connection weights to represent resource dependency ratios and node colors to represent labor intensity levels. This graph supports subsequent maturity stratification and permission level determination for collaborative profiles.

[0032] Optionally, the role switching record aims to capture the switching actions and their timing attributes between multiple related roles under the same user's control, used to identify primary / secondary account rotation habits and high-frequency operation alternation patterns. Optionally, the role switching record can be a complete timestamp sequence recording a user's logout from the currently controlled role and reselecting another role. Besides including the absolute time of the switching action, it can also include the role's identity before and after the switch, the switching time, and the scene context during the switch. Considering that multi-account players need to quickly move between the primary account and multiple secondary accounts to complete resource transfer, task handover, or status checks in actual operation, as a possible implementation, the above record can be collected through a combination of client-side tracking and server session logs: when the user confirms the target role to switch on the role selection interface, the client reports the switching request time; after the new role scene is loaded, the server records the session activation time, and the difference between the two is the switching time. Furthermore, if the switching time is less than a preset threshold, the record can be marked as a high-frequency switching segment to distinguish it from normal cross-role mail or market viewing behavior, thereby providing refined data support for subsequent identification of primary / secondary account rotation habits.

[0033] Optionally, resource flow records are used to document the transfer paths and quantity structures of virtual items between multiple related characters, quantifying the resource supply ratio and output characteristics of each character to the main character. Optionally, resource flow records can be targeted logs generated by the system for actions such as direct transactions between characters within an account, sending email attachments, guild warehouse storage and retrieval, or shared backpack transfers. Specifically, in addition to the unique identifier and quantity of transferred items, the record may also include the transfer direction, transfer timestamp, and the item's quality level or scarcity marker. To avoid misjudging a one-time large-amount, accidental transfer as a long-term dependency, as a possible implementation, the records can be aggregated according to a fixed statistical period (e.g., using a natural week or natural month as the granularity) to calculate the proportion of the cumulative quantity transferred from each auxiliary character to the main character relative to the total flow within the account. Furthermore, the system can also classify and weight the flow records according to item category, for example, assigning different weight coefficients to enhancement materials and experience items used for character growth, and purely decorative items, thereby more accurately reflecting the main character's true dependency on specific auxiliary characters.

[0034] Optionally, task execution records are used to track the task types, completion frequency, and time distribution of multiple related characters to support a quantitative assessment of repetitive labor intensity. Optionally, task execution records may include, but are not limited to, daily dungeon completion records, wilderness resource gathering logs, crafting queue completion records, and trading stall duration records. In addition to recording the basic task type identifier, these records may also include the character's level, equipment rating, and the associated identifier of the task chain at the time the task is triggered. Considering that the same task may have different operational complexities at different levels, as a possible implementation, the system can pre-set repetitive labor weights for various tasks: for example, assigning higher weights to wilderness mining tasks that require manual navigation and repeated clicking of the gathering button, and lower weights to escort tasks that only require clicking to participate and are automatically advanced by the system. Based on this, when calculating the repetitive labor intensity index, the aforementioned task execution records will be summarized in conjunction with weight coefficients, thereby avoiding homogenized measurement of high and low level tasks caused by simply relying on the number of tasks, making the assessment results of repetitive labor intensity closer to the player's actual operational burden.

[0035] Optionally, the switching pulse record is a lightweight interactive capture entry triggered at the moment of character switching, used to capture the switching interval and the context of incomplete tasks.

[0036] Optionally, the switching pulse record can be a structured data packet generated instantly by the client when the user confirms the role switching operation. It can be triggered during the transition between the role selection interface and the scene loading interface, or when the user is detected forcibly returning to the login interface to reselect a role. Considering that relying solely on server session logs in practical applications makes it difficult to accurately capture the extremely short time interval between two valid operations and the instantaneous task status before the switch, as a possible implementation, the pulse record, in addition to including the identity identifiers of the source and target roles, can also include the switching interval in seconds, the context of unfinished tasks before the switch (e.g., the progress of an ongoing data collection bar, the list of uncollected rewards in the instance), and user input feedback in the lightweight switching pulse bar that pops up on the client side. One objective of this embodiment is that by explicitly marking high-frequency switching segments (e.g., switching intervals less than 30 seconds) as pulse records, key behaviors can be captured without intruding on the user's normal visual experience. Furthermore, cross-validation with background logs can improve the accuracy of identifying abnormal batch operations.

[0037] Optionally, in addition to basic fields such as switching interval and task context, the switching pulse record may also include the coordinates of the scene at the time of switching, network latency indicators, and client frame rate performance before and after the switching. To avoid errors in switching interval calculation due to network jitter, which could lead to false high-frequency switching, the above method can dynamically correct the switching interval based on the network latency indicator when it detects that the switching interval is close to a preset threshold (e.g., between 25 and 35 seconds). If the network latency exceeds the preset standard, the actual interval is compensated to eliminate false high-frequency switching caused by loading time. Furthermore, for the incomplete task context attached to the switching pulse record, the system can perform conflict detection with the task status of the target role. If there is a need for continuous connection of the same task chain, a task continuation prompt window can be automatically popped up after the target role logs in, guiding the user to seamlessly continue the previously interrupted operation steps. It should be understood that the above pulse record collection method is not only applicable to desktop terminals, but can also be implemented on mobile terminals by detecting application foreground / background switching or role tab switching events. This disclosure does not limit this.

[0038] Optionally, the primary role dependency is used to characterize the proportion of resources transferred from each secondary role to the primary role relative to the total flow within the account, in order to identify the primary-secondary relationship.

[0039] Optionally, the main character's dependency can be a normalized value calculated based on the number of directed transfers in the resource flow records. This value is related not only to the supply of a single auxiliary character but also to the total resource flow of all characters within the account. Specifically, the calculation process may include: obtaining the cumulative number of various virtual items flowing to the main character within a preset statistical period; obtaining the total flow between all characters within the account within the same period; dividing the two and then truncating by an upper limit to obtain a dependency value between 0 and 1. To avoid distorting the true dependency relationship due to the massive flow of a certain type of low-value resource, as a possible implementation, the system can pre-exclude flow records of items already marked as junk items or test items, or set a flow upper limit cap for items of different grades. Furthermore, when multiple auxiliary characters exist, the system can also calculate the independent dependency of each auxiliary character on the main character separately and display the calculation results in the form of a radar chart or bar chart on the collaboration panel page, allowing users to intuitively perceive whether the supply structure between the main and auxiliary accounts is balanced.

[0040] Optionally, the update frequency of the main character's dependency can be dynamically adjusted according to the maturity level of the collaboration profile: for accounts in the basic collaboration stage, the dependency can be recalculated on a weekly basis; for accounts in the deep collaboration stage, the update frequency can be shortened to a daily basis or even a single task cycle.

[0041] Optionally, the repetitive labor intensity index is used to measure the operational burden caused by high-frequency switching and repetitive tasks in multi-role operations, and serves as a reference for determining the assistance level.

[0042] Optionally, the repetitive labor intensity index can be a comprehensive score obtained by weighting and summing multiple parameters such as the count of repetitive actions, the frequency of character switching, and the proportion of high-frequency switching segments. Its purpose is to quantify the mechanical back-and-forth operations of players between multiple characters into a signal of burden reduction needs that the system can recognize. Specifically, the process of determining the index may include: obtaining the cumulative number of various repetitive actions (such as gathering, transporting, setting up stalls, and dungeon assistance) in collaborative segments and converting them into repetition scores; obtaining the total number of switching and the number of high-frequency switching in the switching pulse record, assigning different weights to each, and summing them into a switching score; obtaining the main character's dependency and mapping it to a dependency bonus score; and finally, adding the three scores and truncating them to an upper limit. To avoid drastic fluctuations in the index due to occasional changes in player operating habits, as a possible implementation, the system can use a sliding window mechanism to perform a moving average processing of the repetitive labor intensity index of multiple consecutive collaborative segments. Only when the smoothed index continuously exceeds a preset threshold will a prompt for reassessing the maturity of the collaborative profile or unlocking support capabilities be triggered.

[0043] Optionally, in addition to reflecting operation frequency and switching density, the repetitive labor intensity index can be further correlated with the task type complexity and time consumption distribution in the task execution record. For example, for highly repetitive tasks that require players to maintain attention for a long time (such as multiple consecutive collection loading bars), the weight coefficient of such tasks can be increased; while for low-value production queues that can be automatically promoted by the system, their scoring weight can be reduced accordingly. Furthermore, when generating dependency graphs, the repetitive labor intensity index can be used to adjust the visual attributes of graph connections: the connection between a secondary character and a primary character with a higher index can be marked with a striking color or dynamic flashing effect to indicate that the area is a key entry point for reducing the burden of support. It should be understood that the definition of repetitive labor may differ in different games, and the constituent parameters of the above index can be adaptively increased or decreased according to specific gameplay rules. This disclosure is not intended to exhaustively limit the specific terms in the calculation formula.

[0044] Optionally, a dependency graph is used to visualize resource supply and labor intensity between characters, intuitively reflecting the main-support collaboration structure within the account. Optionally, the dependency graph can be rendered as a directed graph with the main character as the central node and each support character as an outer node, where the weight of the directed connections between nodes is positively correlated with the main character's dependency, and the visual style of the connections is related to the repetitive labor intensity index. Considering that players may find it difficult to directly perceive the true collaboration status between main and support characters from numerical reports, as a possible implementation, the graph can be directly displayed in the background layer of the character grouping management area on the collaboration panel page, or it can be expanded as a pop-up window when the user clicks on a specific group. In addition to nodes and connections, the graph can also dynamically display the character's current online status, today's task completion progress, and remaining resource supply next to each node. One objective of this embodiment is to transform quantitative dependence and qualitative labor intensity into a topological relationship graph. On the one hand, this can help users quickly identify inefficient links and core supply chains in the current multi-open combination. On the other hand, it can enable the system backend to automatically recommend which linked task groups to unlock first based on the connectivity density and weight distribution of the graph when generating assistance rules, thereby achieving precise allocation of assistance resources.

[0045] In an optional implementation, a collaborative profile for the target game account is constructed, including determining the permission level of the collaborative profile based on the continuous collection duration of collaborative behavior data and the stability of dependency relationships. This approach, which comprehensively assesses permission levels based on continuous collection duration and dependency stability, objectively reflects the maturity of multi-role collaboration within the account, ensuring that the pace of opening collaborative management permissions matches actual user engagement and avoiding the risk of resource abuse caused by a one-size-fits-all approach to authorization.

[0046] In one specific approach, the system classifies the permission level of collaborative profiles based on the continuous collection duration of collaborative behavior data and the stability of dependency relationships. Specifically, if the continuous collection duration of multi-character collaborative behavior data for a target game account reaches a first duration threshold, and the fluctuation of the proportion of resources supplied by each associated character to the main character in the most recent statistical periods is within a preset stable range, then the system determines the permission level of the collaborative profile to be above basic collaboration; conversely, if the continuous collection duration is insufficient or the resource supply proportion fluctuates frequently, the initial permission level is maintained. For example, if a player's main character continuously receives resource transfers from a fixed auxiliary character for ten calendar days, and the resource supply proportion remains between 60% and 80% during this period, the system determines that its dependency relationship has a stable trend, and thus upgrades the account's collaborative profile from basic collaboration to stable collaboration level.

[0047] Optionally, the aforementioned continuous collection duration refers to the number of natural days the system continuously records the collaborative behavior of multiple roles under the same account, used to measure the sustained depth of user collaborative habits. Optionally, the aforementioned continuous collection duration can refer to the number of natural days or active session cycles elapsed from the first time the system detects collaborative behavior that meets preset conditions among multiple related roles under the control of the same user until the current statistical cutoff point. This continuous collection duration not only helps the system distinguish between occasional multi-role trial operations and real multi-account users with stable habits, but also forms a complementary verification with the stability of subsequent dependency relationships: when the continuous collection duration reaches the preset short-term observation threshold (e.g., three consecutive natural days), the system initially determines that the account has the basic conditions for multi-role collaboration; while when the continuous collection duration reaches the medium-to-long-term observation threshold (e.g., seven or fifteen consecutive natural days), the system further confirms that the user's multi-account behavior is not a temporary activity, thus providing a reliable time dimension basis for the permission level jump of the collaborative profile. It should be noted that the above-mentioned statistics of natural days are not limited to a complete 24-hour cycle. In actual implementation, the effective active hours or login sessions can also be used for equivalent conversion. This disclosure does not limit this.

[0048] Optionally, the aforementioned stability level characterizes the degree of convergence of the resource supply ratio and division of labor labels among roles within the cycle, in order to determine whether the collaborative structure tends to solidify.

[0049] Optionally, the stability of the aforementioned dependencies can be measured using various quantitative indicators, such as calculating the variance or standard deviation of the main role's dependency across multiple consecutive collaborative segments, or statistically analyzing the frequency of changes in the role assignment labels for production, transaction, and combat roles. Considering that users may frequently adjust resource allocation strategies and role assignments in the early stages of multi-role collaboration, as a possible implementation, the system can be configured to determine that the dependency has reached a stable state when the coefficient of variation of the main role's dependency across the last five collaborative segments is below 20% and the role assignment labels remain unchanged; conversely, if the main role's dependency fluctuates wildly or the role repeatedly switches between combat and production roles, the dependency is considered unstable. Furthermore, the determination of this stability can also incorporate a time-weighted factor, meaning that collaborative segments closer to the current time have a higher reference weight when calculating fluctuation amplitude, thereby avoiding excessive interference from early exploratory operations in the stability assessment.

[0050] Optionally, the above permission levels are the result of the system's hierarchical classification of collaborative files based on duration and stability, used for differentiated access to collaborative management permissions. Optionally, the above permission levels may include, but are not limited to, three levels: basic collaboration, stable collaboration, and deep collaboration. The basic collaboration level corresponds to the initial permission configuration, the stable collaboration level corresponds to the medium permission configuration, and the deep collaboration level corresponds to the high-level permission configuration. One-way or two-way transition channels can be set between different levels. When executing transitions, the system considers not only the two basic dimensions of continuous data collection duration and dependency stability, but also anomaly risk scoring for a comprehensive judgment.

[0051] Optionally, in actual implementation, the above permission level division is not limited to a three-level structure. It can also be expanded to four, five or more subdivisions according to business needs, or even sub-stages can be set within the same basic level. For example, deep collaboration can be further subdivided into deep collaboration beginner level and deep collaboration advanced level.

[0052] In step S250, based on the permission levels of the collaborative files, corresponding collaborative management permissions are granted to multiple associated roles, and a collaborative management interface is output. These collaborative management permissions include task progress sharing permissions and resource scheduling permissions. This dynamically releases support capabilities through permission level mapping and aggregates a unified management entry point for task progress sharing and resource scheduling at the front end. This transforms multi-role collaboration from decentralized operations to a visual server-side front-end interaction, effectively reducing repetitive work for multiple users and improving ease of operation.

[0053] For example, when an account's collaborative profile is rated as basic collaboration, the system only grants the account the permission to share task progress once a day, and the benefit reduction ratio is 30%. The remaining number of times is indicated in gray in the collaboration management interface. When the profile is upgraded to deep collaboration, the number of times it can be shared per day increases to five, the benefit reduction ratio decreases to five percent, and a complete interactive entry point for the resource scheduling panel is added to the collaboration management interface. Users can initiate the grouping and scheduling of gap resources with one click in the main control interface without switching clients.

[0054] Optionally, collaborative management permissions are used to grant related roles access to task progress sharing and resource scheduling capabilities based on file level. The daily available limit and benefit decay rate are dynamically adjusted according to the permission level. Optionally, collaborative management permissions include at least task progress sharing permissions and resource scheduling permissions; task progress sharing permissions allow a related role to synchronize part of its progress to other related roles under the same account after completing a daily gathering or escort task; resource scheduling permissions allow the primary role to send instructions to secondary roles to automatically connect to low-value production queues or preset supply packages when there is a shortage of virtual resources.

[0055] Optionally, the collaborative management interface aims to aggregate the grouping relationships, task status, and resource gap information of multiple roles in a visual form, and provide a unified interactive entry point for triggering collaborative management operations.

[0056] Optionally, the collaborative management interface is presented in the form of a collaborative panel page on the graphical user interface. This collaborative panel page includes at least a role grouping management area and a resource gap display area. The role grouping management area displays the current members and functional labels of each group in the form of cards or lists, and accepts drag-and-drop adjustments by the user to regroup. The resource gap display area displays the gap type and recommended supply role information in the main color with highlighted items. After the user clicks, a resource scheduling panel will pop up on the current page. The collaborative management interface can also display a permission level jump banner at the top to explicitly notify the user to unlock the preview of the newly added collaborative management permissions when the file is upgraded, avoiding the silent opening of assistance capabilities and resulting in insufficient user awareness. Furthermore, the above interface layout can be adaptively adjusted according to the terminal type. For example, on mobile terminals, the resource scheduling panel is displayed in the bottom drawer, and on desktop clients, the grouping relationship is displayed in a persistent side window. This disclosure is not limited to this.

[0057] like Figure 4 The diagram shown illustrates a collaborative management interface, displaying a player collaboration panel: The top title is "Collaboration Panel," and the status label is "Stable Collaboration." The "Current Character Group" area displays the status of the main character, production character, trading character, and dungeon support character, including the main battle character (online - blue), production character (gathering - green), trading character (setting up a stall - yellow), and support character (standby - gray). "Today's Collaborative Benefits" section: Shared progress - 60% collection, time saved - 42 minutes, remaining benefits - 72%; The "Recommended Source" section indicates that "Your main account is short of alchemy materials. You can use the low-value production queue of your production account, which is expected to save 18 minutes of repetitive operations." The progress bar shows 76%. The three buttons at the bottom are: One-click grouping (blue), Linked tasks (green), and Reward details (black).

[0058] In an optional implementation, based on the permission level of the collaborative profile, corresponding collaborative management permissions are granted to multiple associated roles. This includes configuring a daily limit on the number of times collaborative management permissions can be used and a percentage reduction in the benefits of shared task progress based on the permission level. By dynamically binding permission levels with the daily limit on the number of times permissions can be used and the percentage reduction in benefits, differentiated support can be provided to multi-account accounts at different maturity levels. This also effectively prevents studios from abusing the collaborative mechanism in large numbers while reducing their workload, thus maintaining the stability of the game's economic ecosystem.

[0059] In one implementation, when a user's collaborative profile is at the basic collaboration level, the system sets the daily limit for sharing task progress to 1 time, and the benefits after sharing are settled at 70% of the original value. When the profile advances to deep collaboration, the daily limit for available attempts increases to 5 times, and the benefit decay rate is adjusted to 5%, thereby achieving a balance between differentiated incentives and risk control. Optionally, the daily limit for available attempts is used to limit the cumulative daily frequency of collaborative management operations performed by associated roles under different permission levels.

[0060] Optionally, considering the objective differences in the maturity of account collaboration represented by different permission levels, the above-mentioned daily limit on the number of times can be configured in a tiered manner according to the permission level of the collaboration profile. In one approach, the daily limit on the number of times a multi-role account at the basic collaboration level can be set to a lower value, such as allowing only one task progress sharing operation per day; while for accounts at the deep collaboration level, this limit can be increased to five times or even more per day. It should be noted that the above values ​​are only examples, and in actual applications, they can be dynamically adjusted according to the adjustment needs of the overall economic ecosystem of the server. This embodiment, by binding the limit to the permission level, can effectively constrain the initial multi-account behavior with a short account nurturing cycle, preventing it from excessively consuming system resources; on the other hand, it can also provide more flexible operating space for highly active, highly trusted, experienced multi-account users, so that the allocation of support resources can accurately match the actual collaboration behavior profile of the account.

[0061] Optionally, the revenue decay ratio is used to determine the settlement loss factor when associated roles obtain virtual revenue through task progress sharing.

[0062] Optionally, to avoid the impact of high-frequency task progress sharing on the game's virtual economy, the aforementioned revenue attenuation ratio can be configured as a step-wise coefficient that decreases with increasing permission level.

[0063] In an optional implementation, the collaborative management interface includes a character grouping management area and a resource shortage display area. The character grouping management area displays the grouping relationships of multiple related characters and regroups these characters in response to grouping adjustment operations. The resource shortage display area displays resource shortage information for the main character and recommended supply characters. By dividing the collaborative management interface into two main areas—character grouping management and resource shortage display—players can intuitively control the division of labor among multiple characters and resource allocation, significantly reducing the time spent switching between characters one by one.

[0064] In one implementation, players open the collaborative management interface and can intuitively view the current grouping relationships of multiple related characters in the character grouping management area, including the affiliation status of the main combat group and the production group. When a player initiates a grouping adjustment operation, moving a combat-type character to the main combat group, the system responds to the operation by immediately completing the regrouping and refreshing and displaying the updated grouping relationships in a graphical manner in the character grouping management area. At the same time, the resource shortage display area at the bottom of the interface displays the resource shortage information in the main character's color in real time. For example, if the main combat character is short of 300 iron ore, this area displays the recommended supply character information, prompting that the gathering characters in the production group should transfer the ore. Thus, multi-character grouping management and resource demand coordination can be achieved simultaneously within a single interface.

[0065] Optionally, the role grouping management area is used to receive grouping adjustment operations and to regroup and display the relationships between multiple related roles.

[0066] Optionally, the aforementioned character grouping management area can be directly displayed on the left or central area of ​​the graphical user interface. Its presentation format includes, but is not limited to, a matrix-style avatar array, folded group cards, or a tree-structured directory. In one possible implementation, this area displays the main combat group, production group, and trading group side-by-side in a tab format. Within each group, thumbnail information and online status of each associated character are arranged horizontally or vertically. Players can initiate grouping adjustments by long-pressing and dragging, clicking and selecting, or using shortcut keys. Upon receiving this operation, the system immediately regroups the target characters and synchronously updates the grouping relationship display within the area.

[0067] like Figure 5The diagram shown illustrates a role grouping management area, showcasing drag-and-drop role grouping functionality: The top title is "Role Grouping," and the top right corner has a "Drag and Drop to Assign Roles" tab. "Main Combat Group / Production Group / Trading Group" Area: - Main battle group: Main account + auxiliary account (light blue background) - Production Team: Gathering + Alchemy (Light Green Background) - Trading Group: Stalls + Mail (Light Yellow Background) "Joint Quest: Daily Gathering" area: Description: "After the production account is completed, the associated character will share part of the progress, and the benefits will be reduced according to the rules." Progress bar display: Main account / 40% shared, Production account / Completed (green), Trading account / 20% ready for settlement; "Restricted Rules" area (yellow warning box): Daily limit of 3 times, decreasing rewards, requires real-name authentication and activity threshold; abnormal accounts will have their access level reduced. There is an "Anti-Abuse" label on the right. The three buttons at the bottom are: Save Group (blue), Share Progress (green), and Rule Details (black).

[0068] Optionally, considering that multi-account players often need to frequently switch between different characters to complete daily tasks, as a possible implementation, the aforementioned character grouping management area can also dynamically display the number of tasks completed today, the remaining amount of obtainable rewards, and the daily priority indicator for each group entry. One objective of this embodiment is to integrate progress and reward information in the grouping area, allowing players to assess the current status of each character without having to navigate to a secondary page. This reduces the jarring feeling caused by interface level transitions and provides data for regrouping. It should be understood that the display parameters of various information in this area can be dynamically switched according to the player's collaboration profile permission level at different stages of operation. For example, at the basic collaboration level, only the character name and group affiliation are displayed, while at the deep collaboration level, the estimated rewards and task queue are further displayed. This disclosure is not intended to limit the information density.

[0069] Optionally, the resource gap display area is used to display the resource gap information of the main character, and at least partially includes a visual representation of the recommended supply role information. Optionally, the aforementioned resource gap display area is typically located on the right or lower part of the graphical user interface, and it at least partially includes the main character's current resource gap information and the recommended supply role information.

[0070] Optionally, considering that players may miss items and the switching cost is high when manually searching the backpacks of each secondary character, in order to avoid resource scheduling delays caused by information dispersion, the above resource gap display area can further display the estimated delivery time and the number of collaboration attempts consumed while displaying the main character's resource gap information.

[0071] In an optional implementation, before regrouping multiple related roles in response to a grouping adjustment operation, the process includes: determining whether the number of roles in the target group exceeds the target group's capacity limit based on the number of roles in the grouping adjustment operation; outputting a "group full" message if the number of roles exceeds the capacity limit; determining whether the role's function tag matches the target group based on the recommended mapping relationship of the role's function corresponding to the target group if the function tag does not match the target group; and outputting a grouping suggestion message if the function tag does not match the target group. This not only prevents resource scheduling imbalances and gameplay mechanism conflicts caused by grouping overload, but also guides players to establish a reasonable multi-role division of labor structure through function adaptation verification, thereby improving the standardization and operational efficiency of grouping management in the server-side multi-instance support system.

[0072] In one example, a player triggers a group adjustment operation in a collaborative management interface, intending to drag a trading character to the main battle group. The front end verifies in real time whether the number of characters currently existing in the main battle group exceeds the preset capacity limit of the group. If the limit has been reached, a floating "Group Full" message is immediately displayed in the group slot area to prevent the character from being added. If the limit has not been reached, the system further calls upon the character's associated role tag and performs a suitability judgment based on the recommended mapping relationship of role roles corresponding to the main battle group. When a tag is detected that does not match the target group preference, a group suggestion prompt slides out from the bottom of the interface, showing that the character is more suitable for the trading group and asking whether the player still wants to include the character, waiting for the player to confirm or cancel the regrouping command.

[0073] Optionally, the target group is used to receive the set of roles assigned in the group adjustment operation and to undertake the corresponding collaborative task allocation. Optionally, the target group is the terminal carrier container pointed to in the group adjustment operation. It is presented in the collaborative management interface as a visual group card such as the main combat group, production group, or trading group. Each group has an independent capacity limit and role function preference settings. When the user triggers the movement of a character by dragging, clicking, or using the shortcut menu, the front-end interaction module uses the group as the placement target for real-time verification to determine whether its remaining capacity is sufficient to accommodate the adjusted character. It should be noted that the above division of the main combat group, production group, and trading group is only an example. In actual implementation, the target group can also be set as an exploration group, escort group, gathering group, or other custom group names according to the actual gameplay needs in the game. This disclosure does not limit the specific category and number of target groups.

[0074] Optionally, the capacity limit is used to restrict the number of characters that a target group can accommodate, in order to prevent the group from being over-expanded. Optionally, the capacity limit is a character capacity threshold set separately for groups with different functional divisions, and its value can be dynamically issued in the background based on the current economic environment of the server, the difficulty of the gameplay, and the overall activity level of the multi-account group.

[0075] Optionally, the "Group Full" notification is used to display a blocking message to the front-end interface when the number of characters reaches the capacity limit. Optionally, the "Group Full" notification can be presented in various visual forms on the front-end interface, such as a pop-up, floating bubble, or grayed-out overlay. It is triggered the instant the user completes the drag-and-drop action and the system determines that the number of characters already existing in the target group is equal to or exceeds the group's capacity limit. To avoid players misjudging successful placement due to network latency or interface refresh delays, the notification can be accompanied by a brief interface vibration or sound effect feedback to enhance the perception of preventing the loading. Furthermore, in addition to the basic text "Group Full," the "Group Full" notification can also display the current group name, actual number of characters, and specific values ​​of the capacity limit, such as "Main Battle Group Full (2 / 2)," thereby guiding players to release occupied slots or select other suitable target groups to re-execute the group adjustment operation.

[0076] Optionally, the role / function recommendation mapping relationship is used to establish a set of adaptation rules between function tags and groupings for rationality judgment. Optionally, the role / function recommendation mapping relationship is a set of rules automatically generated and continuously updated by the system after the collaborative profile construction module completes the identification of primary and secondary accounts and functional division of labor. It represents the grouping type that a role with a certain function tag is more suitable to reside in in the server-side multi-account support interaction system. Considering that multi-account players may temporarily schedule characters across groups due to short-term task needs, the above mapping relationship usually intervenes in the grouping process as a pre-suggestion layer rather than a mandatory blocking rule; this mapping relationship can be stored on the server in the form of a one-dimensional mapping table, key-value pair configuration file, or conditional branch statements in the rule engine. Furthermore, the role / function recommendation mapping relationship can also be dynamically corrected based on the historical grouping stability of the account's collaborative profile: if it is detected that a player continuously groups a specific trading character into the main battle group and produces positive collaborative benefits, the system can reduce the deviation weight of that character from the main battle group, or even generate a custom cross-function grouping permission for it.

[0077] Optionally, the above-mentioned role-recommendation mapping relationship can also adopt a tiered strategy based on collaboration maturity during actual deployment. This means that accounts at the basic collaboration level will be subject to stricter, rigid mapping rules, while accounts at the stable or deep collaboration levels will have a more flexible, adaptive mapping range. Specifically, when a basic collaboration account drags a production-type character into the main battle group, the system can directly intercept and output a strong prompt; while when a deep collaboration account performs the same operation, the system will only provide a soft reminder and allow the system to directly record the overwrite decision and synchronously update the division of labor stability parameters in the collaboration profile after player confirmation. This design aims to balance preventing abuse by botting studios with the operational flexibility of experienced multi-account users, avoiding excessive interference from a one-size-fits-all mapping rule on the normal multi-account experience.

[0078] Optionally, the function tag is used to identify the functional division of related roles, serving as a benchmark for comparing the role function recommendation mapping relationship.

[0079] Optionally, the function tag is a classification mark assigned to each associated role after identifying the primary and secondary accounts and assigning functions in the account collaboration profile construction module. Considering that the collaborative behavior of multiple roles may dynamically evolve with the game version or player needs, the tag can be automatically generated by the system based on the collaborative behavior data, or it can be initialized by manually selecting when the player creates a character for the first time or changes jobs.

[0080] Optionally, grouping suggestion prompts are used to output flexible guidance information when the function label does not match the target group.

[0081] Optionally, grouping suggestions can be displayed on the front end as a dashed breathing light, a bottom pop-up, or a side drawer. The trigger condition is that the system determines a deviation between the adjusted character's role label and the target group's preset role preferences. To avoid disrupting normal player operations, grouping suggestions typically do not forcibly terminate the grouping process. Instead, the suggestion text displays the recommended grouping type for the character, the potential impact on benefits or changes in collaboration attempts when grouping across groups, and provides two optional controls: confirm grouping and cancel with a recommended optimal group. If the player chooses to confirm grouping, the system records this overwrite decision and incorporates it into the grouping stability calculation in the account's collaboration profile. If the player chooses to cancel, the system can automatically return the adjusted character to its original position or recommend it to the optimal grouping slot indicated by the mapping relationship.

[0082] In an optional implementation, a risk score for the target game account is obtained; based on the risk score, collaborative management permissions are dynamically adjusted; specifically, when the risk score exceeds a preset risk threshold, the permission level is reduced or some functions of the collaborative management permissions are restricted. In this way, through the dynamic linkage between risk scores and collaborative permissions, not only can support capabilities be tightened promptly when abnormal, batch-based behavior is identified, but authorization can also be automatically restored after the risk recedes, effectively balancing multi-account experience and ecosystem security.

[0083] In one implementation, the system monitored the behavior of five associated characters of the account "Player A" and found that the account exhibited a highly synchronized data collection sequence during the early morning hours for three consecutive days, with resources all converging on the same main character. The clustering model marked this as an abnormal operation sequence and assigned it a risk score of 72. Since this score exceeded the preset risk threshold of 60, the system immediately downgraded the access level of its collaborative profile from "Deep Collaboration" to "Basic Collaboration," simultaneously disabled the automatic production queue attachment function, and reduced the daily limit for sharing collaborative task groups from 5 times to 1 time, decreasing the benefit attenuation rate from 95% to 70%. Over the next seven days, the account's operation mode returned to normal, the risk score dropped to 35, and after automatic verification each early morning, the system restored its access level to "Stable Collaboration" and reopened the daily sharing quota of 3 times.

[0084] Optionally, the risk score quantifies an account's tendency to engage in abnormal operations, dynamically calculated based on cluster analysis of collaborative behavior data. Optionally, the risk score can comprehensively reflect multiple dimensions of abnormal characteristics of the target game account within a specific statistical period, such as operational regularity, resource concentration, and character switching synchronization. To avoid directly exposing specific risk control rules and preventing studios from specifically bypassing monitoring, the risk score can be presented as an aggregated index, concealing the underlying labels and presenting only a numerical range to the backend decision-making module. In actual calculation, the system can cluster the operation timestamp sequences in the collaborative behavior data to identify whether there are abnormal operation sequences where multiple characters perform homogeneous tasks within a fixed time window.

[0085] Optionally, considering the potential overlap in operational habits between normal multi-account players and studio accounts, to avoid misjudgments due to short-term, occasional clustering of behavior, the risk score update mechanism can incorporate a cooldown buffer and a trend-weighted strategy. As a possible implementation, when the risk score exceeds a preset risk threshold, the system does not immediately implement a precipitous reduction in the support level. Instead, it first enters an observation period of one to three days, continuously collecting new collaborative behavior data and calculating the daily moving average of the risk score. When the moving average remains above the threshold for several consecutive days, the system officially lowers the access level. Furthermore, for accounts with risk scores in the moderate range (e.g., between 40 and 60 points), the system can subtly remind users of the reasonableness of their operation intervals in the collaborative management interface, rather than directly restricting their collaborative management permissions. This minimizes disruption to the experience of normal multi-account players while ensuring a healthy ecosystem.

[0086] Optionally, dynamic adjustment aims to reconfigure the parameters of collaborative management permissions in real time or periodically based on changes in risk scores. Optionally, dynamic adjustment can manifest as raising or lowering the assistance level, or selectively freezing or unfreezing certain functions. Considering that frequent permission switching may affect players' operational expectations, as a possible implementation, the system can set a daily limit of one permission level adjustment, or uniformly execute batch adjustments corresponding to the previous day's risk scores during daily server off-peak hours (e.g., 3:00 AM to 5:00 AM).

[0087] Optionally, a preset risk threshold is used to determine the boundary for triggering permission downgrades. This threshold can be configured globally by the system or set differently based on account level. Optionally, the preset risk threshold is not limited to a single fixed value; it can be designed as a threshold system with multiple trigger tiers. As one possible implementation, the system can set a first threshold (e.g., 60 points) and a second threshold (e.g., 80 points). When the risk score exceeds the first threshold but is lower than the second threshold, the system progressively downgrades the assistance level, such as reducing deep collaboration to stable collaboration or basic collaboration. When the risk score exceeds the second threshold, the system directly determines it to be a high-risk state, restricting collaboration management permissions to the lowest available level or even completely freezing the entry point to the collaborative task group.

[0088] In an optional implementation, when collaboration management permissions are reduced or restricted, a collaboration restriction status prompt is displayed in the collaboration management interface; the prompt displays information on the remaining available attempts and collaboration recovery conditions. This way, by informing the user of the remaining attempts and recovery conditions through an interface status prompt when permissions are restricted, risk control details are avoided from being exposed, and users are guided back to compliant collaboration paths, enhancing the system's auditability and user trust.

[0089] In one implementation, when the system detects that a target game account's risk score exceeds a preset threshold due to high-frequency, bulk resource aggregation, the collaborative management permission is downgraded from stable collaborative to basic collaborative. At this time, a light red status bar indicating temporarily restricted collaborative capabilities appears at the top of the collaborative panel. The left side displays 2 / 3 of the remaining collaborative attempts for the day, and the right side indicates in small gray text that the restriction can be lifted after 7 consecutive days of normal activity. Clicking the status bar expands a brief explanation overlay, but does not present any specific risk control rules or details of the anomaly assessment. This ensures the user's right to know while preventing the leakage of anti-cheating strategies, guiding the player to restore full collaborative support capabilities through continuous compliant operations.

[0090] Optionally, the collaboration-restricted status prompt is used to display the available status and recovery instructions when permissions are restricted. It can be presented in the form of a status bar or a pop-up window.

[0091] Optionally, the collaboration restriction status prompt can be deployed in various visual forms within the collaboration management interface. For example, it can be configured as a horizontal status bar spanning the top of the page, rendered with a color scheme different from the normal functional areas, so that users can immediately perceive it when entering the collaboration panel. Considering that directly displaying specific risk control rule details might lead to reverse engineering of anti-fraud logic by the studio, the prompt content is designed to only include a factual statement of restricted permissions, quantitative information on the remaining available attempts, and a general description of the recovery conditions, without disclosing the specific data thresholds or judgment model parameters that trigger downgrades. Furthermore, the status bar can also be set as an interactive control. After a user triggers it, the system can overlay a semi-transparent overlay layer on the current page, loading more detailed explanatory text within it, but this explanatory text still adheres to the principle of not exposing the underlying rules. In other words, the core delivery goal of the collaboration restriction status prompt is to convey the fact of restriction and the compliance path, rather than explaining the reasons, thereby establishing a transparent understanding of the restrictions on the user side, while ensuring that the system's risk control security is not weakened.

[0092] Optionally, the triggering timing and display parameters of the collaboration-restricted status prompt can be dynamically adapted according to different risk score ranges. As one possible implementation, when the risk score only triggers a single downgrade of the assistance level, the above prompt can adopt a gentle reminder style, such as displaying it in a corner of the interface with a light-colored icon and text, while retaining all user interface operation permissions.

[0093] Optionally, the remaining available count information is used to display the number of collaborative operations that can still be performed within the current period, and can be dynamically calculated based on the permission level.

[0094] Optionally, the remaining available attempts information can be visualized in various ways within the collaboration-limited status prompt. Besides displaying the used attempts and total attempts as simple numerical scores, it can also be presented as a progress bar, a pie chart, or markers in a calendar view. Considering that players in multi-account collaboration scenarios need to quickly determine whether there are still remaining group scheduling or task progress sharing resources for the day, as a possible implementation, when the remaining available attempts are nearing exhaustion, the system can change the text color of this information from the usual black to a striking warning color, or add a flashing animation next to the numbers to enhance the sense of urgency. Furthermore, the remaining available attempts information can not only display the global total but also be displayed separately according to different sub-functions of collaboration management permissions. For example, the status prompt can list the remaining attempts for group scheduling, task progress sharing, and resource scheduling, allowing users to rationally plan the operation order of multiple roles based on the remaining resources for each function. It should be noted that the above-mentioned update logic for remaining available attempts can be synchronized with the server in real time, or a strategy of client-side local caching combined with timed refresh can be used to avoid putting pressure on the server due to high-frequency requests. In other words, the core function of this information on remaining available attempts is to transform abstract permission constraints into operational margins that players can directly understand, thereby assisting them in making collaborative decisions among multiple roles within the boundaries of the rules.

[0095] Optionally, collaborative recovery condition information is used to explicitly indicate the compliance behavior standards that need to be met to lift permission constraints, which may include the number of consecutive active days.

[0096] Optionally, the collaborative recovery condition information can be designed as descriptive text with different granularities to adapt to the user's cognitive needs at different stages of restriction. For example, in the initial stage when permissions are just restricted, the collaborative recovery condition information can only show general requirements, such as maintaining continuous normal activity to restore full capabilities; as the user gradually approaches the lifting threshold, the information can be refined into more specific progress expressions, such as the current continuous normal activity progress is more than halfway complete, or several more risk-free marker copies need to be completed. Considering that displaying overly precise recovery algorithms might be used by studios to test the system's boundaries, the above collaborative recovery condition information uses conditional, behavior-oriented natural language in its expression, rather than exposing specific numerical judgment formulas.

[0097] In an optional implementation, obtaining the risk score of the target game account includes: performing cluster analysis on collaborative behavior data to identify abnormal operation sequences; and determining the risk score of the target game account based on the characteristics of the abnormal operation sequences. In this way, by using cluster analysis to automatically identify patterns in collaborative behavior data, abnormal operation sequences that deviate from normal multi-account usage habits can be accurately extracted, thereby improving the objectivity and accuracy of the risk score and reducing the probability of misjudging normal users' multi-account behavior.

[0098] In one example, the system extracts all collaborative segments of a specific account within a preset statistical period, encoding the character switching sequence, resource flow path, and task execution frequency in each segment into a multi-dimensional feature vector. Then, a density-based clustering algorithm is used to group these feature vectors, classifying accounts with similar operational rhythms and resource aggregation patterns into one category. For isolated points in the clustering results that deviate from the normal player cluster, the system marks them as suspected abnormal objects and identifies continuous behavioral chains with characteristics of batch synchronous operations, high-frequency low-interval switching, and unidirectional resource aggregation as abnormal operation sequences. Finally, the system calculates the risk score of the target game account based on multiple characteristics such as the duration of the abnormal sequence, the number of characters involved, and the degree of abnormal resource aggregation.

[0099] Optionally, cluster analysis aims to unsupervised pattern grouping of multi-dimensional collaborative behavior data, thereby identifying discrete operation clusters that deviate from normal multi-operation habits.

[0100] Optionally, the clustering analysis described above can be a grouping operation performed on the multidimensional feature vectors corresponding to the collaborative behavior data. These multidimensional feature vectors can be composed of at least one parameter among switching pulse timing, resource flow direction, frequency of repeated behaviors, and main / auxiliary role switching intervals. Considering that multiple roles controlled by the same real user typically exhibit orderly patterns of operational intervals and resource complementarity that conform to physiological laws, and that batch-controlled studio accounts often exhibit clustering characteristics of mechanical synchronization, low-interval rotation, and unidirectional resource convergence, as a possible implementation, the system can use density-based spatial clustering algorithms or partition-based mean clustering algorithms to automatically cluster collaborative segments of massive numbers of accounts, grouping accounts with similar behavioral patterns into one category without the need for pre-labeled samples.

[0101] Optionally, an abnormal action sequence refers to a continuous chain of actions or a combination of temporal behaviors that deviate from normal player habits and are extracted based on clustering results.

[0102] Optionally, the aforementioned abnormal operation sequence can manifest as a high-frequency character switching chain within a specific time window, a unidirectional resource dumping path of multiple characters on the same main character, or a batch synchronization chain in which multiple characters repeatedly execute the same type of collection or transportation tasks at fixed time intervals. To avoid misjudging concentrated operation periods of normal multi-account players as bot behavior, the above identification process can be combined with the contextual semantics of the operation sequence, such as determining whether the sequence occurs continuously within a non-human physiologically appropriate duration, or determining whether there is a significant imbalance in the convergence ratio of resource flow.

[0103] Optionally, the characteristics of the abnormal operation sequence include the duration of the time sequence, the direction of resource flow and the convergence ratio, as well as the number of roles and the degree of deviation in functional division.

[0104] Optionally, the aforementioned features can specifically include the following dimensions: At the temporal level, abnormal operation sequences can have a combination of ultra-short switching intervals and ultra-long continuous online durations; at the resource level, they can manifest as a non-reciprocal, one-way, high-value transfer from auxiliary characters to main characters, with the transfer volume significantly exceeding the reasonable proportion required for normal development; at the character structure level, they can manifest as a large number of production-type characters converging towards a single combat-type character, but lacking normal character function interaction records. Based on these features, the system can establish a multi-dimensional scoring model to calculate a comprehensive risk score for each abnormal operation sequence; for example, sequences with a duration exceeding a set number of days, involving more than a preset upper limit of characters, and a resource convergence ratio reaching an abnormal threshold are assigned a higher risk weight. It should be noted that the specific numerical boundaries of the above-mentioned features are not fixed and can be dynamically adjusted according to the economic adjustment strategies of different game versions and the evolution of multi-account group behavior, thereby ensuring the continuous effectiveness of the risk scoring mechanism at the technical level.

[0105] In an optional implementation, the total output and transaction activity of the target group within a preset statistical period are obtained; based on the total output and transaction activity, the permission parameters of the collaborative management authority are dynamically adjusted globally. In this way, by monitoring the total output and transaction activity of the target group and making global dynamic adjustments, not only can the virtual economic ecosystem be balanced, but also abnormal batch outputs can be suppressed, thereby improving the stability of the support strategy.

[0106] In practical applications, the server backend automatically summarizes the total output and transaction activity of all multi-account player groups with established collaborative profiles on the current server within a preset statistical period each natural week. When it is detected that the total cumulative gold coin output of this group in a certain week has increased by more than a preset threshold compared to the previous week, and the circulation frequency of high-value items involved in the transaction has increased abnormally, the system determines that there is an inflation risk in the current economic ecosystem. Therefore, it automatically reduces the resource sharing benefit attenuation ratio of daily collection tasks in the collaborative task group from the original 85% to 70%, and simultaneously reduces the daily available number of times. This achieves global dynamic adjustment of the multi-account support permission parameters and avoids excessive consumption of server resources by batch operations.

[0107] Optionally, the target group mentioned above includes multiple game accounts that have established collaborative profiles, used to provide sample data required for global statistics. Optionally, the target group mentioned above does not refer to all players on the server in general, but rather to a specific set of accounts that have been identified by the system and have established collaborative profiles, that is, a user group that has a main character and at least one auxiliary character and continuously generates multi-character collaborative behavior data.

[0108] Optionally, the above-mentioned preset statistical period is used to define the statistical time window, which can be a natural day, a natural week, or a season cycle.

[0109] Optionally, considering the obvious periodicity and regularity of fluctuations in the virtual economic environment, the aforementioned preset statistical period can be flexibly adapted to different macroeconomic control needs. For example, the preset statistical period can be a natural week to match players' fixed activity habits and the rhythm of in-game periodic task refreshes; alternatively, the preset statistical period can be set as a complete season cycle or monthly settlement cycle to smooth out interference caused by abnormal daily data fluctuations. It should be noted that the start and end points of the statistical period can be configured by the server backend according to specific operational needs, such as from 00:00 on Monday to 24:00 on Sunday, or from 00:00 on the first day of each month to 24:00 on the last day. By setting a reasonable statistical period, a stable and reliable time benchmark can be provided for subsequently judging whether the total output and transaction activity of the target group exceed the normal range, reducing misjudgments caused by instantaneous peaks.

[0110] Optionally, the total output mentioned above includes the sum of the total amount of virtual resources acquired, the increase in currency, and the output of items accumulated by the target group during the period.

[0111] Optionally, the aforementioned total output is a key indicator for measuring the impact of the target group on the overall resource supply of the server. Its statistical scope can cover various virtual resources involved in multi-role collaborative behavior. In one implementation, the total output can be the cumulative amount of gold coins, raw materials, and tradable items obtained by the target group during the statistical period through daily collection activities, production queue operations, and dungeon clearing. In another implementation, it can further focus on the additional incremental output generated after sharing progress through collaborative task groups, in order to accurately assess the actual contribution of the server-side support mechanism itself to resource expansion. To avoid distorting the overall data due to the extreme behavior of individual accounts, the aforementioned total output can be subjected to mean smoothing or quantile denoising before global dynamic adjustment. That is to say, the backend not only focuses on the absolute value of output, but also normalizes and compares the total output with the total active time of the target group, thereby identifying batches with abnormal output efficiency per unit time.

[0112] Optionally, the above-mentioned transaction activity represents the frequency of resource exchange, which may include the number of transactions, the frequency of asset turnover, and the market order response rate.

[0113] Optionally, the aforementioned transaction activity can comprehensively reflect the level of activity in which virtual resources produced by the target group flow into the game's economic cycle from multiple dimensions. As one possible implementation, this transaction activity can be a weighted average of the number of transactions completed by the target group in the trading post or stall system and the total transaction amount. As another implementation, it can also reflect the frequency of high-value items being transferred from production group characters to trading group characters and then to the external market. Considering the close causal relationship between transaction activity and total output, when the backend detects a significant increase in total output and a corresponding rise in transaction activity, the system can determine that a large amount of resources generated by multi-client collaboration is rapidly entering the circulation field. To avoid misjudging normal trading surges caused by holiday events or version updates as abnormal, the aforementioned transaction activity can also be standardized and corrected by combining it with the benchmark trading level of all players on the server during the same period, thereby improving the accuracy of global dynamic adjustments.

[0114] Optionally, the above permission parameters include one or more of the following: daily maximum number of uses, revenue decay rate, unlocking conditions, and group capacity limit. Optionally, the above permission parameters are a quantitative expression of the server-side assistance rules at the specific numerical level, which defines the rigid boundaries of multi-role collaborative management in terms of operation frequency and revenue returns.

[0115] Optionally, to enhance the flexibility and executability of global dynamic adjustments, the aforementioned permission parameters can be further subdivided into hard constraint parameters and soft guidance parameters. Hard constraint parameters can include daily maximum usage limits and group capacity limits; adjustments to these parameters will directly block operation requests exceeding the thresholds. Soft guidance parameters can include the reward decay ratio and the compensation multiplier for expected delivery time; adjustments to these parameters are more about incentivizing player behavior and raising psychological expectations. In practical applications, when the backend detects low server inflation risk, the reward decay ratio can be lowered first to increase the sense of gain for players using multiple accounts; conversely, when signs of mass abuse by studios are detected, the daily maximum usage limit can be quickly reduced to create a hard interception at the operational level. Furthermore, the adjustment records of the aforementioned permission parameters can be stored on the server in an immutable log format for subsequent auditing, tracing, and reverse recovery, ensuring that every global dynamic adjustment is interpretable and rollbackable.

[0116] Optionally, the aforementioned global dynamic adjustment refers to the unified and automated updating of permission parameters across accounts and servers by the backend based on macro statistical data.

[0117] Optionally, the core of the aforementioned global dynamic adjustment lies in breaking through the limitations of the single-account dimension and macro-controlling the multi-account support mechanism from the overall perspective of the server or cluster. Unlike the micro-dynamic adjustment mechanism that targets the risk score of a single account, the aforementioned global dynamic adjustment focuses on addressing the systemic impact of collective behavior on the virtual economic environment.

[0118] like Figure 3 The diagram shows a multi-account support rule mechanism, whose interface is divided into several areas: Top data metrics: 148K collaborative segments, 62% stable collaboration, 3.8M time saving, 4.6% anomaly interception; The table in the middle, titled "Collaboration Maturity and Open Capabilities," displays four levels: - Basic collaboration: Sharing low-value daily tasks, twice a day, low risk level. - Stable coordination: Grouped settlement / supply packs, 3 times / day, low risk level. - Deep collaboration: Production queue connection, 5 times / day, medium risk level. - Risk restrictions: Reduce opening level to 0-1 times / day, high risk level. The "Assistance Capability Rules" in the lower left corner are: High repetitive work (open sharing of progress), stable division of labor (open grouping and settlement), active participation (open supply packs), and abnormal synchronization (restricted assistance level). The bottom right corner displays "Ecological Regulation Indicators": Total Output 74, Transaction Volume 68, Active Duration 82, Resource Convergence 44 (Yellow Warning), Abnormal Risk 21 (Red Warning). The bottom description states, "The backend dynamically adjusts the profit ratio based on output, transaction volume, and risk."

[0119] Optionally, to ensure the aforementioned global dynamic adjustments have sufficient predictive capability and fault tolerance, the system can undergo a buffer observation period for verification before executing parameter updates. During this buffer observation period, the backend continuously tracks the subsequent output and transaction trends of the target group. If the trend is confirmed, the parameter adjustments are officially implemented; if a data decline is detected, the warning is automatically canceled and the system reverts to the original parameter state. It should be understood that the triggering conditions for global dynamic adjustments are not only related to the total output and transaction activity, but can also be comprehensively weighted by combining the current total amount of virtual currency on the server and the average price of items in the mall, in order to form a more robust closed-loop control of the economic ecosystem.

[0120] In step S270, in response to a collaborative operation request for the collaborative management interface, the corresponding collaborative management operation is executed under the constraints of the collaborative management permission rules. By executing collaborative management operations under rule constraints, not only can the risk of abuse through multiple accounts be avoided, but it can also ensure that assistance activities remain within the server-side controllable regulatory boundaries, thereby effectively improving the system's security and fairness.

[0121] In one implementation, when a player triggers the one-click scheduling control for gap resources in the collaboration panel, the system receives a collaboration operation request. At this time, under the constraints of the daily limit and the profit decay ratio corresponding to the current collaboration management permission, the system sends a resource scheduling instruction to the production group role to attach to the low-value production queue and execute the corresponding collaboration management operation to complete cross-role resource replenishment.

[0122] Optionally, a collaborative operation request is used to trigger the execution flow of collaborative management operations, which is generated through the player's explicit authorization operation in the collaborative management interface.

[0123] Optionally, collaborative operation requests can be initiated by players clicking on a designated touch area in the collaborative management interface, or automatically submitted by the system when preset trigger conditions are met. Each collaborative operation request must include at least a request type identifier, a target character number, and associated operation parameters to ensure accurate server identification and distribution to the corresponding processing node. Considering the pressure on the server caused by mass malicious fraud, the front-end can perform local rule pre-checks before the request is officially sent to the server. For example, it can verify whether the current account's collaborative profile permission level supports the request type, or whether the current operation exceeds the daily limit. If the pre-check fails, it can be directly intercepted on the front-end with a prompt. Furthermore, the form of collaborative operation requests is not limited to click triggers; they can also be generated through voice commands, preset gesture trajectories, or keyboard shortcuts. This disclosure does not impose any limitations on this.

[0124] Optionally, rule constraints aim to limit the execution boundaries of collaborative management operations, which are dynamically determined based on the permission level and risk score of the collaborative profile. Optionally, rule constraints may include, but are not limited to, daily maximum number of uses, the attenuation ratio of shared task progress rewards, real-name authentication requirements, and character online status verification; these constraint parameters are not fixed but dynamically adjusted according to the maturity level of the collaborative profile. For example, when an account is at the basic collaboration level, only one data collection-type progress sharing is allowed per day with a high attenuation ratio; when the account advances to the deep collaboration level, the daily maximum number of uses increases accordingly, and the attenuation ratio decreases. Furthermore, if the system detects abnormal batch behavior of the account leading to an increased risk score, the rule constraints can be automatically tightened, for example, by temporarily lowering the attenuation ratio or restricting the execution of some high-value collaborative operations. It should be noted that the purpose of setting rule constraints is to reduce repetitive work for multi-account players while preventing studio accounts from using the collaboration mechanism to amplify profits without limit, thereby maintaining the stability of the overall virtual economic ecosystem.

[0125] Optionally, the collaborative management operation is determined based on the request type, and includes at least one of task progress sharing, resource scheduling, and group settlement operations. Optionally, the collaborative management operation can be a task progress sharing operation, whereby after a designated role completes part of the task, other related roles automatically obtain the corresponding progress synchronization, without needing to repeatedly execute the same collection or kill objectives; it can also be a resource scheduling operation, for example, where the system automatically identifies candidate supply roles based on the main role's resource shortage and sends scheduling instructions, causing production group roles to be attached to the corresponding production queue or preset supply package.

[0126] In an optional implementation, under the constraints of collaborative management permission rules, corresponding collaborative management operations are executed, including: obtaining resource gap information of the main role in the current task; determining the target supply role from candidate supply roles among multiple associated roles based on the resource gap information; and sending resource scheduling instructions to the target supply role, causing the target supply role to perform the corresponding production queue attachment operation or supply package preset operation. In this way, the target supply role is automatically matched and scheduling instructions are issued based on the main role's resource gap, eliminating the need for users to switch roles one by one. Cross-role resource flow is achieved through production queue attachment and supply package preset, significantly reducing repetitive work in multi-client scenarios and improving overall collaborative management efficiency.

[0127] In practical applications, when the main character is performing an equipment enhancement task, the system detects a shortage of meteorite resources. The collaboration panel automatically selects production-type characters with this type of resource from multiple related characters as candidate supply characters. Then, based on production capacity and delivery time, the target supply character is determined. Subsequently, a resource scheduling command is sent to the target supply character, so that it automatically joins the low-value meteorite production queue. Alternatively, the target supply character can preset the collected materials as supply packs and transfer them to the main character, thereby completing cross-account resource allocation without the main character leaving the current task interface.

[0128] Optionally, candidate supply roles are selected as backup roles with supply capabilities when the main role has a resource shortage. Optionally, candidate supply roles can be production roles within a production group with the ability to produce the corresponding materials, trading roles within a trading group holding the resource, or related roles automatically marked by the system based on historical resource flow records that have previously provided similar materials to the main role. The selection scope of the above candidate supply roles is not limited to a single group but can simultaneously cover supplyable objects in multiple groups. It should be noted that the number and specific identities of candidate supply roles can be dynamically adjusted according to the resource shortage type of the main role and the real-time inventory status of each related role; when multiple related roles have supply capabilities, the above multiple candidate supply roles can be sorted and displayed according to the expected delivery time or the number of collaborations consumed, so that subsequent steps can determine a unique target supply role, thereby avoiding the tedious operation of users manually searching for supplyable roles one by one.

[0129] Optionally, the target supply role is used to receive resource scheduling instructions and, once determined, to perform the corresponding resource transfer or production attach operation.

[0130] Optionally, the target supply role can be a single associated role manually selected by the user from the candidate supply role list, or it can be a unique supply role automatically matched by the system according to preset rules. These preset rules may include, but are not limited to, the shortest delivery time priority rule, the lowest number of collaboration consumption priority rule, or the highest remaining capacity priority rule. Considering that multiple users often want to reduce operational interruptions, as a possible implementation, after determining the target supply role, the system does not require the user to switch to the role's operation interface, but directly drives the role to execute subsequent resource scheduling tasks via background commands. Furthermore, if changes in the target supply role's inventory or capacity are detected before sending the resource scheduling command, resulting in insufficient capacity to complete the scheduling, the system can re-trigger the candidate supply role selection process and promote the second-best role to the target supply role to ensure the continuity and stability of resource scheduling.

[0131] Optionally, resource scheduling instructions are used to invoke the background capabilities of the target supply role, driving it to complete a targeted resource flow for the main character.

[0132] Optionally, the resource scheduling instruction can be a structured message carrying a resource type identifier, a target character identifier, and an operation type. This message is sent to the game server, where it is parsed and distributed to the client containing the target character, or a status change is performed directly on the server. The operation type can correspond to production queue attachment, supply package pre-setting, or a combination of both.

[0133] Optionally, the production queue hooking operation is used to enable the target supply role to automatically take on low-value continuous production tasks to fill the resource gap of the main role.

[0134] Optionally, the production queue assignment operation can automatically allocate idle production slots of a target supply role to a specified type of resource production task after receiving a resource scheduling instruction, without requiring the user to manually open the role's production interface for item-by-item configuration. The assigned production queues can include low-value and periodic production activities such as ore smelting, herb cultivation, or material synthesis, aiming to utilize the idle capacity of auxiliary or production accounts to provide a stable source of resources for the main account. Considering the differences in production capabilities among different roles, as a possible implementation, the production queue assignment operation can also dynamically calculate and select the optimal production plan based on the target supply role's skill level, current energy value, and the number of queues already occupied. Furthermore, when a production task is completed or the main role actively cancels the demand gap, the system can automatically unattach the queue and reclaim the corresponding production slot to prevent the target supply role's capacity from being occupied ineffectively for an extended period.

[0135] Optionally, the supply pack preset operation allows the target supply character to pre-package specified resources and deliver them to the main character when necessary. Alternatively, the supply pack preset operation can involve the target supply character packaging and encapsulating specified resources already held in their own inventory to generate a resource pack for the main character's role to be transferred. This resource pack can be directly transferred to the main character's inventory or a designated temporary transit warehouse after generation. The types and quantities of resources in the supply pack can be automatically determined based on the main character's resource shortage information, or can be manually fine-tuned by the user before confirming resource allocation.

[0136] In an optional implementation, before sending the resource scheduling instruction to the target supply role, the process includes: displaying a resource scheduling panel in the collaboration management interface, the resource scheduling panel including at least one of the following: a list of candidate supply roles, estimated delivery time information, collaboration count consumption information, and benefit decay warning information; and generating a resource scheduling instruction in response to a confirmation operation on the resource scheduling panel. By forcibly displaying the resource scheduling panel and receiving explicit confirmation before scheduling, players can fully perceive the boundaries and costs of collaboration rules, avoiding accidental triggers that could lead to irreversible flow, while simultaneously creating an auditable explicit authorization record, thus improving the security and compliance of assistance.

[0137] In practical applications, when the main character is short of healing potions while performing high-intensity dungeon missions, the player can click the "Recommended Source" tab next to the missing item in the collaboration management interface. The system will then display a resource scheduling panel in the form of a sliding drawer at the edge of the current interface. This panel displays a vertically arranged list of candidate supply characters, listing the portraits and names of multiple characters within the production group who possess the corresponding resources. Estimated delivery time is displayed as a dynamic countdown to the right of each character's entry. Collaboration attempt consumption is indicated by a prominent numerical badge showing the collaboration quota used in this scheduling. A benefit reduction warning explains the current benefit reduction percentage with supplementary text. After reviewing the above multi-dimensional information, the player can trigger a confirmation operation at the bottom of the panel. Based on this, the system generates a resource scheduling command and forwards it to downstream modules.

[0138] The resource scheduling panel is used to present multi-dimensional constraint information in the collaborative management interface and receive player review and confirmation to trigger the secure generation of resource scheduling instructions. Optionally, the resource scheduling panel can be presented directly as a modal window covering the current collaborative management interface, or as a non-modal drawer that slides out from the bottom or side edge of the interface. This disclosure does not limit its specific visual carrier form.

[0139] Optionally, considering the differences in screen sizes across different terminal devices and varying levels of player tolerance for information density, the information layout in the resource scheduling panel can be adaptively rearranged based on the number of characters within a group. For example, when the number of candidate supply characters is small, the character entries can be arranged in a horizontally expanded card array; when the number of candidate supply characters is large, a vertical list with a collapsible hierarchical structure is used. Furthermore, to reduce the cognitive burden on players when checking estimated delivery time and collaboration count consumption, the information in the panel can be displayed in priority zones with different color schemes. Information on collaboration count consumption can be highlighted with warm colors, while information on diminishing returns can be weakened with cool colors, allowing players to quickly grasp key decision-making elements and improve the accuracy and efficiency of collaborative scheduling operations.

[0140] The candidate supply character list is used to display a set of related characters who can supply resources within the resource scheduling panel, allowing players to compare and select sources. Optionally, the candidate supply character list can be arranged in a vertical list format on the left side of the resource scheduling panel, or it can be distributed at the top of the panel as a horizontally scrolling array of icons; this disclosure does not limit its specific arrangement. In one possible implementation, each entry in the list, in addition to displaying the character's name and avatar, may also include the name of the virtual scene the character is currently in, the spatial coordinate difference from the main character, and a dynamic label indicating whether the character is currently busy. If a candidate supply character is temporarily unable to respond to scheduling (e.g., in combat or already occupied by other cooperative tasks), its corresponding list entry can be grayed out or semi-transparent, and the estimated time for the busy status to be lifted can be displayed next to the entry, thereby preventing players from making invalid choices.

[0141] The estimated delivery time information is used to quantitatively display the estimated time data for resource transfer in the resource scheduling panel, helping players judge the timeliness of scheduling.

[0142] Optionally, the estimated delivery time is related not only to the virtual spatial distance between the candidate supply character and the main character, but also to the traffic congestion of the selected virtual path, the movement speed attribute of the candidate supply character, and whether a virtual teleportation node is used. In one possible implementation, this information can be displayed in real-time as a dynamic countdown to the right of the corresponding supply character entry, or it can be displayed as static interval text (e.g., approximately 3 to 5 minutes). Considering that sudden regional events in the game (such as temporary closures or monster attacks) may extend the actual delivery time, the estimated delivery time information can also be associated with a fluctuation range indicator. When the path risk level is high, the upper limit of the displayed time is automatically expanded, and a risk warning is provided with an auxiliary icon. In other words, players can decide whether to immediately execute the dispatch or wait for the path to recover based on the real-time changes in this information, thereby avoiding mission interruptions caused by blind confirmation.

[0143] Among them, the information on the number of collaboration attempts consumed is used to clearly indicate the amount of collaboration quota used in this scheduling in the resource scheduling panel, helping players to rationally plan their usage rhythm for the day.

[0144] Optionally, the display format for collaboration usage consumption information can be a numerical badge, a progress bar preview, or a real-time deduction animation of remaining usages. Its display position can be embedded in the title bar area of ​​the resource scheduling panel or placed adjacent to the confirmation operation controls. In one possible implementation, this information is not displayed in isolation but is linked to the number of times used and the maximum number of remaining available usages in the account's collaboration profile for the day. For example, it may appear as a composite text format: X usages consumed this time and Y usages remaining today divided by Z usages. To prevent players from making hasty decisions when collaboration usages are about to run out, when this scheduling operation will cause the remaining usages to fall below a low threshold (e.g., 1 or 2 usages remaining), the above information can be enhanced with a flashing effect or a pop-up prompt to guide players to prioritize addressing the most pressing resource gaps. It should be understood that the collaboration usage consumption coefficients corresponding to different permission levels may differ; therefore, the consumption information displayed in the panel has already been converted for the current profile permission level, and players do not need to perform the conversion themselves.

[0145] The benefit reduction notification is used to inform players in advance of the percentage reduction in benefits for this collaborative operation in the resource scheduling panel, ensuring players' right to know about the rules. Optionally, the benefit reduction notification can be presented as a percentage number, a discount label, or a multi-level color progress bar. Its display area can be located in the bottom description bar of the resource scheduling panel, or it can be triggered as a floating bubble when the player focuses on a candidate supply character.

[0146] The confirmation action is intended as an explicit authorization action after the player reviews the resource scheduling panel, ensuring that the generation of resource scheduling instructions is based on informed consent.

[0147] Optionally, the confirmation operation can be triggered by a confirmation button at the bottom of the resource scheduling panel, a gesture slider, or a biometric recognition control, the specific form of which can be adapted to the hardware capabilities of the terminal device. In one possible implementation, considering that resource scheduling involves the transfer of virtual assets across roles, the above confirmation operation can be designed as a two-level confirmation mechanism. That is, after the player clicks the confirmation button for the first time, a second confirmation pop-up window appears in the center of the panel, displaying a summary of the core elements of this scheduling. The player performs the final confirmation operation in this pop-up window, and the system generates a resource scheduling instruction accordingly. To avoid duplicate submissions due to network jitter or interface lag, the confirmation operation control can be grayed out and locked after being triggered for the first time, and will only become available again after the server returns a feedback signal that the instruction has been successfully received.

[0148] In an optional implementation, the number of times the target game account has performed collaborative management operations within a target period is obtained; the number of times used is compared with the daily available limit; if the number of times used is less than the daily available limit, the collaborative management operation is performed; if the number of times used reaches the daily available limit, the collaborative operation request is rejected. In this way, by periodically controlling the number of collaborative operations, not only can the overuse of multi-account mechanisms be effectively prevented, but a quantifiable dynamic balance threshold can also be established between the game's economic ecosystem and reducing the burden on players.

[0149] For example, if a target game account has already performed two collaborative management operations on the same day, when the system responds to the third collaborative operation request, it first retrieves the number of times the account has used the operation within the current target period and compares it with the preset daily limit. Since the current number of uses is two, which is less than the limit of three, the system confirms the execution of the collaborative management operation. However, when the account subsequently initiates a fourth request on the same day, the system determines that the number of uses has reached the limit, immediately rejects the collaborative operation request, and sends a message to the front end that the daily limit has been exhausted.

[0150] Optionally, the number of uses is used to reflect the collaborative quota consumed by the target account within the period, providing a counting basis for permission verification.

[0151] Optionally, the statistical range of used counts can be accumulated on a rolling basis with the target period as the boundary. This includes not only the consumption of task progress sharing operations, but also the invocation counts of resource scheduling operations, grouping and settlement operations, or other types of collaborative management operations. This disclosure is not intended to limit this. It should be noted that the above-mentioned record of used counts can be stored in a persistent database or temporarily saved using a cache counter with an expiration time. The specific storage medium can be flexibly configured according to the account activity scale and system load. Considering that multiple players may trigger multiple collaborative requests intensively during peak hours, as a possible implementation, the system can immediately perform an atomic auto-increment update after each collaborative operation is completed to avoid the failure of the upper limit control due to counting deviations in concurrent scenarios, thereby ensuring the accuracy and reliability of the limit verification.

[0152] Optionally, the initial value of the used count can be automatically reset to zero when the target period switches, or it can be periodically reset or the quota can be increased according to the global dynamic adjustment instructions in the system background. This disclosure does not limit the specific timing of its reset. Furthermore, in order to prevent the same collaborative operation from being counted repeatedly due to network jitter or repeated submissions from the front end, the above method can generate a unique sequence identifier for the request after receiving the collaborative operation request, and check whether the sequence identifier has been processed before incrementing the used count; if it already exists, it is regarded as a duplicate request and the previous processing result is returned directly without adding additional used counts. In other words, the actual accumulation of used counts depends not only on the real collaborative needs initiated by the user, but also on multiple factors such as request deduplication mechanism and exception compensation logic, thereby ensuring strict rate limiting while reducing the damage caused by system fluctuations to the normal collaborative experience of players.

[0153] Optionally, the target period is used to define the cumulative window of the number of times the game has been played, and its duration can be flexibly configured according to regulatory requirements and player activity patterns.

[0154] Optionally, the start and end boundaries of the target period can be from midnight to midnight of a natural day, or a rolling time interval calculated from the moment a player first performs a collaborative management operation, or a fixed settlement interval coupled with the game server maintenance cycle. This disclosure does not limit its specific timing benchmark. It should be noted that the set length of the target period not only affects the statistical accuracy of the number of uses, but also directly relates to the player's perception of the collaborative assistance capability. As a possible implementation method, setting the target period to a shorter duration can more promptly respond to the player's flexible needs at different times, while using a longer period based on natural days makes it easier to align with the overall design of the daily available usage limit, reducing the complexity of backend billing and permission settlement. Furthermore, when the target period is about to end and the number of uses is close to the daily available usage limit, the system can also remind the player of the remaining quota for the current period through visual prompts in the collaborative management interface, so that they can reasonably arrange subsequent multi-role collaborative plans.

[0155] Optionally, rejecting a collaborative operation request aims to return a blocking response to the user when the collaborative consumption reaches the limit, thus forming a hard constraint boundary for the assistance rules. Optionally, the triggering condition for rejecting a collaborative operation request can be an equivalent state where the number of uses has reached the daily available limit, or it can be triggered when the number of uses exceeds the limit and exceeds the preset tolerance threshold, or it can be triggered in advance in conjunction with an abnormal increase in the account risk score. This disclosure is not limited to a specific judgment logic. It should be noted that when returning a rejection response to the user, the above method can be expressed in the corresponding function entry point of the collaborative management interface by graying out, locking icons, or pop-up restriction prompts, rather than simply discarding the request directly, so that the user can intuitively perceive that their collaborative ability has reached the stage limit. Considering that direct rejection may affect the player's task planning rhythm, as a possible implementation method, the system can push the remaining recovery time or the available quota for the next cycle to the front end at the same time as triggering the rejection, so that the player can adjust the resource allocation strategy among multiple characters accordingly and reduce the negative experience caused by sudden blocking.

[0156] A multi-role collaborative management device according to one embodiment of the present disclosure, such as Figure 6 As shown, the device may include: The acquisition module is used to acquire collaborative behavior data of multiple related characters in the game for the target game account; among them, multiple related characters include one main character and at least one auxiliary character; The module is used to determine the dependencies between multiple related roles based on collaborative behavior data and to build a collaborative profile for the target game account. The output module is used to grant corresponding collaborative management permissions to multiple associated roles based on the permission level of the collaborative file, and output the collaborative management interface; among which, collaborative management permissions include task progress sharing permissions and resource scheduling permissions; The execution module is used to respond to collaborative operation requests for the collaborative management interface and execute the corresponding collaborative management operations under the constraints of collaborative management permission rules.

[0157] In this way, the hierarchical access control progress sharing and resource scheduling based on collaborative archives can help reduce frequent switching and repetitive operations between roles, reduce redundant interactions between terminals and servers, improve the processing efficiency of multi-role collaborative management, and help alleviate the data processing pressure on the server caused by high-frequency status requests.

[0158] The specific details of each part of the above-mentioned device have been described in detail in the method section of the implementation plan. For any undisclosed details, please refer to the implementation plan of the method section, and therefore will not be repeated here.

[0159] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to exemplary embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0160] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure.

[0161] The following is a detailed reference. Figure 7 The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present disclosure. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 1201, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1202 or a program loaded from memory 1208 into random access memory (RAM) 1203. The RAM 1203 also stores various programs and data required for the operation of the electronic device. The processor 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An input / output (I / O) interface 1205 is also connected to the bus 1204.

[0162] Typically, the following devices can be connected to I / O interface 1205: input devices 1206 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 1207 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 1208 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1209. Communication device 1209 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 7 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0163] In particular, according to one embodiment of this disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, one embodiment of this disclosure includes a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication device 1209, or installed from memory 1208, or installed from ROM 1202. When the computer program is executed by processor 1201, it performs the functions defined in the methods described above in various embodiments of this disclosure.

[0164] Figure 7 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0165] This disclosure also provides a computer-readable storage medium in which the methods described in this disclosure can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium after being downloaded over a network. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0166] A portion of this disclosure can be applied to computer program products, such as computer program instructions, which, when executed by a computer, can invoke or provide methods and / or technical solutions according to this disclosure through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, and installation package files. Accordingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions; the computer compiling the instructions and then executing the corresponding compiled program; the computer reading and executing the instructions; or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0167] Although embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A multi-role collaborative management method, characterized in that, include: Obtain collaborative behavior data of multiple related characters in the game for the target game account; wherein, the multiple related characters include one main character and at least one auxiliary character; Based on the collaborative behavior data, the dependency relationships between the multiple associated roles are determined, and a collaborative profile of the target game account is constructed. Based on the permission level of the collaborative files, corresponding collaborative management permissions are granted to the multiple associated roles, and a collaborative management interface is output; wherein, the collaborative management permissions include task progress sharing permissions and resource scheduling permissions; In response to a collaborative operation request for the collaborative management interface, the corresponding collaborative management operation is executed under the rules constrained by the collaborative management permissions.

2. The method according to claim 1, wherein, The collaborative behavior data includes role switching records, resource flow records, and task execution records; the role switching records include switching pulse records. Determining the dependencies between the multiple associated roles includes: Based on the resource flow records, the main role dependency is calculated, which is used to characterize the proportion of resource supply from each associated role to the main role. Based on the switching pulse record and the task execution record, the repetitive labor intensity index is determined; Based on the main role dependency and the repetitive labor intensity index, a dependency graph of the multiple related roles is generated.

3. The method according to claim 2, wherein, The construction of the collaborative profile for the target game account includes: The permission level of the collaborative profile is determined based on the continuous collection duration of the collaborative behavior data and the stability of the dependency relationship.

4. The method according to claim 3, wherein, The step of granting corresponding collaborative management permissions to the multiple associated roles based on the permission level of the collaborative files includes: Based on the permission level, configure the daily maximum number of times the collaborative management permission can be used and the percentage reduction in benefits for task progress sharing.

5. The method according to claim 1, wherein, The execution of corresponding collaborative management operations under the constraints of the collaborative management permissions includes: Obtain the resource shortage information of the main character in the current task; Based on the resource gap information, a target supply role is determined from the candidate supply roles among the multiple associated roles; Send a resource scheduling instruction to the target supply role, causing the target supply role to perform the corresponding production queue attachment operation or supply package preset operation.

6. The method according to claim 5, wherein, Before sending the resource scheduling instruction to the target supply role, the following steps are included: The collaborative management interface displays a resource scheduling panel, which includes at least one of the following: a list of candidate supply roles, estimated delivery time information, collaborative number consumption information, and revenue decay prompt information. In response to a confirmation operation on the resource scheduling panel, the resource scheduling instruction is generated.

7. The method according to claim 1, wherein, The collaborative management interface includes a role grouping management area and a resource gap display area; The role grouping management area displays the grouping relationship of the multiple associated roles and regroups the multiple associated roles in response to grouping adjustment operations; The resource gap display area shows the resource gap information for the main character and the recommended supply role information.

8. The method according to claim 7, wherein, The response to the grouping adjustment operation before regrouping the multiple associated roles includes: Based on the number of roles in the target group during the grouping adjustment operation, determine whether the capacity limit of the target group is exceeded. When the number of characters exceeds the capacity limit, an output group is full prompt. When the number of roles does not exceed the capacity limit, the function tag of the role to be adjusted is determined to match the target group based on the role function recommendation mapping relationship corresponding to the target group. When the function label does not match the target group, a grouping suggestion prompt is output.

9. The method according to claim 4, wherein, The method further includes: Obtain the number of times the target game account has performed collaborative management operations within the target period; Compare the number of times used with the daily available number of times limit; if the number of times used is less than the daily available number of times limit, perform the collaborative management operation. When the number of uses reaches the daily available limit, the collaborative operation request is rejected.

10. The method according to claim 1, wherein, The method further includes: Obtain the risk score of the target game account; Based on the risk score, the collaborative management permissions are dynamically adjusted; Specifically, when the risk score exceeds a preset risk threshold, the permission level is reduced or some functions of the collaborative management permission are restricted.

11. The method according to claim 10, wherein, The method further includes: When the collaborative management permissions are reduced or restricted, a collaborative restricted status prompt is output in the collaborative management interface; The notification of limited collaboration status displays information on the remaining available attempts and collaboration recovery conditions.

12. The method according to claim 10, wherein, The process of obtaining the risk score of the target game account includes: Cluster analysis is performed on the collaborative behavior data to identify abnormal operation sequences; Based on the characteristics of the abnormal operation sequence, the risk score of the target game account is determined.

13. The method according to claim 10, wherein, The method further includes: Obtain the total output and transaction activity of the target group within a preset statistical period; The permission parameters of the collaborative management authority are dynamically adjusted globally based on the total output and the transaction activity.

14. A multi-role collaborative management device, characterized in that, The device includes: The acquisition module is used to acquire collaborative behavior data of multiple related characters in the game for the target game account; wherein, the multiple related characters include one main character and at least one auxiliary character; A construction module is used to determine the dependency relationships between the multiple associated roles based on the collaborative behavior data, and to construct a collaborative profile of the target game account; The output module is used to grant corresponding collaborative management permissions to the multiple associated roles according to the permission level of the collaborative file, and output the collaborative management interface; wherein, the collaborative management permissions include task progress sharing permissions and resource scheduling permissions; The execution module is used to respond to collaborative operation requests for the collaborative management interface and, under the rule constraints of the collaborative management permissions, execute the corresponding collaborative management operation.

Images