Game evaluation method, apparatus, and program

Abstract

To solve a problem that sales of a game cannot be maximized by optimizing parameters by adjusting the parameters of the game in advance by visualizing a balance of items before sales of the game.SOLUTION: In a method according to the present disclosure, a computer executes the steps of: inputting a master including a play assumption; calculating, by enhanced learning, a finer play assumption so as to make efficient maximum, on the basis of the play assumption; and calculating such an optimal play that an average of status within a predetermined period or an average of values of the total amount of acquires resources is maximum, on the basis of the finer play assumption.SELECTED DRAWING: Figure 23

Description

Technical Field

[0001] The present disclosure relates to a method, apparatus, and program for evaluating games.

Background Art

[0002] After a game is released, some games have evaluated business information such as the sales performance of the game or the actual play of players, and changed parameters necessary for the operation of the game. On the other hand, before a game is released, evaluating the game from the perspective of players, visualizing each parameter of the game based on the evaluation, and thereby changing or adjusting the parameters of the game has not been conventionally performed.

[0003] In the game industry, etc., in the development stage of a new game, it is often the case that a game play assumption is created regarding how players play the game. And, based on the master parameter setting values for the created game play assumption, simulating how many items are acquired and consumed by players over time, or how much the player's status grows, etc., has been partially performed.

[0004] For example, when it is set that the items that can be obtained in Quest 1 of Chapter 1 of a certain game are 1 item A and 5 items B, when Quest 1 of Chapter 1 is played 5 times, the number of items that can be obtained in Quest 1 of Chapter 1 can be simulated as 1 item A × 5 times = 5 items and 5 items B × 5 times = 25 items. However, such a simulation is a complicated and time-consuming operation when the number of quests and the number of items are large, so it has not actually been performed.

[0005] Patent Document 1 describes evaluating the timing of player inputs after the game has been released and changing the game's difficulty based on that evaluation. However, Patent Document 1 does not disclose evaluating and adjusting game parameters before the game is released (Patent Document 1). [Prior art documents] [Patent Documents]

[0006] [Patent Document 1] Japanese Patent Publication No. 2019-457 [Overview of the Initiative]

[0007] As mentioned earlier, it is possible to create a gameplay scenario and calculate the amount of items and other items to be acquired in each content based on that scenario. However, for example, if there are 10 quests in one chapter and there are 10 chapters, there will be a total of 100 content items (10 quests x 10 chapters). In such a case, creating a gameplay scenario would require creating 100 detailed scenarios for each of the 100 content items. Furthermore, in typical games, there are various content items other than quests, and creating a detailed gameplay scenario for each of these content items, including difficulty levels and stages, would be too time-consuming and impractical. Therefore, such simulations have often not been performed before a game is released, or if they have been performed, they have been partial and limited.

[0008] On the other hand, the conventional methods described above could only visualize the amount of items acquired. The amount of items consumed also changes depending on the character's strengthening status, so the amount of items consumed is influenced by factors such as how the character is developed. What is important for game balance is not the amount of items acquired alone, but the balance between the amount of items acquired and consumed. Calculating this balance of items required separately calculating the amount of items acquired and consumed, and then comparing them to determine if the balance was appropriate, which was even more time-consuming.

[0009] Furthermore, each parameter in the master file that records parameter settings and other information is intricately related to other parameters, and there may even be nested structures between multiple master files. For example, when calculating the items obtainable in Chapter 1, Section 1 of Quest, Chapter 1, Section 1 is further divided into three stages, each featuring enemy monsters. Defeating these monsters has a predetermined probability of yielding three treasure chests: gold, silver, and bronze. Opening each treasure chest yields a set of items corresponding to that chest. Since these item sets usually contain multiple items such as Item A, B, C, etc., simply calculating how much of each item you will obtain upon completing this quest becomes complex. Moreover, the composition of treasure chests varies considerably depending on the content and game. Therefore, even within the same game, different content requires different simulation logic, making the simulation a cumbersome and time-consuming task.

[0010] For these reasons, trying to balance the entire game, including the balance of items, requires an enormous amount of effort or time. Moreover, when looking at the amount of item A acquired, for example, in most cases the same item A can be obtained from multiple different content sources. As mentioned earlier, the structure of the master file differs depending on the content source, making simultaneous simulation impossible. Therefore, the simulation results for each individual content source must be calculated separately, and representing how much of each item can be obtained from which content source in a single graph has been an extremely time-consuming task.

[0011] Simulating game balance required a tremendous amount of effort to create detailed gameplay scenarios, and each time the game, content, or features differed, a different simulation logic had to be created. As a result, it was virtually impossible to comprehensively and thoroughly simulate the overall balance of a game in the past.

[0012] Ultimately, if a game has a poor balance between revenue and expenses, it's highly likely that its monthly sales will become unstable or unexpectedly low, resulting in a slump in the total revenue generated from the game. [Problems that the invention aims to solve]

[0013] The problem this disclosure aims to solve, as described above, is that by visualizing the revenue and expenses of items before the game's release, it is not possible to maximize game sales by adjusting and optimizing the game's parameters in advance.

[0014] Conventional methods involved using structured master data to simulate gameplay scenarios. This required developers to meticulously plan and define how users would play. For example, if there were 50 quests, from 1-1 to 1-10, across 5 chapters, developers had to specify which quests would be played and how many times on each day. However, such detailed planning is impractical in reality. Therefore, this invention automates the creation of these settings (gameplay scenarios).

[0015] Furthermore, after creating a gameplay scenario, I invented a method to automatically tune the parameters so that they match the intended balance once that scenario is actually implemented. In other words, this method automatically generates parameter settings that result in the game difficulty desired by the designer.

[0016] According to another aspect of the present invention, it is possible to calculate the optimal play based on a rough play scenario.

[0017] In another aspect of the present invention, it becomes possible to adjust parameter values ​​based on optimal gameplay. [Means for solving the problem]

[0018] The method for evaluating a game according to this disclosure involves a computer performing the following steps: (A) calculating the product of the expected value of acquiring and consuming each item when a player takes an action, based on the parameters of the master, and the assumed number of times the player takes the action; and (B) visualizing the balance of each item based on the result of the multiplication.

[0019] Another method according to this disclosure involves a computer performing the following steps: inputting a master including play assumptions; calculating more detailed play assumptions using reinforcement learning based on the play assumptions to maximize efficiency; and calculating an optimal play based on the more detailed play assumptions to maximize the average value of the status or the total amount of resources acquired over a predetermined period.

[0020] Another method according to this disclosure involves a computer performing the following steps: calculating an optimal play based on predetermined parameter settings; comparing the amount of resources acquired, growth status amount, or amount of each content acquired obtained as a result of the calculation of the optimal play with the respective predetermined values, and based on the results, changing the predetermined parameter settings to learn to reduce the difference between the amount of resources acquired, the growth status amount, or amount of each content acquired and the predetermined values; and, if the difference becomes less than or equal to a predetermined value, outputting the parameter settings at that time.

[0021] These general or specific aspects may be implemented in a system, apparatus, method, integrated circuit, computer program, or recording medium, or may be implemented in any combination of a system, apparatus, method, integrated circuit, computer program, and recording medium.

Advantages of the Invention

[0022] According to the present disclosure, by simulating the game balance before the release of the game, the profit and loss balance of the game can be easily evaluated, and necessary adjustments to each parameter can be made. As a result of such adjustment of parameters before the release of the game, the game can steadily increase its sales every month, and as a result, it becomes possible to increase the total sales from the game.

Brief Description of the Drawings

[0023] [Figure 1] Diagram showing the procedure of game level design [Figure 2] Diagram showing the basic pattern of sales trend of social games [Figure 3] Diagram showing the amount of damage received by players in each layer when clearing the dungeon of a certain game [Figure 4] Diagram showing an example of parameter visualization by organizing masters [Figure 5] Diagram showing an example of improving game operation by applying the present disclosure [Figure 6] Diagram showing the profit and loss of magic stones in the game before and after applying the present disclosure [Figure 7] Flowchart showing the application procedure of the present disclosure [Figure 8] Diagram showing a master with a nested structure that is not a conventional standard ​​​​​​​​ [Figure 12] Figure 11 shows the output when this disclosure is applied, and this figure shows the expected value of each item calculated from that figure. [Figure 13] Diagram showing a non-standard master [Figure 14] Figure 13 shows a non-standard master converted to a standard master to which this disclosure applies. [Figure 15] Figure 14 shows the output of a standard master to which this disclosure is applied. [Figure 16] Figure 14 shows a list of expected values ​​for a standard master to which this disclosure is applied. [Figure 17] Diagram illustrating gameplay scenarios [Figure 18] A diagram showing the daily number of each item acquired in each action. [Figure 19] This chart shows the daily acquisition count of each item according to the assumed gameplay scenario. [Figure 20] Table explaining item consumption [Figure 21] Table showing the balance of each item [Figure 22] Block diagram of a computer running a program that operates in accordance with this disclosure [Figure 23] A flowchart outlining how to calculate the optimal play. [Figure 24] A diagram showing the relationship between quest categories and play order. [Figure 25] Diagram illustrating reinforcement learning [Figure 26] A flowchart showing the procedure when using the Monte Carlo method. [Figure 27] A graph showing the relationship between total value and the date on which the first rarity 5 card was acquired. [Figure 28] Graph showing the average values ​​for each date in Figure 27 [Figure 29] Flowchart illustrating the outline of Example 3 [Figure 30] A flowchart illustrating the automatic adjustment method for the master according to the present invention. [Figure 31] A graph showing how the battle power value changes with the number of occurrences. [Figure 32] Diagram showing the master before and after adjustment using the automatic adjustment method of the present invention. [Modes for carrying out the invention]

[0024] In this specification, "game" includes, without limitation, all types of computer games using any kind of computer, including arcade games, console games, video games, handheld games, PC games, mobile phone games, smartphone games, social games, browser games, NFT games, blockchain games, and crypto games. Furthermore, in DeFi (Decentralized Finance) using NFTs and blockchain technology, unlike centralized systems, there are no intermediaries and transactions take place between users. However, unlike centralized systems, there is no mechanism in place where a specific person bears various transaction mediation costs in exchange for receiving a reward, so transactions are difficult to complete as they are. Therefore, in the field of DeFi, it is necessary to design a system in which an unspecified number of users can receive some kind of reward in exchange for paying transaction costs, so that transactions can be carried out smoothly even among an unspecified number of people. It is necessary to optimize the reward balance defined on the smart contract, and the technology of this application is applicable to such fields.

[0025] In this specification, for the sake of explanation, social games will be used primarily as examples of games, but the application of this disclosure is not limited to social games and is applicable to all types of games.

[0026] In this specification, "social game" refers to an online game enjoyed by one or a group of users, and includes elements such as community and cooperation or competition among users. For example, social games involve actions such as building farms or towns within the game, collecting cards and battling with decks, or progressing through stages by solving specific puzzles. Social games are usually free to play, and game providers generate revenue through charges for purchasing items. Social games are also called "social games."

[0027] Basic terminology in the social game field is not necessarily standardized across game manufacturers; therefore, the terms used in this specification are defined as follows.

[0028] A "character" refers to a person, animal, robot, machine, or fictional creature that appears in a game. These characters are controlled by the player and play a role in the game's narrative. "Characters" are also sometimes called "caras" or "game characters."

[0029] The term "gacha" originally comes from a machine called "gacha-gacha" or "gachapon," and in games, it refers to a system where you randomly draw items or other items to obtain them. Gacha is usually a combination of free and paid methods.

[0030] A "card" is like an avatar of the player used in a game. Players collect multiple cards to create a deck (or team) and use that deck to battle enemies or other players in the game. In some games, cards are also called monsters.

[0031] A "card" generally has four elements: "rarity," "cost," "parameters," and "skill." "Rarity" represents the scarcity of a card. Generally, the rarer a card is, the harder it is to obtain, meaning the probability of drawing it is low and the more expensive it is. "Cost" is used as the "cost limit," which is the maximum cost of all cards when multiple cards are placed in a deck. "Parameters" are values ​​that represent the strength associated with a card. Generally, other values ​​such as "attack power" or "defense power" are also set. The higher the "attack power," the more damage the attack deals to the opponent, and the higher the "defense power," the less damage the card receives from an opponent with the same attack power. "Skills" are unique abilities that the card can use. For example, they may be abilities that increase the attack power of the players or allow the player to attack first.

[0032] A "quest" is a task given to the player, and is used when helping a character in need.

[0033] A "stage" is a constituent unit or section of a game.

[0034] A "dungeon" is an area with traps such as monsters appearing, and dungeons are the climax of the game.

[0035] A "chapter" is a division or section, and is synonymous with "stage."

[0036] "Items" refer to all tools that a character can possess within the game.

[0037] "Magic Stones" are an item that functions like currency within the game. Magic Stones can be used for things like gacha draws, the continue function, and stamina recovery.

[0038] The "boss" is the guardian of each stage, and defeating this boss allows you to advance to the next stage. [Examples]

[0039] Figure 1 shows the steps involved in game level design. Generally, in game development, "level design" refers to the process of adjusting the difficulty (i.e., numerical values) of various parameters used in the game. In apps such as social games, level design is often perceived as simply parameter setting. However, in this specification, level design is defined as a series of steps, from the upstream UX (User Experience) policy—that is, defining what kind of experience to deliver to the user—to subsequent data analysis.

[0040] If there are problems with the upstream UX (User Experience) policy determination 101 or game logic design 102, sales may not increase even if the parameter settings 103 are adjusted. Also, unless the parameter settings 103 are analyzed and confirmed to satisfy the UX (User Experience), it may not be possible to make appropriate parameter adjustments.

[0041] In this specification, level design includes steps such as determining the UX (User Experience) policy 101, designing the game logic 102, setting parameters 103, visualizing the UX 104, designing KPIs 105, and verifying the UX 106, as shown in Figure 1. In Figure 1, six steps are shown for the sake of explanation, but these steps may be further subdivided, and some of the six steps may be integrated.

[0042] In this specification, the level design process includes a series of steps, from the upstream UX policy determination 101, that is, the definition of what kind of experience to deliver to the user, to subsequent data analysis.

[0043] UX policy determination 101 is the stage where the user experience policy, or in other words, the game specifications, are decided.

[0044] In the next step, game logic design 102, we consider how to make the game enjoyable for users based on the UX policy decided in step 101. In other words, we consider what logic or formulas will be used to implement the decided UX policy. For example, in a scenario where players enjoy a group battle, the number of players in each battle, the duration of the battle, and the types of attacks available are all part of the game logic. On the other hand, regarding character growth, deciding what constraints to impose and how to encourage trial and error is included in game logic design 102.

[0045] In game logic design 102, the formula representing difficulty should be based on mathematical formulas to consider the UX (user experience), such as whether the difficulty increases monotonically over time, accelerates from the latter half of the game, or converges to a certain value in the end. If the game logic is flawed or the formula representing difficulty is inappropriate, it will be difficult to implement a marketable game based on such game logic, no matter how good the UX policy decided in the early stages of level design is.

[0046] In the next step, parameter setting 103, we will assign numerical values ​​to each parameter in accordance with the UX policy decided up to that point and the game logic that has been designed. In this parameter setting 103, it is necessary to quantitatively translate the framework of the UX policy into parameters.

[0047] For example, in a city-building game, a UX policy might be assumed regarding a certain accident: "This accident happens surprisingly frequently and causes significant damage, making it a thrilling experience." In this case, the "surprisingly frequent" aspect can be quantified, for example, to "occurs once every 60 minutes," and the "significant damage" aspect can be quantified, for example, to "up to 70% of the player's money is lost." Alternatively, the "thrilling" aspect could be set with a certain range, for example, "the damage randomly fluctuates between 10% and 70% of the player's money each time."

[0048] By determining the UX policy in this way, players of this game can experience the "thrilling experience" that is the determined UX policy. Furthermore, by repeatedly quantifying the parameters of the UX policy in this way, it becomes possible to set parameters that are less prone to errors.

[0049] The next step is to perform UX visualization 104. In UX visualization 104, we visualize and verify whether the parameter settings are in accordance with the determined UX policy. In this case, player playtesting of the game is necessary, but as a preliminary step, visualizing the UX at a numerical level and verifying the parameters can significantly reduce the risk of errors in parameter settings. For example, the UX can be roughly expressed numerically, such as "how many days does it take to raise a certain character?" Alternatively, the UX can be visualized by, for example, performing a simulation and organizing a master file that describes each parameter.

[0050] By using a simulator to visualize the user experience (UX), it becomes possible to provide a mechanism to prevent sales declines caused by incorrect parameter settings during operation.

[0051] For example, in a game, when entering a dungeon and acquiring items, the amount of time it takes to acquire a certain number of items is also an important aspect of UX (User Experience). This can be visualized by organizing the master data, which can help prevent accidents caused by incorrect parameter settings.

[0052] Next, in KPI Design 105, you need to design KPIs (Key Performance Indicators) and prepare to check the difference between the expected UX and the actual UX when playing the game. For example, if the game is designed with the assumption that "heavy users will play a certain number of times a day and complete a certain number of quests in a certain number of days," then the number of times that player group plays and the quest completion status will become KPIs to check that UX.

[0053] In the final step, UX verification 106, before the game's release, the team verifies whether the intended UX is being delivered by reviewing the previously designed KPIs. If, as a result of UX verification 106, the UX determined in UX policy determination 101 is not being delivered, the team returns to game logic design 102 to reconfigure the game logic, or returns to parameter setting 103 to readjust the parameters.

[0054] Figure 2 shows the basic patterns of sales trends for social games. In Figure 2, the horizontal axis represents time, and the vertical axis represents the sales of the social game.

[0055] Referring to Figure 2, we can see that there are three phases in terms of game sales, starting from the time of game release: "Expansion Phase 201," "Sharp Decline Phase 202," and "Gradual Decline Phase 203." The first stage after the game's release is "Expansion Phase 201," in which both the number of users and the average spending per customer increase rapidly, resulting in a steady rise in sales from the game. Next is "Sharp Decline Phase 202," in which the number of users decreases sharply and sales plummet. Finally, there is "Gradual Decline Phase 203," in which the number of users decreases to a certain extent and sales continue to decline.

[0056] A good game, or in other words, a game that sells well, sees a gradual increase in both user numbers and sales after its release, and the decline in sales is gradual even after the peak sales period (i.e., there is no sudden drop in sales). On the other hand, a game that doesn't sell well often sees a gradual increase in user numbers and sales after its release, but the peak sales are not high, and then user numbers and sales decline rapidly thereafter.

[0057] While the maximum (peak) sales depend largely on the game's potential, or in other words, its inherent appeal, thorough level design can help maximize sales during the expansion phase (201) and, to some extent, prevent user attrition and sales decline during the sharp decline phase (202) or gradual decline phase (203) after sales have peaked. As a result, significant profit improvements are possible in the long term.

[0058] Figure 2 shows examples of successful game level design (solid line) and unsuccessful level design (dashed line). In the example of successful level design (solid line), sales are maximized during the expansion phase 201 due to the success of level design (indicated by 210), and sales do not fall sharply during the sharp decline phase 202 and the subsequent gradual decline phase 203, but are maintained to a certain extent (indicated by 211).

[0059] In contrast to the example of successful RebeDeza (solid line) mentioned above, in the example of unsuccessful RebeDeza (dashed line), the maximum sales did not increase significantly during the expansion phase 201, and the peak sales value was also low (symbol 220). Furthermore, the decline in sales was sharp during the subsequent rapid decline phase 202 and gradual decline phase 203 (symbol 221). As a result, in the example of unsuccessful RebeDeza (dashed line), the total sales from launch to final discontinuation were also smaller than in the example of successful RebeDeza (solid line).

[0060] Before a game's release, the focus tends to be on whether it will sell at all, that is, on the maximum sales amount over a certain period. However, unlike in the past, maintaining sales once they have been achieved is becoming more important, so proper level design is more crucial than ever.

[0061] There are several important elements associated with each of the three phases described in Figure 2: the expansion phase (201), the rapid decline phase (202), and the gradual decline phase (203). First, the "core enjoyment (204)" contributes significantly to the initial expansion phase (201). This core enjoyment (204) refers to the fun of the in-game experience itself, as well as the appeal of the IP, characters, and world setting. While the fun of the in-game experience can be increased through game logic and parameter settings, there are aspects of the core enjoyment (204) that cannot be addressed solely through level design.

[0062] The importance of the core enjoyment of the game (204), including in-game elements and IP, is high during the expansion phase (201) (◎), while its importance decreases during the rapid decline phase (202) and the gradual decline phase (203) (△).

[0063] The importance of "perceived growth (205)" due to status inflation, etc., is high (◎) during the rapid decline period (202), and moderate (○) during the expansion period (201) and the gradual decline period (203).

[0064] The importance of "heroic feelings (206)," such as the need for recognition and self-display, tends to gradually increase over time, progressing from the expansion phase (△), to the rapid decline phase (○), and then to the gradual decline phase (◎).

[0065] While the sales of each game certainly depend on the game's potential, that is, its inherent appeal, even with the same game, proper level design can maximize sales early in the expansion phase 201 and delay the subsequent decline in the sharp decline phase 202 and gradual decline phase 203, thereby maximizing the revenue generated from a single game.

[0066] In the period of rapid decline (202), the element of "feeling of growth (205)" becomes crucial. In short, it is important to ensure that players constantly experience the feeling that they are getting stronger the more they play the game. For example, in card games, this corresponds to the inflation of card stats (in other words, the phenomenon where stats and firepower continue to increase over time), but it is not enough to simply inflate them; it is also important to create a system that provides players with a tangible sense of that increased strength.

[0067] The crucial element in the final gradual decline phase (203) is "heroic feeling (206)." This heroic feeling (206) is whether the player feels they are making an impact. For example, this could be the player ranking high in the game's rankings, or other players thinking, "Wow, that player has some great cards or characters!"

[0068] In games that maintain high sales for an extended period, designing a sense of heroism (206) is crucial in the long run. When players feel a sense of heroism (206), they are more likely to play the game for a longer time and make in-app purchases, which can lead to increased sales and mitigated sales declines.

[0069] These three important elements—core enjoyment (204), sense of growth (205), and sense of heroism (206)—are not entirely separate from each other, but they generally correspond to the three phases described above: expansion (201), rapid decline (202), and gradual decline (203).

[0070] Figure 3 shows the amount of damage taken by players in each floor of a dungeon in a certain game, i.e., the win rate. The horizontal axis of the table lists the players' levels in five stages, from beginner, novice, intermediate, advanced, and ranker, from those who are bad at the game to those who are good at it. The vertical axis of the table lists the seven areas of the game, from Area 1 to Area 7, from top to bottom. Figure 3 shows the win / loss record (%) for each area for players of each level. Also, referring to the legend on the right side of Figure 3, the win rate is classified into five stages from lowest to highest in terms of UX (User Experience): crushing defeat, close defeat, narrow victory, victory, and easy victory.

[0071] For example, in an RPG (role-playing game) with multiple areas to explore, we simulate the amount of damage (i.e., damage taken) that a player or party would receive in each level until clearing each area. In Figure 3, the boundary between winning and losing is set at 100% based on the amount of damage, assuming that if the amount of damage exceeds 100, it is a loss, and if it is 100 or less, it is a win. Through this simulation, for example, a beginner would not be able to clear Area 5 (damage taken is 110%, i.e., a narrow defeat), but would barely be able to clear Area 4, the level below Area 5 (damage taken is 90%, i.e., a narrow victory).

[0072] On the other hand, advanced players can easily clear Area 3 (taking 40% of the damage, i.e., an easy victory), barely clear Area 6 (taking 75% of the damage, i.e., a narrow victory), and barely clear Area 7 (taking 90% of the damage, i.e., a narrow victory).

[0073] As shown in Figure 3, the player's level and the difficulty level of each area (i.e., the amount of damage taken) are listed in a table, and the UX is comprehensively visualized. Therefore, visualizing the parameters as shown in Figure 3 can significantly reduce parameter errors caused by incorrect parameter settings.

[0074] In actual game operation, a significant drop in sales is often due to poorly configured parameters. For example, distributing too many important items can disrupt the balance of the player's sense of progression, or certain characters can become unbalanced, diminishing their heroic appeal. Such parameter setting errors can actually lead to sales not meeting expectations in the long term.

[0075] While these issues ultimately stem from incorrect parameter settings, the direct cause may be the lack of visualization of the user experience (UX).

[0076] Figure 4 shows an example of parameter visualization by organizing the master (or master file) that defines the parameters. The table on the left of Figure 4 (410) lists the quest ID, item ID, and quantity included in the game's master, from left to right. Based on this left-hand table (410), the items are organized by quest in the table on the right (420). In the right-hand table (420), the columns from left to right are ID, item name, and quest name, and within the larger groups of quest names, more detailed quest names are listed, such as grassland, cave, and mine.

[0077] For example, in the table (420) on the right of Figure 4, the row for ID=1 shows that the item name is Herb, and that there is 1 Herb in the grassland, 2 in the cave, and 3 in the mine. Similarly, the row for ID=2 shows that the item name is Small Healing Potion, and that there are 2 Small Healing Potions in the cave, but none in the grassland or mine. The row for ID=3 shows that the item name is Fragment, and that there is 1 Fragment in the grassland, but none in the cave or mine. For IDs 4-6, the number of Iron Ore, Gems, and Cards in each quest is listed in the table (420) on the right.

[0078] By organizing the game's master format table on the left (410) by item, the table on the right (420) makes it easier to understand how many of each item can be obtained in which quest compared to the table on the left (410).

[0079] Figure 5 shows an example of how the operation of a game has been improved by applying this disclosure. When designing a game, it is necessary to divide users into several categories and prepare content that can be enjoyed by players in each category. In the example in Figure 5, for simplicity, users are divided into three categories according to their skill level in the game: beginners, intermediate players, and core players (advanced players).

[0080] For example, when evaluating the difficulty level for each user group in the early stages of game design before release, it may be possible to find a situation like the left diagram (510) in Figure 5, where many players can clear beginner-level content, but few can clear intermediate-level content. In such cases, players may get stuck in the intermediate stages of the game's progression. When this happens, intermediate-level players, in particular, will have difficulty progressing to the higher-level core tier, which reduces their motivation to continue playing the game. This leads to a decrease in sales from the large number of intermediate-level players, and consequently, a decrease in overall game sales.

[0081] If the balance of players at each level who can clear the content is poor, as shown in the left diagram (510) of Figure 5, applying the parameter evaluation of this disclosure to the game before its release will make the content for intermediate players easier than in the left diagram (510), thereby balancing the number of players who can clear the content for beginners, intermediate players, and core players. In the right diagram (520), as a result of making the content for intermediate players easier than in the left diagram (510), the number of players who can clear the content for intermediate players increases (i.e., the number of players who can challenge the content for core players increases), and intermediate players will continue to play more, so the overall revenue from the game can be further maximized.

[0082] Figure 6 shows the balance of Magic Stones in the game before and after applying this disclosure. As mentioned above, Magic Stones are a type of item and function like currency within the game. In both Figure 600 (before parameter adjustment) and Figure 650 (after parameter adjustment), the horizontal axis represents the number of days played, from day 1 on the far left to day 60 on the far right. In both Figure 600 (before disclosure) and Figure 650 (after disclosure), the vertical axis represents the balance (number) of Magic Stones. In each figure, the leftmost bar of the three bar graphs for each day of play represents the amount of Magic Stones acquired, the middle bar represents the amount of Magic Stones consumed, and the rightmost bar represents the difference (balance) between the amount of Magic Stones acquired and the amount consumed. From the left (600) and right (650) figures of Figure 6, it can be seen that in both cases, the amount of magic stones acquired and consumed increases according to the number of days the player has played the game.

[0083] Referring to Figure 600 before applying this disclosure, it can be seen that the balance (acquisition - consumption) increases with the number of days played: 1 day, 3 days, 5 days, 7 days, 14 days, 30 days, and 60 days. Also, at 60 days of play, the amount acquired is 13,100, which is the sum of 4,500 paid gems purchased, 5,000 from events, 3,000 from regular quests, and 600 from login bonuses. Referring to Figure 600 before applying this disclosure, at 60 days of play, the amount consumed is 8,400, which is the sum of 6,000 from event gacha and 2,400 from regular gacha (free gacha are not considered here). Therefore, the balance, which is acquisition - consumption, at 60 days of play before applying this disclosure is 4,700.

[0084] In contrast, referring to Figure 650 after applying this disclosure, we can see that as the number of play days increases from 1 day, 3 days, 5 days, 7 days, 14 days, 30 days, to 60 days, the balance, which initially increased on the 3rd day, decreases after some fluctuations, ultimately decreasing. Also, at 60 days of play, the amount acquired is 8350, which is the sum of 4500 paid gems purchased, 2500 from events, 1050 from regular quests, and 300 from login bonuses. Referring to Figure 650 after applying this disclosure, at 60 days of play, the amount consumed is 8400, which is the sum of 6000 from event gacha and 2400 from regular gacha. Therefore, the balance, which is acquired amount minus consumed amount, after applying this disclosure is -50.

[0085] As shown above, the balance after 60 days of play before applying this disclosure is 4700, indicating a poor balance between the amount of magic stones acquired and consumed (i.e., consumption is too low compared to acquisition). In contrast, the balance after 60 days of play after applying this disclosure is -50, indicating a smaller difference between the amount of magic stones acquired and consumed (i.e., a good balance between consumption and acquisition), and also a higher amount of magic stones consumed, which encourages spending on gacha, thus maximizing revenue from this game.

[0086] Figure 7 is a flowchart illustrating the application procedure of this disclosure. Here, "master" refers to tabular data that describes parameters used in the game, and "master format" refers to the format used for this master.

[0087] While sometimes a single master file describes the parameters of all elements used in a game, typically the contents of a parent master file are further described in child masters, grandchild masters, and so on, resulting in a multi-level nested master structure. When master files are nested, for example, an item in a parent master file may be further defined in detail within a child master file, making it impossible to understand the details of that item by looking only at the parent master file.

[0088] First, when a program according to the method of this disclosure is executed by a computer, it converts a master in a non-standard master format to a standard master format to which this disclosure applies (S701). The conversion of a non-standard master format to a standard master format (S701) may be performed using a computer, but it may also be performed manually. Typically, all masters used in a game are provided by a game development company in a non-standard master format. Even for games developed by the same game development company, the master format is not unified, and the master format often differs depending on the game or the version of the same game. A standard master format is used, which is unified and consistent regardless of the game production company, game, or game version.

[0089] Using the master data converted to a standard master format, the expected value × assumption for each element (e.g., an item) is calculated (S702). Here, the expected value is the number of times a player will acquire and consume each item when performing a certain action, and the assumption is the number of times the player is estimated to perform the action. By calculating this expected value × assumption, it becomes possible to predict, for example, how many of a certain item can be acquired in a given piece of content.

[0090] Next, by simulating the amount of items acquired, consumed, and the balance between acquired and consumed items, and visualizing the results, it is possible to visualize the results using the target parameters (S703). A diagram that visualizes the results of such a simulation of the amount of items acquired, consumed, and balance is, for example, the diagram (600) shown in Figure 6, which has already been explained.

[0091] Finally, the parameters are adjusted (S704) based on the item balance visualized by the simulation results. Specifically, the balance between item acquisition and consumption is examined for each day elapsed since the start of the game, as shown in Figure (600) in Figure 6. Looking at Figure (600) in Figure 6, for example, it can be seen that the amount acquired on day 60 is large compared to the amount consumed, resulting in an unbalanced balance of +4700.

[0092] By applying this disclosure, game developers can improve the balance of item balance by observing the balance of income and expenses in the upper left figure (600) of Figure 6 and appropriately adjusting each parameter in the master. The result of improving the balance of income and expenses by adjusting the parameters in this way is shown in the lower right figure (650) of Figure 6. Looking at the lower right figure (650) of Figure 6, it can be seen that the balance of income and expenses is well-balanced at each stage of play since the start of the game, especially from the 7th day onwards (i.e., the height of the income / expense bar graph is relatively low compared to the height of the bar graphs for acquired items and consumed items), and that the adjusted parameters are more appropriate for maximizing sales.

[0093] After adjusting the parameters in S704, you may optionally return to S702 and recalculate the expected value × assumed value based on the adjusted parameters, then resimulate the item balance based on the newly calculated results in S702, visualize the parameters again in S703, and if further fine-tuning of the parameters is necessary, you may adjust the parameters again in S704 based on the results of this simulation.

[0094] If necessary, after further parameter adjustments, you may repeat steps S702 through S704 once more.

[0095] Next, using Figures 8 to 16, we will explain in more detail the processes related to S701 and S702 in Figure 7. Figures 8 and 9 are non-standard masters created by game development companies and others when creating a game, while Figure 10 is a standard master to which this disclosure applies.

[0096] Figure 8 shows a non-standard nested master structure. Figure 8 contains four masters, and their relationships will be explained below.

[0097] The top table in Figure 8 is the master (parent master) of a certain game, named story_quest_master(801). First, in the structure of such a non-standardized (i.e., non-unified) master, the information contained in this master includes what you can obtain and with what probability when you perform an action such as a quest or draw from a gacha.

[0098] While some master tables directly specify the items that can be received, others specify the ID of a group list of items that can be received indirectly, such as a reward group. Furthermore, there are nested structures where referring to another master containing details of the target ID listed in the master may reveal yet another group list.

[0099] For example, in the example in Figure 8, there is a table called story_quest_master(801), which is the main master (i.e., the parent master), and the IDs of each story are written in the leftmost ID column as "10001", "10002", "10003", etc. For each story ID, there is a first_reward_group_id, which is the ID of an item that can only be obtained the first time, and a random_reward_group_id, which is the ID of an item that can be obtained every time. These are listed sequentially in the column to the right of the story ID column, such as 10001.

[0100] For example, in Figure 8, if the story ID is 10001, the item group list specified by first_reward_group_id is 1001, and the item group list specified by random_reward_group_id is 201.

[0101] In contrast, for groups that receive a reward only once, there is another master (child master) called first_reward_group_master(802), which states that for groups with group ID "1001", you can obtain "10" items (amount) of item_id "11" (flow in 810). Thus, it is sometimes impossible to know exactly how many items you can obtain in a given quest without going through two or more masters (in this case, two masters, a parent and a child). For example, to find out how many items of item 11 you can obtain, you can refer to the child master first_reward_group_master(802) from the parent master story_quest_master(801).

[0102] Next, in story_quest_master(801), if the ID is "10001", the ID of the item that can be obtained each time (random_reward_group_id) is "201". If we then refer to another master (child master) random_reward_group_master(803), we find that the random_reward_id for this item with ID "201" is "2001" (following the process in 820). Next, if we refer to another master (grandchild master) random_reward_master(804), we find that the item ID (item_id) for random_reward_id "2001" is "21", the weight is 10000, and the amount is "5" (following the process in 825). For random_reward_group_id, it's impossible to know which items you can obtain and with what probability without going through two separate masters (child master and grandchild master) called random_reward_group_master(803) and random_reward_master(804) (following the flow of 820 and 825). In other words, in this case, the masters have a three-tiered structure (i.e., there are three masters: 801, 803, and 804).

[0103] Figure 9 shows a non-standard nested master structure. Three masters are shown in Figure 9, and their relationships will be explained below.

[0104] Figure 9 shows an example of the structure of a gacha master. While Figure 8 showed the master structure of a quest, Figure 9 shows the master structure of a gacha. Even for things like gacha, where you don't know what you'll get with a certain probability, the master usually has several levels of nesting structure, similar to Figure 8. Referring to Figure 9, first, in the master called gacha_master(901), the gacha IDs "50001" and "50002" are listed. For the items that can be obtained for each gacha ID, the group to be referenced is specified in the lot_table_id column, such as "501" and "502" respectively. In other words, by only referring to the parent master gacha_master(901), you cannot tell what you can get and with what probability (i.e., the parent master gacha_master(901) does not have a column representing weight).

[0105] Next, by referring to the master table called gacha_lot_table_master(902), we can see that the gacha group with id "501" has three rarity levels: SR (Super Rare), SSR (Super Super Rare), and UR (Ultra Rare) (following the flow in 910). In the case of gacha, you can obtain something with a certain weight, so for example, if the gacha id is 50001, the weights you can obtain from the SR group, SSR group, and UR group are listed in gacha_lot_table_master(902) as 80, 15, and 5 respectively.

[0106] Here, "weight" is a dimensionless quantity that represents the relative ratio of the occurrence of each event. Therefore, the probability of each event occurring is the weight of the event in question divided by the sum of the weights of the events in the same group. For example, in this case, for gacha ID 501, the probability of an SR occurring is the weight of the SR itself divided by the sum of the weights of all three SR, SSR, and UR, i.e., 100 (=80+15+5). So the probability of an SR occurring is 80 ÷ 100 = 80%. Similarly, the probability of an SSR occurring is 15%, and the probability of a UR occurring is 5%. However, it is also possible to directly list the occurrence probabilities in the master without using weights.

[0107] Next, regarding rarity, we refer to the master table, gacha_prize_table_master(903), which describes what can be obtained in each group: SR, SSR, and UR. Referring to gacha_prize_table_master(903), we find that the SR group has three types of characters: "SR_A", "SR_B", and "SR_C", and the weight value of each is "10" (see 920). In other words, the weights of the three types of characters, "SR_A", "SR_B", and "SR_C", are 10:10:10 (i.e., 1:1:1), and we can see that each character can be obtained with a probability of 33.3% (=10÷(10+10+10)).

[0108] Thus, regarding the quest master, in some cases the reward group is specified, as in first_reward_group_id(802) in Figure 8, or a group master (i.e., gacha_lot_table_master(902)) is specified, as in the gacha SR shown in Figure 9, and a weight is applied to determine the proportion of each item that will appear. Furthermore, instead of individual item names, group names such as SR, SSR, and UR are specified, and then further details are specified within those groups, resulting in a multi-layered nested structure.

[0109] Typically, each master in each game has a nested structure of one or more levels. However, the inventor believed that by specifying which is an intermediate group and which is the final separated group, it would be possible to convert them into a unified standard master.

[0110] Figure 10 shows a standard master according to the method to which this disclosure is applied. In the method to which this disclosure is applied, the main master is defined as group_trans_1_conf(1010). group_trans_1_conf(1010) specifies which columns are for larger and smaller groups. In a table according to the method to which this disclosure is applied, the input source master (input_file) is specified on the far left. In this example group_trans_1_conf(1010), the four input masters are, from top to bottom, story_quest_master, story_quest_master, gacha_master, and gacha_master. Here, story_quest_master and gacha_master appear twice, but the child masters referenced in each row are different.

[0111] The two masters, story_quest_master and gacha_master, correspond to story_quest_master(801) shown in Figure 8 and gacha_master(901) shown in Figure 9, respectively.

[0112] In this disclosure method, the group ID column (group_id_column) in the three input masters in Figure 10 is the quest name, and the column to its right, separation_id_column, specifies what can be obtained in that quest. In the case of story quests, the ID of the main quest may be specified in group_id_column, and the obtainable rewards may be specified in separation_id_column.

[0113] In this disclosure method, the largest master is defined as group_trans_1_conf(1010). group_trans_1_conf(1010) specifies which columns belong to the larger and smaller groups. Furthermore, in select_type_column, cases where a reward is received only the first time are specified as "first", and cases where a reward is received every time are specified as "loop". In this example, select_type_column specifies two types: "first (first time only)" and "loop (every time)", but there may be three or more types.

[0114] In Figure 10, first_reward_group_id and random_reward_group_id are specified as the decomposed group separation_id_column. However, these group IDs themselves cannot become the smallest unit called item_id, so a master that further defines first_reward_group_id and random_reward_group_id is specified in the separation_id_master column, and then the master specified in separation_id_master is referenced.

[0115] Next, we refer to random_reward_group_master and gacha_lot_table_master in group_trans_2_conf(1020) to determine what group IDs are available and which ID to ultimately look at. In the case of first_reward_group_master, the final item_id is written in separation_id_column in group_trans_2_conf(1020), so the value in group_trans_2_conf(1020) becomes the final value to be decomposed (referenced), and the amount_column specifies the number of items to be acquired. For example, if amount_column is blank, the quantity can be set to "1".

[0116] Next, we refer to random_reward_master and gacha_prize_table_master in group_trans_3_conf(1030) to determine what group IDs are available and which ID to ultimately look at. In the case of random_reward_master, the final item_id is written in separation_id_column in group_trans_3_conf(1030), so the value in group_trans_3_conf(1030) becomes the final value for decomposition. The amount to be acquired is specified in amount_column, and the weight is specified in weight_column. For example, if amount_column is blank, the quantity can be set to "1".

[0117] By repeating these operations, a standard master can be created that works for any game manufacturer and any title. As explained with reference to Figure 10, the master that breaks down the largest group into smaller groups is group_trans_1_conf(1010), which further breaks it down into smaller groups is group_trans_2_conf(1020), which further breaks it down into smaller groups is group_trans_3_conf(1030), and so on, creating a structure where masters with the same structure can be linked indefinitely. When mapping is performed in this state, according to the logic described above, the output will show this group_id and this separation_id, and furthermore, the reference destination will be separated depending on whether it is a first-time reward or a reward that is given every time.

[0118] Figure 11 is a table that organizes and lists each item, its quantity, and its weight, based on Figure 10, which shows the standard master data of this disclosure. Each table in Figure 11 contains, from left to right, row number, group_id, separation_id, select_type, amount (quantity), and weight (weight).

[0119] The three masters shown in Figure 11, group_trans_1(1110), group_trans_2(1120), and group_trans_3(1130), are structured so that when the action indicated in the group_id column is performed, the amount of the item listed in the separation_id column is obtained according to the amount listed in the amount column. Next, the item with separation_id becomes the group_id of the next group_trans_x (where x is an integer greater than or equal to 1). For example, if group_id for group_trans_1(1110) is "10001" and separation_id is "1001", then the group_id of the next group_trans_2(1120) will also be "1001" (following the 1111 sequence), and it will be further broken down into the item ID (separation_id) "11", and so on, creating a relationship between group items and their decomposed parts. In this way, all masters are standardized and can be migrated to the standard master of the template to which this disclosure is applied.

[0120] Based on this, a calculation is performed to determine the expected number of items that can be obtained by executing the action "10001" once.

[0121] The flow from group_trans_1(1110) to group_trans_3(1130) is as follows: group_id(group_trans_1(only the last number will be displayed below)) → separation_id(1):rate(1),amount(1) group_id(2) → separation_id(2):rate(2),amount(2) group_id(3) → separation_id(3):rate(3),amount(3)

[0122] Here, when a group_id(x) is obtained using group_trans_x, it is possible to obtain multiple separation_ids (x,m(1)), separation_id(x,m(2)), ..., separation_id(x,m(n)) for a single group_id(x). In this case, rate(x,m(k)) is defined as the probability of obtaining separation_id(x,m(k)) when group_id(x) is obtained.

[0123] In this case, each k: 1 ≤ k ≤ n, and W(separation_id(x, m(k))) is the weight of separation_id(x, m(k)).

[0124] At this time, Equation 1 is,

number

[0125] Next, let us make the following assumptions. A: Action I: Item Depth(A,I): A variable x such that when action A is performed, equation 1 results in separation_id(x,m(k)) = item I (in the diagram below, x=3). E(A,I): Expected number of items I obtained when action A is performed. s(i,k): The separation_id used in group_trans_i when calculating the expected number of items I obtained when action A is performed.

number

[0126] Below, we will explain some specific examples with reference to Figure 11.

[0127] <In the case of quest rewards> Playing Quest 10001 once will reward you with Item Group 1001 and Item Group 201. The breakdown of each group is as follows: The first item you can get (select_type is first), Item group 1001 = 11 items × 10 (see row 1 of group_trans_2) As an item that can be obtained each time (select_type is loop), Item group 201 = Item 21 × 5 + Item 22 × 5 (See rows 3 and 4 of group_trans_2 and rows 1 and 2 of group_trans_3) Therefore, when you add both together, Quest 10001 = Item 11 x 10 + Item 21 x 5 + Item 22 x 5 This is the result.

[0128] <In the case of gacha> In Quest 10001, the expected value of UR_A obtained when drawing 501 gacha once can be calculated by referring to row 7 of group_trans_1, as follows: In Gacha 501, the UR rate is 5% (see row 11 of group_trans_2), and within UR there are UR_A and UR_B (see rows 11 and 12 of group_trans_3), Expected value = 1 × 0.05 × 0.5 = 0.025 Therefore, the expected value of UR_A when drawing Gacha 501 once is 0.025.

[0129] Figure 12 shows the expected values ​​of each item calculated from Figure 11, which shows the output when this disclosure is applied. In Figure 12, the flag in the rightmost column, "First Time," is "TRUE" if the action is performed for the first time, and "FALSE" for subsequent times. That is, rows where the "First Time" column is TRUE indicate items for which the action is given only on the first time, and rows where the "First Time" column is FALSE indicate items for which the action is given for subsequent times.

[0130] Furthermore, rows 1 to 9 in Figure 12 show items obtainable from quests, while rows 10 to 17 and rows 19 to 26 show items obtainable from gacha. In other words, in rows 1 to 9, the action name column contains the quest number, and in rows 10 to 17 and rows 19 to 26, the action name column contains the gacha number.

[0131] For example, looking at row 1 in Figure 12, when action 10001 is performed, item 11 is received in quantity 10.0 only on the first execution (i.e., the first column is TRUE). Looking at row 2, we can see that even when the same action 10001 is performed as in row 1, if it is the second or subsequent execution of the action (i.e., the first column is FALSE), item 21 is received in quantity 5.0.

[0132] On the other hand, looking at row 10 in Figure 12, we can see that when the gacha action 50001 is performed, the item SR_A can be obtained with a probability of 0.266 from the second time onward. In this example, the column for the first gacha, listed from row 10 to row 27, is all "FALSE (second time onward)".

[0133] Figures 8 to 12 illustrate an example where the masters in the original Figures 8 and 9 are nested, while Figures 13 to 16 show an example where the master in the original Figure 13 is not nested.

[0134] Figure 13 shows a non-standard master. The masters listed in Figure 13 are non-standard masters, and include battle_master(1310), which is related to battles, and event_gacha_master(1320), which is related to gacha. Each master is a single master, and there are no child masters that reference it, so it does not have a nested structure (i.e., a hierarchical structure).

[0135] In Figure 13, the IDs of the final items received on the first attempt, as well as the IDs and quantities of the final items received on subsequent attempts, are listed in a single master file, linked to the IDs of battle_master(1310) (i.e., 3001, 3002, 3003, 3004, and 3005).

[0136] For example, if you refer to battle_master(1310) for battles, the IDs of the items you receive the first time are listed in the first_treasure_id column from top to bottom as 111, 111, 111, 111, and the quantities you receive for each ID are listed in the first_treasure_amount example from top to bottom as 5, 10, 15, 20, and 25. On the other hand, the IDs of the items you receive each time are listed in the random_treasure_id column from top to bottom as 222, 222, 222, 222, and the quantities you receive for each ID are listed in the random_treasure_amount example from top to bottom as 50, 100, 150, 200, and 250.

[0137] For example, in a battle with item ID 3001, the first time you receive item ID 111, you get 5 of them, and each time you receive item ID 222, you get 50 of them.

[0138] Furthermore, in Figure 13, the other master, event_gacha_master(1320) for gacha, lists the weight of each card, linked to the ID 100001. For example, if the gacha ID is 100001 and the card is UR_AA, the weight is 1, and if the gacha ID is 100001 and the card is SSR_AA, the weight is 4. The relationship between weight and probability is as described above.

[0139] Figure 14 shows the non-standard master data from Figure 13 converted to a standard master data to which this disclosure applies. The master data in Figure 13, battle_master(1310) and event_gacha_master(1320), contains the final information within the master data itself regarding the quantity or weight of each item that can be obtained, and has a simple, non-hierarchical structure. Therefore, even when the master data in Figure 13, battle_master(1310) and event_gacha_master(1320), are converted to a standard master data, only one table, group_trans_1_conf, is required for mapping.

[0140] The basic structure of Figure 14 is the same as that of 1010 in Figure 10, so it is omitted here.

[0141] When the master in Figure 13 is converted to a standard master to which this disclosure is applied, it can be organized into an output similar to the master shown in Figure 8, as shown in Figure 15, and an expected value list similar to the one shown in Figure 16 can be calculated.

[0142] Figure 15 shows the output of a standard master applying the disclosure shown in Figure 14. In this figure, rows 1 to 10 represent quests, and rows 11 to 26 represent gacha. For example, in the case of a quest, referring to row 1 of group_trans1, if group_id is 3001 and separation_id is 111, then select_type is first and amount is 5. Similarly, in the case of a gacha, referring to row 11, if group_id is 100001 and separation_id is UR_AA, then select_type is random, amount is 1 and weight is 1.

[0143] In line 1, the reason `select_type` is set to `first` is not because `separation_id` is 111, but simply because, as a setting, when you complete the quest with `group_id` 3001, there is a set of items that you can receive, and the setting that you receive 5 of the item with `separation_id` 111 is set in the original master to be a first-time reward that you can only receive the first time. Here, `select_type` is set to `first` to make it clear that it is a first-time reward. For example, when you complete the quest with `group_id` 3001, you can receive 5 of the item with `separation_id` 111 the first time (first), and separately, there may be a setting that allows you to receive 1 of these items each time (loop), even after the first time, as a loop reward.

[0144] Figure 16 shows a list of expected values ​​for a standard master applying the disclosure shown in Figure 14. In this figure, rows 1 to 10 represent quests, and rows 11 to 26 represent gacha. For example, referring to row 1 in Figure 16, we can see that when the action name is 3001, item name 111 is obtained only on the first attempt (TRUE) in quantity 5.0. Also, referring to row 11, we can see that when the action name is 100001, item name UR_AA is obtained with an expected value of 0.01.

[0145] Figure 17 shows a diagram of gameplay assumptions. In this table, the assumed number of actions per day (i.e., gameplay assumptions) is created for each action. Specifically, there are two gameplay assumption tables: story_quest_master(1710) for quests and gacha_master(1720) for gacha. In the story_quest_master(1710) at the top of Figure 17, the id column lists the quest IDs from top to bottom as 10001, 10002, and 10003. The three columns to the right of the id column list the number of times the player performs each quest on each day (day1, day2, day3). For example, let's assume that the player performs quest id 10001 5 times on day1, 3 times on day2, and 0 times on day3. In this case, a blank action_num (number of actions) represents 0.

[0146] Furthermore, in the id column of gacha_master(1720) at the bottom of Figure 17, the gacha IDs are listed from top to bottom as 50001, 50002, and so on. The three columns to the right of the gacha IDs show the number of times the player performs each gacha on each day (day1, day2, day3). For example, let's assume that the player performs the gacha with gacha ID 50001 2 times on day1, 3 times on day2, and 0 times on day3. In this case, a blank space in action_num (number of actions) represents 0 times.

[0147] Figure 18 shows the daily number of items obtained for each action. By multiplying the expected value described in Figure 12 by the assumed daily number of actions described in Figure 17, we can calculate how many items can be obtained each day for each combination of action and item.

[0148] In Figure 18, rows 1 to 9 represent quest actions, and rows 10 to 27 represent gacha actions.

[0149] For example, looking at row 1, the action name at this time is "10001" and the item name is "11". Referring to Figure 17 above, the number of actions is 5 on day 1, 3 on day 2, and 0 on day 3. Therefore, multiplying the amount in the corresponding row in Figure 12 by the number of actions on each day gives the number of items acquired on each day. For example, in the case of row 1, the number of items acquired on day 1 is 10 × 5 = 50, the number of items acquired on day 2 is 10 × 3 = 30, and the number of items acquired on day 3 is 10 × 0 = 0.

[0150] Next, looking at row 10, for example, the action name is "50001" and the item name is "SR_A". The number of actions is 2 on day 1, 3 on day 2, and 0 on day 3. Multiplying the amount in the corresponding row in Figure 12 by the number of actions on each day gives the amount acquired on each day. For example, in the case of row 10, the amount acquired on day 1 is 0.266 × 2 = 0.532, the number of items acquired on day 2 is 0.266 × 3 = 0.798, and the number of items acquired on day 3 is 0.266 × 0 = 0.

[0151] In Figure 18, the same item is listed in combination with multiple actions. For example, the item named "11" is listed in rows 1, 4, 7, and 18 with different actions 10001, 10002, 10003, and 50001, respectively.

[0152] Figure 19 is a graph summarizing the daily acquisition count of each item according to the assumed play scenario. By totaling the number of identical items obtainable through each action, it is possible to predict the total number of each item acquired over multiple days of play. The examples for day 1 (Day 1), day 2 (Day 2), and day 3 (Day 3) in Figure 19 show the total number calculated by organizing the results of the aforementioned assumed number of plays × expected value for each day for each item. The example on the far right, "total," represents the total for each item over the three days from day 1 to day 3.

[0153] For example, if you have an item named "11", you can obtain a total of 10 of them on day 1, 20 on day 2, and 130 on day 3. Therefore, if you play this game for these three days, you can obtain a total of 160 items of item "11".

[0154] For example, if you play this game for three days, you can obtain a total of 1.862 units of the item SR_A. 0.532 units can be obtained on day 1, 0.798 units on day 2, and 0.532 units on day 3.

[0155] In Figure 19, item names 11, 21, and 22 represent items obtainable through quests, while SR_A through UR_E represent items obtainable through gacha.

[0156] Figure 20 is a table illustrating item consumption. While Figure 19 explained the acquisition amount of each item, Figure 20 explains the consumption amount of each item. Similar to item acquisition, item consumption is calculated by multiplying the number of items consumed by the number of plays in the expected value list in Figure 12, where the quantity column is negative. In Figure 12, which shows the expected values, the only items with negative quantities are item 11 in row 18 and item 21 in row 27. Conversely, in the example in Figure 12, items other than item 11 and item 21 are not consumed.

[0157] Looking at the row for item 11 in Figure 20, we see that 40 items were consumed on day 1, 60 on day 2, and 0 on day 3. Therefore, the total consumption of item 11 over these three days is 100.

[0158] For example, in the example shown in Figure 20, it can be seen that 100 units of item 11 and 40 units of item 21 are consumed in total over three days, but no other items are consumed (i.e., the total number of items consumed is zero).

[0159] Figure 21 is a table showing the balance of each item. The balance of each item (=acquisition amount - consumption amount) can be calculated from the amount of each item acquired (calculated in Figure 19 according to the gameplay scenario) and the amount of each item consumed (calculated in Figure 20 according to the gameplay scenario). In this way, by finding the difference between the number of items acquired and the number consumed for each item, the balance of items in the game can be determined.

[0160] For example, item 11 has a balance of -30 on day 1, -40 on day 2, and 130 on day 3, so the balance for these three days is 60.

[0161] For example, item SR_A has a balance of 0.532 on day 1, 0.798 on day 2, and 0.532 on day 3, so the balance for these three days is 1.862.

[0162] Using the expected values ​​shown in Figure 12, the balance for each item in Figure 21 can be calculated using the method described for Figures 14 to 20. By calculating the amount of each item acquired and consumed in quests and gacha in this way, and then calculating the balance by subtracting the amount consumed from the amount acquired, the balance of magic stones and other items as described in Figure 6 above can be calculated.

[0163] By comparing the profit and loss of each item before and after parameter adjustments, and by adjusting the balance of profit and loss for each item or all items after parameter adjustments, it becomes possible to discover better parameters, that is, game parameters that allow you to earn more.

[0164] Figure 22 is a block diagram of a computer running a program that operates in accordance with the present disclosure. For example, computer 2200 running a program according to the present disclosure may include a processor 2210, graphics 2220, chipset 2230, memory 2240, network control 2250, keyboard / mouse 2260, and storage 2270, which are typically connected to each other by a bidirectional bus.

[0165] The processor 2210 executes programs stored in memory in cooperation with the chipset 2230. The chipset 2230 is controlled by the processor 2210 and controls the functions of the graphics 2220, memory 2240, network control 2250, keyboard / mouse 2260, and storage 2270.

[0166] The graphics control the internal or external display devices of the computer 2200. The network control 2250 is connected to an external network and controls wired or wireless LANs, etc. The keyboard / mouse 2260 is an input means for controlling the computer 2200 and may be integrated with the computer 2200 or be external. The storage 2270 includes a hard disk or optical disk and is controlled by the processor 2210 via the chipset 2230 to store data and / or instructions.

[0167] For example, a program containing instructions to perform steps S701, S702, S703, and S704, as described with reference to Figure 7, may be executed using the computer 2200 described in Figure 22.

[0168] The methods described herein may be performed using AI, including machine learning or deep learning.

[0169] This disclosure uses games as an example for the sake of explanation, but it is applicable not only to games but also to simulations in general, such as web services. For example, in a service where users can write articles, elements used in games, such as login bonuses, are incorporated based on the articles written by the user. Similarly, in manga apps where users can read manga using points, items can be received or used depending on the number of days logged in or actions taken. This disclosure is a concept that can be applied to fields that incorporate game mechanisms, such as such web services or apps. In the fields of such services, apps, and games, players are also called users. [Examples]

[0170] Next, we will describe Example 2. Example 2 may be implemented, for example, by a program called Auto Params according to the present invention.

[0171] <Overall Summary of Example 2> As mentioned above, it is generally not easy to find the optimal solution for a game or to set the optimal master settings. Therefore, the Auto Params according to the present invention is a method for adjusting the player's growth rate by searching for the optimal play for a general game and then automatically adjusting the master based on the results. In particular, there are two patterns for searching for the optimal play: (1) one that considers cases where the result changes due to randomness even if the user's actions are the same, and (2) one that calculates the user's actions by representing them with expected values ​​in order to reduce the computational load from a practical standpoint. Reinforcement learning of AI may be used in each of the searches for the optimal play.

[0172] Figure 23 is a flowchart outlining the method for calculating the optimal play. In Figure 23, first, instead of detailed play assumptions as in conventional methods, a rough play assumption is created (step 2301).

[0173] Next, since the efficiency of stat growth and resource gathering is crucial for gameplay, detailed gameplay scenarios that maximize efficiency under assumed gameplay conditions are calculated using reinforcement learning ε-greedy methods (Step 2302). Here, efficiency refers to the highest total value of the increase in stat parameters (such as various cards and characters representing advantages and disadvantages in the game) and the acquired resources (such as items) for a given amount of playtime and spending. While the increase in stat parameters is generally given more weight, the degree of emphasis can be adjusted for each game.

[0174] At the end of Figure 23, the optimal play for each content is calculated based on detailed play assumptions, determining what kind of play maximizes average stats and acquired resources over the same period (Step 2303). Each step is explained in detail below. Note that even if the user's actions are the same, the results are usually influenced by probability, such as in gacha or quest drop rewards. Therefore, there are two methods: one that considers the influence of the distribution of results, and one that calculates based on expected value without considering this. However, most parts are common, so differences will be described as needed.

[0175] In other words, there are two patterns for creating an optimal play scenario: (1) a computationally intensive but accurate method, and (2) a method with slightly lower accuracy but a lower computational load. When calculating in detail using method (1), it is desirable to analyze the efficiency of play, including variability, when playing multiple times using the Monte Carlo method, under the condition that there are both good and bad outcomes, such as the success or failure of gacha draws or the rewards sometimes received when defeating enemies. Based on this analysis, it is desirable to define the efficiency of play as an index that combines the maximum efficiency, average efficiency, median efficiency, or a combination of these with the standard deviation of the distribution, and then use a reinforcement learning ε-greedy method or similar to find the optimal play. While (1) this method is computationally intensive but accurate, the above method is computationally intensive, and in practical applications, there are many cases where such accuracy is not sufficient. Therefore, method (2) is less computationally intensive but slightly less accurate, in which case the expected value of resources consumed and acquired when playing each piece of content is defined, and the optimal play scenario is found using reinforcement learning ε-greedy methods or similar techniques based on the efficiency of playing based on these expected values.

[0176] <Program Structure> This Auto Pramas program may include one or more of the following elements in its configuration: • General game model • Optimal gameplay search (greedy algorithm, reinforcement learning, etc.) • Monte Carlo simulation that takes into account the randomness of gacha • Master automatic adjustment

[0177] <Preparation for execution> This shows an example of an implementation using the PYTHON® programming language. In this implementation, you navigate to the local directory and execute PYTHONPATH as follows. cd $auto_params / local PYTHONPATH=$PWD / This allows you to execute various test functions as follows: python tests / test_*py

[0178] <Input File> The following input files are commonly required to run this program. ·action.csv ·master_user_level_exp.csv ·resource.csv • power.csv ·level_up.csv ·setting_value.pickle ·setting_time.pickle

[0179] <General Game Model> This method considers implementation assuming a general-purpose game in which players complete quests using a deck of n cards. As mentioned above, cards have rarity, level, etc., and their combat power may be determined by these values. Within the game model (hereinafter also called the game function), a player object (hereinafter simply called the player) plays the game according to its choices. The game function primarily allows for the following actions, for example: Play quests • Pull the gacha

[0180] Various settings may be read from, for example, the standard master data of the applicant, Precious Analytics Co., Ltd. (hereinafter also referred to as PreAna). In addition, all items consumed or acquired in the game, as well as the characters that make up the deck, have predetermined values, and the player may aim to maximize the total value of the acquired items and characters by playing for a predetermined period of time (hereinafter, it will be assumed that the player plays to maximize the total value).

[0181] <Quest> Figure 24 shows the relationship between quest categories and play order. Quests are distinguished by categories that contain any type of quest (for example, "Story A," "Event A," "Event B," etc.). A play order is set within each category, and a quest in the next play order is only unlocked (i.e., becomes playable by the player) after the quests in the preceding play order have been cleared. In addition, each quest may have different stamina consumption values ​​and play reward values ​​for the first time and for subsequent times, and players may be able to play quests by consuming the required stamina and receive play rewards as a result.

[0182] For example, looking at the upper half of Figure 24, we see that Chapter n of Story A, 2401, is listed as a quest category. At this stage, Chapter n of Story A, 2401 has not yet been played (i.e., it is incomplete). Next, the player plays Chapter n of Story A, 2401 (Action!). As a result of playing, Chapter n of Story A, 2402 is completed (it is now complete), and the player can then play the next chapter, Chapter n+1 of Story A, 2403. Alternatively, if the player completes Chapter n of Story A for the first time, they may receive a first-time reward, 2404. In reality, it is not guaranteed that the story will be completed on the first play of Chapter n of Story A, 2401, but for simplicity, we have assumed that the chapter will be completed on the first play.

[0183] On the other hand, looking at the lower half of Figure 24, we see that Chapter n of Story A, 2411, is listed as a quest category, and at this stage, it is already cleared, indicating that the player has already completed Chapter n of Story A. Next, the player plays Chapter n of Story A, 2411 again (Action!). As a result of playing, Chapter n of Story A, 2412, is cleared again (already cleared), and this time, instead of the first-time reward, the player may receive the loop reward 2413, which is given for clearing it for the second time or later. In this case, since Chapter n of Story A has been cleared more than twice, Chapter n+1 of Story A may not be unlocked as a new quest.

[0184] <Quest Play Restrictions> When playing quests, the program described in this disclosure may, if necessary, impose the following restrictions through master settings. • Minimum Total Combat Power Value: By setting this minimum total combat power value, if a player reaches a certain quest and the total combat power value of their deck at that point is below the pre-set value, that player will not be able to play that quest at that time (for example, it is assumed that they will not be able to clear it). • Play Limit: If a player exceeds the set play limit for a quest, they will not be able to play that quest. (This is intended for scenario stories that can generally only be played once, or event quests with play limits.)

[0185] <Regarding features where the outcome is determined by probability, such as gacha and drop rewards> In the program disclosed herein, for example, two types of gacha may be implemented: an expected value-based gacha (hereinafter also referred to as an expected value gacha) and a random gacha. Similarly, for rewards such as quest rewards, where the acquisition depends on probability, two types of so-called drop rewards may be implemented: an expected value-based drop reward and a random drop reward. • Expected Value Gacha: In an expected value gacha, cards are obtained in proportion to the expected value (e.g., if you draw a 10-pull gacha with a 5% chance of getting a rarity 5 card, statistically you will get 0.5 rarity 5 cards). Players maintain a cumulative value of the number of cards of each rarity, and when the cumulative value of cards of a rarity exceeds 1, one level 1 card is obtained, and 1 is subtracted from the cumulative value of cards of that rarity. --gacha_type “expect” This allows you to specify the expected value of the gacha. • Random Gacha: In the random gacha, cards of each rarity are drawn according to the set probability. --gacha_type “random” It is now possible to specify the type of draw you get from the random gacha.

[0186] <Player> A typical day for a game player might look like this: 1. Draw a 10-pull gacha once every 10 days. 2. Repeat the following until your stamina runs out. • The player selects and plays the most suitable quest from among the available quests. • Growth determination and character enhancement according to the master.

[0187] <How to strengthen your character> The method disclosed here, for example, determines which character to level up most efficiently from among the characters owned by the player, based on the ratio of the total value consumed to raise that character's level by one level to the increase in combat power, and employs a greedy method to level up that character.

[0188] <How to execute> For example, the following test function can be used to perform test calculations for game play. python tests / test_game_play.py \ --max_level 70 \ --deck_num 6 \ --action_type “greedy” --elapsed_days 60 \ --input_path “. / input_csv” \ --output_path “. / output_csv” \ --gacha_type “expect” \ --debug_mode false The arguments from the second line onward are optional, and for example, all the settings in this example are default values. max_level is the maximum level of characters in the deck, and can be set to a natural number less than or equal to 70. deck_num is the number of cards in the deck. action_type is the player's action guideline, and can be set to "random" (acting randomly), "greedy" (using a greedy algorithm), or "qlearning" (using reinforcement learning). The greedy algorithm and reinforcement learning will be explained later. input_path and output_path are the path where the input CSV file exists and the path to the output location, respectively. gacha_type is the type of character gacha, and can be set to "expect" (based on expected value) or "random" (one card is randomly drawn at a time with a probability). debug_mode is an argument provided for debugging, and if set to True, the processing time of the main processes will be output as logs.

[0189] <Exploring Optimal Gameplay> This method implements three different strategies: random quest play, greedy gameplay where the efficiency of playing each quest is known, and optimal gameplay using reinforcement learning (qlearning). ·greedy:greedy selects and performs the most efficient quest based on the ratio of the total value gained from playing each quest to the stamina consumed. --action_type “greedy” This can be used to specify it. • qlearning: To explore the optimal play, the reinforcement learning ε-greedy method may be used, and the Monte Carlo method may be used to learn the Q-value. An important advantage of applying reinforcement learning is that it is possible to produce the optimal solution even if the amount of items obtained from the quest is not known in advance. In reinforcement learning, the state s that represents the environment and situation at that time, the action a taken by the agent (in this program, the player) at that time, and the reward obtained by action a are generally important. The state s may be the date and stamina, and the action a may be playing a quest. By taking action a, stamina may be consumed, a reward may be obtained, and the deck may be strengthened. The reward may be the items obtained and the increase in total value obtained by strengthening the deck.

[0190] Figure 25 illustrates reinforcement learning. First, the master to be used is input (step 2501). Next, either the optimal play or random selection is chosen, and reinforcement learning is performed using the ε-greedy method to calculate the reward (step 2511). Then, the Q-score is updated using the Monte Carlo method with the calculated reward (step 2512). This training in step 2510 is repeated in reinforcement learning. Finally, the optimal play solution is output (step 2502). The details of each step in Figure 25 are explained below.

[0191] <ε-greedy method> The ε-greedy method is a type of reinforcement learning that avoids getting stuck in local minima due to biases in initial values ​​by taking random actions with a suitable, unlikely probability ε. As learning progresses, ε is updated to converge to 0. Learning is considered complete when, for example, ε falls below a certain value.

[0192] <Updating the Q-value using the Monte Carlo method> On date d, with stamina value s, state s=(d,s), the tth learning action a yields a reward r t If we obtain this, then the Q-value for the next learning session will be Q s,a(t+1) It is calculated as follows:

number

number

[0193] <Monte Carlo Simulation> The Monte Carlo simulation module allows you to simulate the relationship between the date on which you first obtain the highest rarity card (hereinafter referred to as day 5) when the gacha is completely random, its total value, and the total combat power of your deck. Normally, if you run many simulations, the distribution of day 5 counts by day will be skewed and form a bell curve, but in order to collect data uniformly, it is implemented so that you can specify day 5 for a given gameplay.

[0194] Figure 26 is a flowchart showing the procedure when using the Monte Carlo method. First, the master data and the number of simulations are entered (2601). Next, either optimal play or total force value calculation is selected (2602). Finally, the statistical distribution of the optimal play results is output (2603).

[0195] The Monte Carlo method can be implemented in the following way, for example: python tests / test_MonteCarlo.py 1000\ --max_level 70\ --deck_num 6\ --action_type “greedy” --elapsed_days 60\ --input_path “. / input_csv”\ --output_path “. / output_csv”\ --debug_mode True The first argument must specify how many cycles of Monte Carlo simulation to perform. The other arguments are the same as those for the `game` function, although the gacha type can be fixed to "random". However, to prevent overwriting, if a file required as input exists at the output file path specified by `output_path`, the file at the output file path will be read.

[0196] <Output file> The input files located in input_path are copied to the path specified by -output_path, and montecalo.log is also generated. An example of the generated output is shown below. [Table 1]

[0197] In the above generation example, cycle, power, rare5_first, and values ​​represent the number of simulations, total combat power, day 5 (the first day to obtain rarity 5), and total value, respectively. As an example, when using sample data and performing 10,000 simulations, the scatter plot of MP and total value is as shown in Figure 27. When the average total value for each day 5 is taken, it can be seen that it is distributed as shown in Figure 28.

[0198] Figure 27 is a graph showing the relationship between total value and the day on which a rarity 5 card was first acquired. In Figure 27, the vertical axis represents total value (total combat power), and the horizontal axis represents the day on which a rarity 5 card was first acquired. As the number of days on the horizontal axis changes from 0 to 60, from left to right, the total combat power also changes. For example, when the number of days on the horizontal axis is 0, the total combat power can be 136,000 or one of the six values ​​below it. However, as the number of days on the horizontal axis exceeds 10, that is, even if a rarity 5 card is first acquired on the 10th day or later, the probability of the total combat power exceeding 136,000 decreases.

[0199] Figure 28 is a graph showing the average values ​​for each date in Figure 27. The vertical axis of Figure 28 represents the average value of total value (total combat power) for each day, and the horizontal axis represents the day on which a rarity 5 card was first acquired. As can be seen from Figure 28, the average value of total value increases from day 0 to about day 5 on the horizontal axis, then decreases as the number of days increases, rises again in a wave-like manner after about 40 days, and finally drops sharply after about 55 days. [Examples]

[0200] Figure 29 is a flowchart illustrating the outline of Example 3. First, the details of optimal gameplay are obtained, and the amount of resources acquired and the amount of status increases at that time, as well as the amount acquired for each type of content (regular quests, event quests, PvP, gacha, etc.) (calculated results), are compared with the values ​​intended by the developers. As a result, the parameter settings are changed to reduce the difference and allow the system to learn (Step 2901). Next, when the difference falls below a certain value, it is considered to have converged, and parameter settings are found such that when the user plays with optimal efficiency, the amount of items acquired, the increase in status, and the distribution ratio for each type of content approach what the developers intended (Step 2902).

[0201] <Master automatic adjustment (auto params)> In the "auto params" module according to the present invention, the master settings may be automatically adjusted to achieve the total combat power value expected when playing optimally. A schematic diagram of this is shown in Figure 30.

[0202] Figure 30 is a flowchart showing the automatic adjustment method for the master according to the present invention. Referring to Figure 30, first, the master and assumed combat power values ​​are input (step 3001). Next, the optimal play and total combat power values ​​are calculated (step 3011). Then, the master is adjusted based on the calculated optimal play and total combat power values ​​(step 3012). This automatic adjustment, including steps 3011 and 3012, is repeated until the difference converges to a predetermined value (step 3010). As a result, the adjusted master is output (step 3002).

[0203] Expected combat power value P e The optimal power value P for play at the current master value. (t) Therefore, the vector m of the master values ​​before adjustment (t) The adjustment formula can also be as follows. For example, you can calculate by setting a specific value for a, such as 0.8 or 1.2.

number

[0204] The first argument may specify the maximum combat power value for the assumed optimal play. Furthermore, this method allows adjustment by specifying the story type and item type. In addition to the necessary input files, you may create and specify an "auto_params.csv" file like the one below. `id`, `major category name`, `Item`, and `adjustment multiplier` are the index, story type, item to adjust, and initial multiplier, respectively. Specifying an adjustment multiplier of 0 or greater will multiply the acquisition amount of the initially specified item by the adjustment multiplier. A value of 0 will result in no adjustment. Similar to Monte Carlo simulation, to prevent overwriting, if a file required as input exists at the output file path specified by `output_path`, the file at the output file path will be read.

[0205] [Table 2]

[0206] <Output file> Along with the master file with adjusted combat power, a log file called params.log, which records the process of adjusting the combat power values, may be generated with content similar to the following. The following example shows the process of adjusting the total combat power value from 990 (based on optimal gameplay before adjustment) to 900. [Table 3]

[0207] The adjustment process is shown in Figures 31 and 32. Figure 31 is a graph showing the change in the power value with a change in the number of cycles. Figure 31 shows that as the number of cycles is repeated, the power value gradually converges from 400 to around 300.

[0208] Figure 32 shows the master data before and after adjustment using the automatic adjustment method of the present invention. Referring to Figure 32, the table on the left (3210) shows the values ​​of character enhancement materials for each quest before adjustment, and the table on the right (3220) shows the values ​​of character enhancement materials for each quest after adjustment. Although this trend is not always observed, in the case of Figure 32, it can be seen that the values ​​of character enhancement materials for each quest and event have decreased from before adjustment (3210) to after adjustment (3220).

[0209] Figures 31 and 32 show the process of adjusting the total combat power value from 399 in the optimal play before adjustment (i.e., 0 attempts) to 301 (i.e., 300±1) in the final play (i.e., 5 attempts) (Figure 31), and the actual change in the master value (Figure 32). In this way, it can be seen that by adjusting the total combat power value in the optimal play, it is possible to approach the desired total strategic value.

[0210] <Summary of this disclosure> The game evaluation method according to Embodiment 1 of the present disclosure involves a computer performing the following steps: (A) calculating the product of the expected value of acquiring and consuming each item when a player takes an action, based on the parameters of a master, and the assumed number of times the player takes the action; and (B) visualizing the balance of each item based on the result of the multiplication.

[0211] The game evaluation method according to Embodiment 2 of the present disclosure is the game evaluation method according to Embodiment 1, wherein the computer further performs the steps of (C) changing the parameters in accordance with an instruction to change the parameters, and (D) recalculating the multiplication of the expected value and the assumed number of times based on the changed parameters, and visualizing the balance of each item based on the result of the recalculation of the multiplication.

[0212] The game evaluation method according to Embodiment 3 of this disclosure is the game evaluation method according to Embodiment 2, wherein the computer repeats steps (C) through (D) until the balance is less than or equal to a predetermined value.

[0213] The game evaluation method according to Embodiment 4 of the present disclosure is the game evaluation method according to Embodiment 1, wherein the master is a master whose format is unified among the multiple games, which has been converted from a non-standard master whose format is not unified among the multiple games.

[0214] The game evaluation method according to Embodiment 5 of this disclosure is the game evaluation method described in Embodiment 1, wherein in step (B) above, the change in the balance of each item over time is visualized.

[0215] The game evaluation method according to Embodiment 6 of this disclosure is the game evaluation method according to Embodiment 5, wherein in step (B) above, the time changes in the amount acquired and consumed of each item are further visualized.

[0216] The game evaluation device according to Example 7 of the present disclosure is a game evaluation device including a processor and a memory for storing instructions, and is configured to: (A) calculate the product of the expected value of obtaining and consuming each item when a player takes an action based on master parameters and the assumed number of times the player takes the action; and (B) visualize the balance of each item based on the result of the multiplication.

[0217] The game evaluation program according to Example 8 of the present disclosure causes a processor to execute instructions for performing: (A) a step of calculating the product of the expected value of obtaining and consuming each item when a player takes an action based on master parameters and the assumed number of times the player takes the action; and (B) a step of visualizing the balance of each item based on the result of the multiplication.

[0218] The app evaluation method according to Example 9 of the present disclosure includes: (A) a step of calculating the product of the expected value of obtaining and consuming each item when a user takes an action based on master parameters and the assumed number of times the user takes the action; and (B) a step of visualizing the balance of each item based on the result of the multiplication.

[0219] The method according to Example 2-1 of the present disclosure includes a step of inputting a master including play assumptions. Based on the play assumptions, a step of calculating more detailed play assumptions by reinforcement learning so that the efficiency is maximized. Based on the more detailed play assumptions, a step of calculating an optimal play such that the average of the statuses or the average value of the total amount of acquired resources within a predetermined period is maximized. A method executed by a computer.

[0220] <00​​​​The method relating to Example 2-3 of this disclosure is the method according to Example 2-2, wherein the ε-greedy method calculates the reward based on play assumptions or random selection.

[0222] The method relating to Example 2-4 of this disclosure is the method according to item 1 of Examples 2-1 to 2-3 of this disclosure, wherein in the reinforcement learning, the update of the Q value is calculated by the Monte Carlo method.

[0223] The method according to Embodiment 2-5 of this disclosure is a method in which a computer performs the following steps: inputting a master including play assumptions; and calculating more detailed play assumptions using reinforcement learning based on the play assumptions in a way that maximizes efficiency.

[0224] The method according to Embodiment 2-6 of this disclosure is a method that a computer performs the following steps: inputting a master including play assumptions and the number of simulations; calculating an optimal play or total combat power value based on the master and the number of simulations; and outputting a statistical distribution of the calculation results of the optimal play.

[0225] The program described in Example 2-7 of this disclosure is a program that includes instructions for executing the methods described in Examples 2-1 to 2-6 on a processor.

[0226] The apparatus described in Example 2-8 of this disclosure comprises a processor and memory, and is an apparatus for performing the methods of Examples 2-1 to 2-6.

[0227] The method according to Embodiment 3-1 of this disclosure is a method performed by a computer, comprising the steps of: calculating an optimal play based on predetermined parameter settings; comparing the amount of resources acquired, the growth status amount, or the amount of each content acquired obtained as a result of the calculation of the optimal play with the respective predetermined values, and learning to change the predetermined parameter settings based on the results so that the difference between the amount of resources acquired, the growth status amount, or the amount of each content acquired and the predetermined values ​​becomes smaller; and outputting the parameter settings when the difference becomes less than or equal to a predetermined value.

[0228] The method according to Embodiment 3-2 of the present disclosure is a method in which a computer performs the following steps: (A) inputting a master including an optimal play and an assumed combat power value; (B) calculating a total combat power value based on the optimal play; and (C) adjusting the values ​​of the master based on the total combat power value.

[0229] The method according to Example 3-3 of this disclosure is the method according to Example 3-2, wherein step (B) and step (C) are repeated until the total combat power value is less than or equal to a predetermined value.

[0230] The program according to Embodiment 3-4 of this disclosure is a program that includes instructions for executing the methods described in Embodiments 3-1 to 3-3 on a processor.

[0231] The apparatus according to Example 3-5 of this disclosure comprises one or more processors and memory, and is an apparatus for performing the methods of Examples 3-1 to 3-3. [Industrial applicability]

[0232] This disclosure is applicable, for example, to methods, apparatus, or programs for evaluating games. [Explanation of Symbols]

[0233] 101 UX Policy Decision 102 Game Logic Design 103 Parameter Settings 104 UX Visualization 105 KPI design 106 UX Check 201 Expansion Period 202 Rapid Decline 203 Gradual Decay Period 204 Core Fun 205 Feeling of Growth 206 Heroism 210 Maximizing Sales with Level Design 211 Maintaining Sales through Level Design 2200 Computers 2210 Processor 2220 Graphics 2230 Chipset 2240 Memory 2250 Network Control 2260 Keyboard / Mouse 2270 Storage 3210 Master before adjustment 3220 Master after adjustment

Claims

1. The process involves inputting a master file that includes a play scenario outlining how players will interact with the gamified content, which is comprised of multiple pieces of content. Based on the aforementioned gameplay assumptions, the following steps are taken: Reinforcement learning is used to calculate more detailed gameplay assumptions for each content, which maximize the efficiency of status growth and resource gathering. Based on the aforementioned more detailed gameplay assumptions, the step of calculating the optimal gameplay that maximizes the average value of the average status or the average value of the total amount of resources acquired over a predetermined period, How to run it on a computer.

2. The method according to claim 1, wherein the reinforcement learning uses the ε-greedy method.

3. The method according to claim 2, wherein the ε-greedy method calculates the reward based on play assumptions or random selection.

4. The method according to any one of claims 1 to 3, wherein in the reinforcement learning, the update of the Q value is calculated by the Monte Carlo method.

5. A step of inputting a master that includes a play scenario in which a player will perform gamification composed of multiple contents, Based on the aforementioned gameplay assumptions, the following steps are taken: Reinforcement learning is used to calculate more detailed gameplay assumptions for each content, which maximize the efficiency of status growth and resource gathering. How to run it on a computer.

6. A program comprising instructions for executing the method according to any one of claims 1 to 5 on a processor.

7. An apparatus comprising a processor and memory for performing the method according to any one of claims 1 to 5.

Images