Game lineup sharing, trading method and system

Abstract

The application discloses a kind of game formation sharing, transaction method and system.The method, first player uploads formation configuration data and transaction condition, is stored into platform database after being qualified by checking.The formation is used, and system generates scene label according to the data of the battle.The second player requests recommendation, and system filters formation according to its player data and scene label, and shows in the form of card.The player selects target formation, and in the transaction confirmation interface, check through transaction condition, and import itself database after being qualified.The method breaks the traditional game isolated formation acquisition mode, reduces the learning threshold of the player unfamiliar with the skill and the skill of character, improves the efficiency and retention rate of passing through.Meanwhile, through transaction mechanism, high-level player is encouraged to share formation, and a benign sharing ecology is built.

Description

Technical Field

[0001] This invention relates to the field of game technology, specifically to a method and system for sharing and trading game lineups. Background Technology

[0002] In games that incorporate character collection and development elements, players need to strategically combine different virtual characters to form a powerful combat team to cope with various battle scenarios. A well-configured team can significantly improve a player's efficiency and win rate.

[0003] In current technology, in-game configurations are limited to single-player setups and fixed system recommendations, lacking mechanisms for sharing, interaction, and co-creation among players. This presents a significant barrier for novice players or those with limited resources to independently research and test efficient team compositions. Players need a deep understanding of the skills, attributes, and counter-relationships of virtual characters, and a substantial investment of time in trial and error. This makes it difficult for novice players to quickly acquire suitable, high-quality team compositions, resulting in a high gameplay barrier.

[0004] Therefore, there is an urgent need for a system and method that can be implemented within the game, supporting standardized uploading of lineup configuration data, quantitative evaluation of actual combat effects, intelligent recommendations, and secure transactions. Summary of the Invention

[0005] To overcome the shortcomings of existing technologies, this invention provides a method and system for sharing and trading game lineups. This method establishes a complete process from uploading lineup configuration data to trading, thereby lowering the barrier for players to acquire high-quality lineups. Players can quickly obtain battle-tested lineups without needing a deep understanding of virtual character skills and counter-relationships. Simultaneously, by setting trading conditions, high-level players are incentivized to share lineups, forming a healthy sharing ecosystem.

[0006] To achieve the above objectives, the technical solution adopted by this invention is: a method for sharing and trading game lineups, comprising the following steps:

[0007] In response to the first player's lineup configuration data upload operation triggered in the lineup upload interface, the lineup configuration data and the transaction conditions of the lineup configuration data are obtained. If the lineup configuration data meets the preset conditions, the lineup configuration data is stored in the platform database. The lineup configuration data includes virtual character formation information, and the transaction conditions include the resources required to obtain the lineup configuration data.

[0008] In response to the use of the lineup configuration data in the platform database, the corresponding battle data is obtained, and a scene tag for the lineup configuration data is generated based on the battle data. The historical data includes at least usage count data and battle result data.

[0009] In response to the lineup recommendation request triggered by the second player in the lineup recommendation interface, the player data of the second player is obtained, and based on the scene tag, lineup configuration data is filtered from the platform database and displayed in the lineup recommendation interface in the form of lineup cards;

[0010] In response to the second player's operation of obtaining the target lineup configuration data on the lineup card, the transaction conditions of the target lineup configuration data are displayed in the transaction confirmation interface, and after the verification is passed, the target lineup configuration data is imported into the second player's player database.

[0011] By employing the aforementioned technical solutions, a closed-loop process is constructed, encompassing data uploading, scene tag generation, filtering and recommendation, and trading. This transforms the traditional game model from one-on-one player research to fixed system recommendations. For players unfamiliar with virtual character skills and counter-relationships, it lowers the barrier to acquiring high-quality team compositions, thereby improving efficiency and player retention. Simultaneously, the trading conditions incentivize high-level players to share team compositions, fostering a healthy sharing ecosystem.

[0012] Furthermore, the scene tags for generating the lineup configuration data based on the battle data include:

[0013] Based on the usage data and battle result data of the lineup configuration data, the win rate and level completion efficiency of the lineup configuration data in specific battle scenarios are determined.

[0014] If the win rate is greater than or equal to the preset win threshold, the specific battle scenario will be marked as the suitable scenario for the lineup configuration data;

[0015] The scene tags are displayed in the lineup cards in the form of graphical tags, which include battle scene icons and win rate progress bars.

[0016] The above technical solution quantifies scene tags based on win rate and completion efficiency, rather than relying solely on the subjective descriptions of the uploader. This allows players to intuitively judge the compatibility of the team composition data with their own, significantly improving the efficiency of filtering and decision-making.

[0017] Furthermore, marking the specific battle scenario as an adapted scenario for the lineup configuration data includes:

[0018] The applicable scenarios are sorted in descending order based on win rate. If the win rates are the same, they are sorted in descending order based on completion efficiency.

[0019] The above technical solution ensures that when players are faced with multiple team composition recommendations, they can quickly identify the optimal team composition that suits them, providing players with a list of suitable team compositions based on tiers and reference value.

[0020] Furthermore, the method also includes:

[0021] According to a preset time period, obtain the usage change data of the lineup configuration data within the preset time period to determine the popularity of the lineup configuration data;

[0022] Based on the popularity, adjust the recommendation weight and / or transaction pricing of the lineup configuration data in the lineup recommendation interface;

[0023] The lineup card displays a popularity indicator, which dynamically changes its display based on the popularity value.

[0024] By introducing the above technical solution, a dynamic popularity evaluation mechanism based on the change in usage frequency within a time window is introduced. The recommendation weight and transaction pricing are dynamically adjusted based on popularity, enabling the system to respond in real time to the selection preferences of the player group and changes in the version environment. This prioritizes the exposure of the most recognized lineups, avoiding the problem of outdated lineups occupying the recommendation position for a long time and high-quality new lineups being buried.

[0025] Furthermore, the method also includes:

[0026] In response to the first player's modification operation triggered by the submitted lineup configuration data in the lineup management interface, the lineup editing interface is displayed, the updated lineup configuration data is obtained, and the updated lineup configuration data is used to replace the original lineup configuration data.

[0027] The above technical solution allows the first player to seamlessly update and replace the submitted lineup configuration data, making it convenient for them to optimize the lineup according to the game version or their own deepening understanding, thus ensuring the timeliness and high quality of the platform data.

[0028] Furthermore, the method also includes:

[0029] In response to a secondary creation operation triggered by any second player on the lineup configuration data in the platform database in the lineup details interface, a lineup editing interface populated based on the lineup configuration data is displayed, the newly generated lineup configuration data is obtained, the new lineup configuration data is uploaded to the platform database, and the derivation relationship between the new lineup configuration data and the original lineup configuration data is displayed in the lineup details interface in the form of a derivation relationship tree diagram.

[0030] The aforementioned technical solution supports players in creating secondary lineups based on existing lineups, and visualizes the derivative relationships between lineups using a tree diagram. This can stimulate players' co-creation activity, transforming the lineup system from isolated nodes into an organically connected knowledge graph. Players can trace the evolutionary history of lineups along the derivative chain, understand the thinking and basis of each change, and thus not only gain access to the lineups themselves but also learn the methodology of lineup construction, accelerating their growth from novice to expert.

[0031] Furthermore, the player data includes virtual character pool data and current level progress data;

[0032] The step of filtering lineup configuration data from the platform database and displaying it in the form of lineup cards on the lineup recommendation interface includes:

[0033] Based on the virtual character pool data and the current level progress data, the team configuration data that matches the player data is selected from the platform database as the suitable team;

[0034] The recommended lineup is displayed to the second player in the form of a lineup card in the lineup recommendation interface, and a one-click import control for the recommended lineup is provided on the lineup card;

[0035] In response to the second player's operation of expanding the lineup card, the gameplay explanation area and the virtual character development priority information area of ​​the lineup are expanded and displayed on the lineup card.

[0036] The above technical solutions ensure that the recommended team compositions are usable by the recommended players. At the same time, the accompanying gameplay explanations and development priority information reduce the understanding and decision-making costs associated with mastering these team compositions.

[0037] Furthermore, the lineup configuration data also includes lineup description information marked by the first player for the lineup configuration data, and the lineup description information includes at least one of the following: the core positioning of the lineup, the type of scene to be adapted, the required virtual character information, and historical win rate data;

[0038] The lineup upload interface includes a lineup formation area, a description information editing area, and a transaction condition setting area. The lineup formation area is used to configure the virtual character positions by dragging and dropping. The transaction condition setting area provides a drop-down control for resource type selection and a resource quantity input control.

[0039] Furthermore, the transaction conditions include at least one of the following: in-game currency amount, specified item type and quantity, and in-game virtual resource type and quantity;

[0040] The method further includes:

[0041] In response to the second player triggering a request in the transaction confirmation interface, a transaction guarantee progress bar is displayed in the transaction confirmation interface, and the resources paid by the second player are locked through the transaction guarantee mechanism set by the system.

[0042] In response to the confirmation that the target lineup configuration data has been successfully imported into the player database of the second player, the locked resources are transferred to the account corresponding to the first player, and the transaction fee is deducted from the transferred resources according to the preset transaction fee and profit distribution rules;

[0043] The transaction confirmation interface displays three status indicators in sequence during the transaction process: locked, importing, and transaction completed.

[0044] The above technical solution eliminates the trust barrier in direct transactions between players through system guarantees.

[0045] Furthermore, a multi-dimensional filter bar is provided in the lineup recommendation interface. The multi-dimensional filter bar includes at least one of the following: a win rate range slider control, a multi-select label control for adapting to the scene, and a selection control for the number of virtual characters required for the lineup. The multi-dimensional filter bar allows players to filter lineups using at least one filter control.

[0046] In response to the filtering operation triggered by the multi-dimensional filtering control, the filtering conditions are obtained, and the lineup configuration data is filtered from the platform database according to the filtering conditions. The filtered lineup cards are then dynamically refreshed and displayed on the lineup recommendation interface.

[0047] The above technical solution transforms team composition retrieval from passively receiving recommendations to actively filtering, allowing players to flexibly combine filtering conditions according to their own needs, thus significantly improving the efficiency and accuracy of team composition retrieval.

[0048] A system for sharing and trading game rosters, including:

[0049] The upload module is used to respond to the lineup configuration data upload operation triggered by the first player in the lineup upload interface, obtain the lineup configuration data and the transaction conditions of the lineup configuration data, and if the lineup configuration data meets the preset conditions, store the lineup configuration data in the platform database. The lineup configuration data includes virtual character formation information, and the transaction conditions include the resources required to obtain the lineup configuration data.

[0050] The labeling module is used to obtain the corresponding battle data in response to the use of the lineup configuration data in the platform database, and generate scene tags for the lineup configuration data based on the battle data. The historical data includes at least usage count data and battle result data.

[0051] The recommendation module is used to respond to the lineup recommendation request triggered by the second player in the lineup recommendation interface, obtain the player data of the second player, filter lineup configuration data from the platform database based on the scene tags, and display it in the lineup recommendation interface in the form of lineup cards;

[0052] The transaction module is used to respond to the second player's operation of obtaining target lineup configuration data on the lineup card, display the transaction conditions of the target lineup configuration data in the transaction confirmation interface, and import the target lineup configuration data into the second player's player database after verification.

[0053] An electronic device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0054] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method.

[0055] By employing the above technical solutions, the beneficial effects of the present invention are as follows:

[0056] 1. The game lineup sharing and trading method disclosed in this application constructs a closed loop process of data uploading, scene tag generation, screening and recommendation and trading, which changes the isolated mode of traditional games that rely solely on individual player research or fixed system recommendations. For players who do not understand the skills and counter relationships of virtual characters, it lowers the threshold for them to obtain high-quality lineups, thereby improving the efficiency of completion and player retention.

[0057] 2. The game lineup sharing and trading methods disclosed in this application can incentivize high-level players to share lineups through the setting of trading conditions, thus forming a healthy sharing ecosystem;

[0058] 3. The game lineup sharing and trading methods disclosed in this application allow the first player to seamlessly update and replace the submitted lineup configuration data, which facilitates the optimization of the lineup according to the game version or the deepening of their own understanding, and ensures the timeliness and high quality of the platform data.

[0059] 4. The game lineup sharing and trading methods disclosed in this application quantify scene tags with actual combat statistics, rather than relying solely on the subjective description of the first player. This allows the second player to intuitively judge the compatibility of the lineup configuration data with themselves, greatly improving the efficiency of screening and decision-making.

[0060] To make the above and other objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

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

[0062] Figure 1 This is a flowchart of the game lineup sharing and trading methods in this embodiment of the invention;

[0063] Figure 2 This is a schematic diagram of the lineup cards in an embodiment of the present invention;

[0064] Figure 3 This is a schematic diagram showing the unfolded lineup cards in an embodiment of the present invention;

[0065] Figure 4 This is a schematic diagram of the derivation relationship tree diagram in an embodiment of the present invention;

[0066] Figure 5 This is a block diagram of the game lineup sharing and trading system in an embodiment of the present invention;

[0067] Figure 6 This is a block diagram of an electronic device in an embodiment of the present invention.

[0068] The attached diagrams above are labeled as follows: 1. Lineup Card; 2. Scene Tag Area; 3. One-Click Import Button; 4. Gameplay Explanation Information Area; 5. Virtual Character Development Priority Information Area; 6. Derivation Relationship Tree Diagram; 7. Processor; 8. Storage; 10. Upload Module; 11. Interface Rendering Submodule; 12. Data Validation Submodule; 20. Labeling Module; 21. Battle Data Collection Submodule; 22. Data Aggregation and Calculation Submodule; 23. Scene Tag Generation Submodule; 30. Recommendation Module; 31. Player Data Reading Submodule; 32. Adaptation and Filtering Submodule; 33. Sorting and Recommendation Submodule; 34. Interface Rendering Submodule; 35. Multi-Dimensional Filtering Submodule; 40. Trading Module; 41. Trading Interface Submodule; 42. Trading Guarantee Submodule; 43. Import Validation Submodule; 44. Transfer and Settlement Submodule. Detailed Implementation

[0069] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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 are within the scope of protection of the present invention.

[0070] It should be noted that in the description of this invention, the terms "first," "second," etc., are used only for descriptive purposes and to distinguish similar objects; there is no order between them, nor should they be construed as indicating or implying relative importance. Furthermore, in the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0071] This application discloses a method for sharing and trading game rosters. By establishing an efficient data interaction channel between the game's underlying server, platform database, and client, a seamless ecological closed loop is constructed. The execution subject of this method can be a terminal device, such as a server, desktop computer, laptop, tablet, mobile phone, smartwatch, smart TV, or other electronic devices with data processing capabilities; this application is not specifically limited to any particular device. The method is deployed on the server side of the online game and communicates with the game client via standard network protocols.

[0072] like Figure 1 As shown, this method mainly includes the following four core steps:

[0073] Step S100: In response to the lineup configuration data upload operation triggered by the first player in the lineup upload interface, obtain the lineup configuration data and the transaction conditions of the lineup configuration data. If the lineup configuration data meets the preset conditions, store the lineup configuration data in the platform database. The lineup configuration data includes virtual character formation information, and the transaction conditions include the resources required to obtain the lineup configuration data.

[0074] Once the first player independently develops a lineup with high strength or unique tactical mechanics, they can log in to the in-game lineup exchange or shared lobby and click to enter the lineup upload interface.

[0075] The lineup upload interface includes a lineup arrangement area, a description information editing area, and a trade condition setting area. In the lineup arrangement area, the system reads the first player's current game lineup configuration data as initial input. The first player can adjust the positions of each virtual character in the grid by dragging and dropping. After each drag and drop operation, the system performs a position conflict check on the client to prevent duplicate placement in the same position. In the description information editing area, the first player writes the core positioning of the lineup, i.e., customizes the suitable scenario, and writes gameplay explanation text. In the trade condition setting area, the first player selects the trade currency using the resource type selection dropdown control.

[0076] After editing, the first player clicks the submit button. The system performs preset condition checks on the lineup configuration data, including but not limited to: whether all virtual characters in the lineup are legal and valid, whether the resource types and quantities in the transaction conditions are within the allowed range, whether the description information contains illegal content, and whether the lineup is duplicated. After the verification is passed, the system assigns a unique global identifier, namely the lineup ID, to the lineup configuration data, serializes the data, and stores it in the platform database.

[0077] Step S200: In response to the use of the lineup configuration data in the platform database, obtain the corresponding battle data, and generate scene tags for the lineup configuration data based on the battle data, wherein the historical data includes at least usage count data and battle result data.

[0078] The generation of scene tags relies on real-world data feedback after the lineup configuration data is actually used in the platform database. Whenever a player uses this lineup in a battle, the system records the basic data of that use and aggregates it to the data analysis service. The data records include detailed indicators such as: battle scene type and specific level identifier, battle result, completion time, number of surviving characters, and total damage dealt.

[0079] The scene tags used in step 200 to generate the lineup configuration data based on the battle data include:

[0080] Step 201: Obtain the usage count data and battle result data of the lineup configuration data.

[0081] The data analysis service aggregates usage data for each lineup configuration in the platform database according to a preset time period. Data is grouped by lineup ID and battle scenario identifier, and the total number of uses and wins for each lineup in each scenario is calculated. The preset time period can be set to execute the processing task every 15 minutes.

[0082] Step S220: Based on usage data and battle result data, determine the win rate and completion efficiency of the lineup configuration data in a specific battle scenario.

[0083] Win rate = Total number of victories ÷ Total number of uses × 100%. Simultaneously, the average time taken to clear each team composition in each scenario is calculated to determine the team's efficiency index. This efficiency is inversely proportional to the time taken for that team composition to defeat enemies or clear dungeons.

[0084] Step S230: Determine whether the win rate is greater than or equal to a preset win threshold. The preset win threshold can be set by the system administrator.

[0085] Step S240: If the win rate is greater than or equal to the preset win threshold, mark the specific battle scenario as the suitable scenario for the lineup configuration data.

[0086] In step S250, if the win rate is less than the preset win threshold, the scenario is not marked as a suitable scenario, and the next scenario is judged.

[0087] Step S260: Sort the adapted scenarios in descending order based on win rate. If the win rates are the same, sort them in descending order based on completion efficiency.

[0088] For example, the preset victory threshold is set to 60%. The usage data of the lineup configuration uploaded by the first player in various scenarios is as follows: In dungeon level 50, it was used 156 times, with 143 wins, a win rate of 91.7%, and an average completion time of 132 seconds; in dungeon level 48, it was used 89 times, with 78 wins, a win rate of 87.6%, and an average completion time of 118 seconds; in dungeon level 52, it was used 67 times, with 37 wins, and a win rate of 55.2%. The first two scenarios have a win rate greater than the 60% threshold and are marked as suitable scenarios. Sorted in descending order of win rate: dungeon level 50 (91.7%), dungeon level 48 (87.6%). The win rate in dungeon level 52 did not reach the victory threshold and was not marked.

[0089] Step S270: Generate scene tags. The scene tags are displayed in the lineup card in the form of graphical tags. The graphical tags include battle scene icons and win rate progress bars.

[0090] The system generates corresponding scene tag data for this lineup configuration data, including scene icon resource references and win rate progress bar parameter values. This scene tag data is cached along with the lineup configuration data for quick rendering and display in the lineup recommendation interface.

[0091] The above technical solution quantifies and characterizes the scenario adaptability of a lineup using real-world statistical data, rather than relying solely on the subjective descriptions of the uploader. In practical applications, players uploading lineups may provide inaccurate descriptions of the lineup's actual effectiveness due to boasting, exaggeration, or cognitive biases. This invention automatically collects actual combat data from all players using the lineup in various battle scenarios at the platform level, summarizing and calculating win rates and completion efficiency at each level. This allows for an objective and transparent quantitative presentation of the overall strength and scenario adaptability of each lineup. Battle scenario icons intuitively indicate which specific battle scenarios the lineup is suitable for, and a win rate progress bar visually displays the lineup's performance in that scenario, enabling players to quickly assess the quality of a lineup.

[0092] Step S300: In response to the lineup recommendation request triggered by the second player in the lineup recommendation interface, obtain the player data of the second player, filter lineup configuration data from the platform database based on the scene tag, and display it in the lineup recommendation interface in the form of lineup cards.

[0093] When the second player enters the lineup recommendation interface, the system receives the lineup recommendation request and starts the recommendation engine service to execute the processing flow.

[0094] The player data includes virtual character pool data and current level progress data. The system first reads the player's virtual character pool data, which includes detailed development status information such as character ID, level, star rating, awakening rank, and equipment level of all owned virtual characters; and current level progress data, such as having unlocked dungeon floors 1 to 5, of which the first 3 floors have been cleared, and floors 4 and 5 have not yet been cleared.

[0095] Based on the virtual character pool data and the current level progress data, team configuration data that matches the player's data is selected from the platform database as suitable team compositions. The system establishes the following query conditions: the required character set for the team composition should be a subset of the existing character set in the player's character pool; the team composition's suitable scene tags should include scenes related to the player's current level progress, such as level 4 or 5 of a dungeon. Team configuration data that meets both of these conditions is selected as candidate suitable team compositions.

[0096] The recommendation engine further combines the scenario tag data of each candidate lineup, especially the win rate data, popularity index data, transaction price data, and lineup release time in the corresponding scenario, and generates the final recommendation list ranking through a weighted ranking algorithm. The weighted ranking formula used in this embodiment is:

[0097] Recommended score = w1 × scenario win rate + w2 × popularity normalized value + w3 × time factor - w4 × price normalized value, where the weight values ​​of each item are flexibly configured by the system according to the operation strategy, for example w1=0.4, w2=0.25, w3=0.15, w4=0.2.

[0098] After sorting, the recommendation engine returns the top-ranked team compositions as team composition cards to the second player's client, where they are rendered and displayed in the team composition recommendation interface. For example... Figure 2 As shown, each lineup card 1 displays the following: lineup name and first player's nickname, thumbnail images of core characters, scene tag area 2, popularity indicator, and resource price tags required to acquire the lineup. A one-click import button 3 is provided at the bottom of the card. The scene tag area 2 includes adapted scene icons and a win rate progress bar.

[0099] A one-click import control for the adapted lineup is provided on the lineup card. In response to a second player's expansion operation on the lineup card, such as... Figure 3As shown, the gameplay explanation information area 4 is displayed on the lineup card 1. The gameplay explanation information area 4 is used to display the detailed strategy text and positioning diagram written by the first player, as well as the virtual character development priority information area 5. The virtual character development priority information area 5 displays the development priority of each character in a tiered list, guiding players to prioritize investing limited development resources in the characters that contribute the most to the overall strength of the lineup.

[0100] In step S400, in response to the second player's operation of obtaining the target lineup configuration data on the lineup card, the transaction conditions of the target lineup configuration data are displayed in the transaction confirmation interface, and after verification, the target lineup configuration data is imported into the second player's player database.

[0101] When the second player clicks the "Import with One Click" button 3 on the lineup card, the transaction confirmation interface slides in from the bottom of the screen as a half-screen pop-up. The top of the interface displays the lineup name and a summary of core information, while the middle displays the details of the transaction conditions.

[0102] The transaction conditions include at least one of the following: in-game currency amount, specified item type and quantity, and in-game virtual resource type and quantity. In this embodiment, the transaction condition is set to 50 diamonds. The system supports the first player in flexibly choosing a combination of multiple resource types for pricing, such as gold coins, enhancement stones, character fragments, limited exchange coupons, etc., in addition to diamonds, providing differentiated pricing space for lineups of different values.

[0103] In response to the second player's request to acquire resources on the transaction confirmation screen, a transaction guarantee progress bar is displayed on the screen. Through the system's transaction guarantee mechanism, the resources paid by the second player are locked. The transaction module performs a resource locking operation within the database transaction; 50 diamonds are transferred from the player's available balance to the frozen balance. These diamonds cannot be used for any other consumption until the transaction is completed. Simultaneously, a locking status indicator icon is displayed on the transaction confirmation screen.

[0104] After the resources are successfully locked, the interface switches to the import state and displays a progress bar filling animation. The server performs the lineup configuration data import operation: it reads the complete version of the target lineup configuration data and writes data such as the character selection list, position coordinate mapping, recommended equipment ID list, and skill point allocation scheme into the corresponding data table in the second player's player database. After writing is complete, the system performs an integrity check, comparing the consistency and integrity of the data before and after the write operation.

[0105] Upon confirmation that the target lineup configuration data has been successfully imported into the second player's player database, the locked resources are transferred to the account corresponding to the first player. After the integrity verification passes, 50 diamonds are deducted from the frozen balance, minus the transaction fee, and the remaining diamonds are credited to the first player's earnings account.

[0106] The interface switches to the transaction completed state and displays the message "The lineup has been successfully imported and can be used in battle formations." Players can view and use the newly acquired lineup configuration in the formation interface.

[0107] In some feasible embodiments, the method further includes a dynamic popularity assessment mechanism: according to a preset time period, the usage change data of the lineup configuration data within the preset time period is obtained to determine the popularity of the lineup configuration data.

[0108] The system backend executes a full popularity calculation task at preset time intervals. The calculation task reads the daily usage time series data for each lineup configuration within a past sliding time window (e.g., 7 days) and calculates the popularity index using the following formula:

[0109] Popularity = Total usage within the sliding time window × Trend coefficient. The trend coefficient reflects the direction of change in usage frequency and is calculated as follows: Trend coefficient = Average daily usage in the last 3 days ÷ Average daily usage in the last 7 days. If the trend coefficient is greater than 1, it indicates that the lineup's popularity has recently increased, and it receives an additional positive weighting on top of the total usage frequency; if the trend coefficient is less than 1, it indicates that the popularity has declined, and it receives a decay weighting.

[0110] Based on the popularity, the recommendation weight and / or trading price of the lineup configuration data in the lineup recommendation interface are adjusted. The popularity calculation result is normalized and mapped to the recommendation weight adjustment range, for example, between 0.5 and 2 times. The system automatically writes the adjusted recommendation weight into the weight parameter table of the recommendation engine. For lineups with dynamic pricing enabled, the system automatically adjusts their trading price according to the segment range of popularity: lineups in the top 5% popularity range have their prices automatically increased by 10% to 30% above the base price set by the first player; lineups in the bottom 20% popularity range have their prices automatically decreased by 10% to 20% to promote circulation.

[0111] The lineup card displays a popularity indicator, which dynamically changes its display based on the popularity value.

[0112] In some feasible embodiments, the method further includes a lineup configuration data update mechanism: in response to a modification operation triggered by the first player in the lineup management interface for the submitted lineup configuration data, a lineup editing interface is displayed, the updated lineup configuration data is obtained, and the updated lineup configuration data is used to replace the original lineup configuration data.

[0113] For example, the first player discovered that the defensive stat of their first virtual character in their uploaded team was reduced by 15%, causing the team's win rate in Abyss dungeons to drop from 91.7% to 78%. This player can log into the team management interface, find the team in their upload list, and click the edit button. The system displays the team editing interface, which is now populated with the currently effective team configuration data. The player replaces the first virtual character with a second virtual character and adjusts the equipment configuration of the healer character. After editing, clicking "Save Update" replaces the original data with the new version of the team configuration data, and adds an update log to the team's version history, recording the update time, update content, and update reason.

[0114] Other players who have previously acquired this lineup will receive a lineup update notification upon their next login. They can choose to sync with one click or keep the old version. The update mechanism iterates content while preserving the lineup's original historical battle data, scene tags, evaluation information, and other data assets, ensuring continuous and traceable version iterations of the lineup.

[0115] With the above technical solution, when the game version is updated, character attributes are adjusted, or players discover a better configuration, the first player does not need to delete the original lineup and resubmit. Instead, they can iteratively optimize the lineup based on the original lineup, maintaining the timeliness and accuracy of the lineup configuration data. At the same time, the existing historical usage data and evaluation accumulation of the lineup are preserved, maintaining the continuity of the lineup configuration data assets.

[0116] In some feasible embodiments, the method further includes a secondary creation and derivation tracing mechanism: in response to a secondary creation operation triggered by any second player in the lineup details interface for the lineup configuration data in the platform database, a lineup editing interface populated based on the lineup configuration data is displayed, the modified new lineup configuration data is obtained, and the new lineup configuration data is uploaded to the platform database.

[0117] In a real-world scenario, the second player, while browsing the lineup details interface, studied the first player's lineup but couldn't directly use it due to the lack of the first virtual character in their character pool. The second player clicked the "Re-creation" button in the lineup details interface. The system displayed a lineup editing interface pre-populated based on the lineup configuration data. The second player replaced the first virtual character with the second virtual character and adjusted their position from the center of the back row to the right to obtain a better skill release angle. New gameplay explanation text was also added to illustrate the changes in gameplay after the character replacement.

[0118] After submission, the system assigns a unique lineup ID to this new lineup configuration data, enters it into the platform database, and automatically establishes a derivation relationship record: Derivation source lineup ID = original lineup ID, creator ID = first player's account ID.

[0119] The lineup details interface displays the derivation relationship between the new lineup configuration data and the original lineup configuration data in the form of a derivation tree diagram. For example... Figure 4 As shown, the derivation tree structure Figure 6 The root node represents the original lineup. Branch nodes represent various versions derived by different players. In the details page of the original lineup, a new node is added to the tree diagram. Nodes are connected by lines with arrows, and the lines are labeled "Replace First Virtual Character → Second Virtual Character | Creator: Second Player". Any player can click on any node in the tree diagram to jump to the details page of the corresponding lineup, thus facilitating browsing and learning along the derivative chain.

[0120] The aforementioned technical solutions can stimulate collaborative creativity among players, allowing any player to trace the origins and evolution of a lineup along its derivative chain, and browse the various variations and improvements inspired by that lineup. This not only helps ordinary players quickly understand the design philosophy and improvement logic of lineups, but also enables them to grasp the general methodology and strategic thinking framework for lineup building while learning specific lineup configurations, thereby accelerating their growth from novice players to strategy masters.

[0121] In some feasible embodiments, the lineup recommendation interface also provides a multi-dimensional filter bar. The multi-dimensional filter bar includes at least one of a win rate range slider control, a scene-adaptive multi-select label control, and a virtual character selection control required for the lineup. The multi-dimensional filter bar allows players to filter lineups using at least one filter control.

[0122] The win rate range slider control allows players to set a minimum and maximum win rate range, such as only displaying lineups with a win rate between 80% and 100%. The double-ended drag handle of the slider makes adjusting the range extremely convenient and intuitive. The recommended list refreshes in real time during dragging, allowing players to immediately perceive the impact of changes in the filtering criteria on the quantity and quality of the results.

[0123] The multi-select tag control for adapted scenarios displays various battle scenarios in the game in the form of tagged buttons. Players can select one or more adapted scenario types of interest, and the system will filter out the lineup that matches the adapted scenario with the selected tag.

[0124] The virtual character selection control for team composition allows players to specify the types of virtual characters required for their team. This is especially helpful for players with a limited character pool, allowing them to quickly filter out the virtual characters needed to fit their team composition and prioritize options with lower requirements for team building.

[0125] In response to a filtering operation triggered by the multi-dimensional filtering control, filtering conditions are obtained, and lineup configuration data is filtered from the platform database according to the filtering conditions. The filtered lineup cards are then refreshed and displayed on the lineup recommendation interface. The core technical feature of the multi-dimensional filtering bar is that it supports the free combination and use of multiple filtering controls. Players can simultaneously set multiple filtering conditions such as win rate range, suitable scenarios, character type, and transaction price range.

[0126] The above technical solution upgrades team composition retrieval from passively receiving recommendations to actively and accurately filtering, meeting the differentiated team composition acquisition needs of players at different levels and with different requirements.

[0127] This application also discloses a game lineup sharing and trading system, such as Figure 5 As shown, the system includes:

[0128] The upload module 10 is used to respond to the lineup configuration data upload operation triggered by the first player in the lineup upload interface, obtain the lineup configuration data and the transaction conditions of the lineup configuration data, and if the lineup configuration data meets the preset conditions, store the lineup configuration data in the platform database. The lineup configuration data includes virtual character formation information, and the transaction conditions include the resources required to obtain the lineup configuration data.

[0129] The upload module 10 includes:

[0130] The interface rendering submodule 11 is used to render the three functional areas of the lineup upload interface: the lineup formation area where the virtual character positions are configured by dragging and dropping, the description information editing area that provides a structured information input template, and the transaction condition setting area that provides a drop-down control for resource type selection and a resource quantity input control.

[0131] The data verification submodule 12 is used to perform preset condition verification on the lineup configuration data when submitting. This includes verifying whether all virtual characters in the lineup are legal and valid, whether the resource types and quantities in the transaction conditions are within the allowed range, whether the description information contains illegal content, and whether the lineup is duplicated. After the verification is passed, a unique lineup ID is assigned to the lineup and serialized and stored in the platform database.

[0132] The labeling module 20 is used to obtain the corresponding battle data in response to the use of the lineup configuration data in the platform database, and generate scene tags for the lineup configuration data based on the battle data, wherein the historical data includes at least usage count data and battle result data.

[0133] The annotation module 20 includes:

[0134] The battle data collection submodule 21 is used to automatically record the usage data each time a player uses a lineup in battle, including indicators such as the battle scene type and level identifier, battle result, time taken to clear the level, number of surviving characters, and total damage dealt.

[0135] The data aggregation and calculation submodule 22 is used to summarize the usage data of each lineup in each scenario according to a preset time period, calculate the win rate = total number of wins ÷ total number of uses × 100%, and the average time to complete the level and other level completion efficiency indicators.

[0136] The scene tag generation submodule 23 is used to compare the calculated win rate with the preset win threshold. If the win rate is greater than or equal to the preset win threshold, the scene is marked as an adapted scene. The adapted scenes are sorted in descending order of win rate, and the scenes with the same win rate are sorted in descending order of level completion efficiency. Graphical tag data containing scene icons and win rate progress bars is generated.

[0137] The recommendation module 30 is used to respond to the lineup recommendation request triggered by the second player in the lineup recommendation interface, obtain the player data of the second player, filter lineup configuration data from the platform database based on the scene tags, and display it in the lineup recommendation interface in the form of lineup cards.

[0138] The recommendation module 30 includes:

[0139] The player data reading submodule 31 is used to read the virtual character pool data of the second player and the current level progress data;

[0140] The adaptation filtering submodule 32 is used to filter out the lineup configuration data that the player can directly use from the platform database based on the player's character pool and level progress, ensuring that the virtual characters required for the lineup are all in the second player's virtual character pool and that the lineup adaptation scenario is related to the player's level progress.

[0141] The sorting and recommendation submodule 33 is used to sort the candidate lineup by a weighted sorting algorithm, taking into account factors such as scenario win rate, popularity index, transaction price, and release time, and generate a recommendation list.

[0142] The interface rendering submodule 34 is used to render and display the recommended lineup in the form of lineup cards, including thumbnails of core character portraits, scene tag areas, popularity indicators, price tags and one-click import buttons, and supports expanding the cards to display gameplay explanation information areas and development priority information areas.

[0143] The multi-dimensional filtering submodule 35 provides multi-dimensional filtering bars such as a win rate range slider control, a scene-adaptive multi-select label control, and a character quantity selection control, which supports players to combine filtering conditions and dynamically refresh the display of filtering results.

[0144] The transaction module 40 is used to respond to the second player's operation of obtaining the target lineup configuration data on the lineup card, display the transaction conditions of the target lineup configuration data in the transaction confirmation interface, and import the target lineup configuration data into the second player's player database after the verification is passed.

[0145] The transaction module 40 includes:

[0146] The transaction interface submodule 41 is used to display the transaction confirmation interface, including the lineup name and core information summary, transaction condition details and a confirm payment button. During the transaction process, three status indicator icons are displayed in sequence: locked, importing, and transaction completed.

[0147] The transaction guarantee submodule 42 is used to perform resource locking operations in the database transaction after receiving the acquisition request, transferring the resources paid by the buyer from the available balance to the frozen balance to ensure the atomicity of the transaction;

[0148] Import verification submodule 43 is used to perform lineup configuration data import operations, write data such as character selection list, position coordinate mapping, recommended equipment ID list, skill point allocation scheme, etc. into the buyer player database one by one, and perform integrity verification.

[0149] The transfer and settlement submodule 44 is used to perform resource transfer after the import verification is passed. After deducting the handling fee according to the preset transaction handling fee ratio, the net amount of the locked resources is transferred to the seller's account.

[0150] This disclosure also provides an electronic device, such as... Figure 6 As shown, the electronic device includes a processor 7 and a memory 8. The memory 8 stores machine-executable instructions that can be executed by the processor, which executes the machine-executable instructions to implement the aforementioned methods for sharing and trading game lineups.

[0151] This disclosure also provides a computer-readable storage medium storing computer-executable instructions. When these computer-executable instructions are invoked and executed by a processor, they cause the processor to implement the aforementioned methods for sharing and trading game lineups. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0152] Specific embodiments have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A method for sharing and trading game lineups, characterized in that, Includes the following steps: In response to the first player's lineup configuration data upload operation triggered in the lineup upload interface, the lineup configuration data and the transaction conditions of the lineup configuration data are obtained. If the lineup configuration data meets the preset conditions, the lineup configuration data is stored in the platform database. The lineup configuration data includes virtual character formation information, and the transaction conditions include the resources required to obtain the lineup configuration data. In response to the use of the lineup configuration data in the platform database, the corresponding battle data is obtained, and a scene tag for the lineup configuration data is generated based on the battle data. The historical data includes at least usage count data and battle result data. In response to the lineup recommendation request triggered by the second player in the lineup recommendation interface, the player data of the second player is obtained, and based on the scene tag, lineup configuration data is filtered from the platform database and displayed in the lineup recommendation interface in the form of lineup cards; In response to the second player's operation of obtaining the target lineup configuration data on the lineup card, the transaction conditions of the target lineup configuration data are displayed in the transaction confirmation interface, and after the verification is passed, the target lineup configuration data is imported into the second player's player database.

2. The method for sharing and trading game lineups as described in claim 1, characterized in that, The scenario tags for generating the lineup configuration data based on the battle data include: Based on the usage data and battle result data of the lineup configuration data, the win rate and level completion efficiency of the lineup configuration data in specific battle scenarios are determined. If the win rate is greater than or equal to the preset win threshold, the specific battle scenario will be marked as the suitable scenario for the lineup configuration data; The scene tags are displayed in the lineup card in the form of graphical tags, which include battle scene icons and win rate progress bars.

3. The method for sharing and trading game lineups as described in claim 2, characterized in that, The step of marking the specific battle scenario as an adapted scenario for the lineup configuration data includes: The applicable scenarios are sorted in descending order based on win rate. If the win rates are the same, they are sorted in descending order based on completion efficiency.

4. The method for sharing and trading game lineups as described in claim 1, characterized in that, The method further includes: According to a preset time period, obtain the usage change data of the lineup configuration data within the preset time period to determine the popularity of the lineup configuration data; Based on the popularity, adjust the recommendation weight and / or transaction pricing of the lineup configuration data in the lineup recommendation interface; The lineup card displays a popularity indicator, which dynamically changes its display based on the popularity value.

5. The method for sharing and trading game lineups as described in claim 1, characterized in that, The method further includes: In response to the first player's modification operation triggered by the submitted lineup configuration data in the lineup management interface, the lineup editing interface is displayed, the updated lineup configuration data is obtained, and the updated lineup configuration data is used to replace the original lineup configuration data.

6. The method for sharing and trading game lineups as described in claim 5, characterized in that, The method further includes: In response to a secondary creation operation triggered by any second player on the lineup configuration data in the platform database in the lineup details interface, a lineup editing interface populated based on the lineup configuration data is displayed, the newly generated lineup configuration data is obtained, the new lineup configuration data is uploaded to the platform database, and the derivation relationship between the new lineup configuration data and the original lineup configuration data is displayed in the lineup details interface in the form of a derivation relationship tree diagram.

7. The method for sharing and trading game lineups as described in claim 1, characterized in that, The player data includes virtual character pool data and current level progress data; The step of filtering lineup configuration data from the platform database and displaying it in the form of lineup cards on the lineup recommendation interface includes: Based on the virtual character pool data and the current level progress data, the team configuration data that matches the player data is selected from the platform database as the suitable team; The recommended lineup is displayed to the second player in the form of a lineup card in the lineup recommendation interface, and a one-click import control for the recommended lineup is provided on the lineup card; In response to the second player's operation of expanding the lineup card, the gameplay explanation area and the virtual character development priority information area of ​​the lineup are expanded and displayed on the lineup card.

8. The method for sharing and trading game lineups as described in claim 1, characterized in that, The lineup configuration data also includes lineup description information marked by the first player for the lineup configuration data. The lineup description information includes at least one of the following: the core positioning of the lineup, the type of scene to be adapted, the required virtual character information, and historical win rate data. The lineup upload interface includes a lineup formation area, a description information editing area, and a transaction condition setting area. The lineup formation area is used to configure the virtual character positions by dragging and dropping. The transaction condition setting area provides a drop-down control for resource type selection and a resource quantity input control.

9. The method for sharing and trading game lineups as described in claim 1, characterized in that, The transaction conditions include at least one of the following: in-game currency amount, specified item type and quantity, and in-game virtual resource type and quantity; The method further includes: In response to the second player triggering a request in the transaction confirmation interface, a transaction guarantee progress bar is displayed in the transaction confirmation interface, and the resources paid by the second player are locked through the transaction guarantee mechanism set by the system. In response to the confirmation that the target lineup configuration data has been successfully imported into the player database of the second player, the locked resources are transferred to the account corresponding to the first player, and the transaction fee is deducted from the transferred resources according to the preset transaction fee and profit distribution rules; The transaction confirmation interface displays three status indicators in sequence during the transaction process: locked, importing, and transaction completed.

10. The method for sharing and trading game lineups as described in claim 1, characterized in that, The lineup recommendation interface provides a multi-dimensional filter bar, which includes at least one of the following: a win rate range slider control, a multi-select label control for adapting to the scene, and a selection control for the number of virtual characters required for the lineup. The multi-dimensional filter bar allows players to filter lineups using at least one filter control. In response to the filtering operation triggered by the multi-dimensional filtering control, the filtering conditions are obtained, and the lineup configuration data is filtered from the platform database according to the filtering conditions. The filtered lineup cards are then dynamically refreshed and displayed on the lineup recommendation interface.

11. A system for sharing and trading game lineups, characterized in that, include: The upload module is used to respond to the lineup configuration data upload operation triggered by the first player in the lineup upload interface, obtain the lineup configuration data and the transaction conditions of the lineup configuration data, and if the lineup configuration data meets the preset conditions, store the lineup configuration data in the platform database. The lineup configuration data includes virtual character formation information, and the transaction conditions include the resources required to obtain the lineup configuration data. The labeling module is used to obtain the corresponding battle data in response to the use of the lineup configuration data in the platform database, and generate scene tags for the lineup configuration data based on the battle data. The historical data includes at least usage count data and battle result data. The recommendation module is used to respond to the lineup recommendation request triggered by the second player in the lineup recommendation interface, obtain the player data of the second player, filter lineup configuration data from the platform database based on the scene tags, and display it in the lineup recommendation interface in the form of lineup cards; The transaction module is used to respond to the second player's operation of obtaining target lineup configuration data on the lineup card, display the transaction conditions of the target lineup configuration data in the transaction confirmation interface, and import the target lineup configuration data into the second player's player database after verification.

12. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1-10.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-10.

Images