Game evaluation method, device, 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 game evaluation method, device, and program. [Background technology]

[0002] In some games, after a game is released (launched), the parameters necessary for the game's operation are changed based on sales information such as the game's sales or the actual gameplay of the players. However, it has not been done before to evaluate a game from the player's perspective before the game is released (launched), visualize each parameter of the game based on the evaluation, and change or adjust the parameters of the game based on the evaluation.

[0003] In the game industry, during the development stage of a new game, a gameplay assumption is often created regarding how a player will play the game. Then, based on the parameter setting values ​​of the master for the created gameplay assumption, a partial simulation is performed to determine how many items a player will acquire and consume over time, or how much the player's status will grow, etc.

[0004] For example, if the items that can be acquired in Quest Chapter 1, Part 1 of a certain game are set to 1 item A and 5 items B, and if Quest Chapter 1, Part 1 is played 5 times, it is possible to simulate that the number of items that can be acquired in Quest Chapter 1, Part 1 is 1 item A x 5 times = 5 items, and 5 item B x 5 times = 25 items. However, such a simulation is a cumbersome and time-consuming task when there are a large number of quests and items, and has not actually been carried out.

[0005] Patent Document 1 describes evaluating the timing of the player's operation input after the game goes on sale, and changing the game difficulty level based on the evaluation. However, Patent Document 1 does not disclose evaluating and adjusting the game parameters before the game goes on sale (Patent Document 1). [Prior art documents] [Patent documents]

[0006] [Patent Document 1] JP 2019-457 A Summary of the Invention

[0007] As mentioned above, it is possible to create a game play scenario and calculate the amount of items and other items acquired in each content based on the game play scenario. However, for example, if there are 10 quests in one chapter and there are 10 chapters, there will be a total of 100 contents (10 quests x 10 chapters). In such a case, if you try to create a game play scenario, you will have to create 100 detailed game play scenarios for the 100 contents. In addition, in a normal game, there are various contents other than quests, and it is too time-consuming and unrealistic to create game play scenarios for each of those contents by detailed divisions such as difficulty level and stage. Therefore, such simulations have often not been performed before the game is released, or even if they have been performed, they have been partial and limited.

[0008] On the other hand, the only thing that could be visualized with the previous work mentioned above was 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 also depends on the situation, such as how the character is developed. What is important for game balance is the balance between the amount of items acquired and the amount consumed, rather than the amount of items acquired alone. When calculating the balance of such items, it is necessary to calculate the amount of items acquired and the amount consumed separately and compare them to determine whether the balance is appropriate, which takes even more time.

[0009] In addition, each parameter in the master file that describes the parameter setting values, etc., is intricately related to other parameters, and may even have a nested structure between multiple masters. For example, when calculating the items that can be obtained in Quest Chapter 1, Quest Chapter 1, 1 is further divided into three stages, and enemy monsters appear in each stage. When these monsters are defeated, three treasure chests of gold, silver, and bronze appear with a certain probability, and when each treasure chest is opened, a set of items corresponding to each treasure chest is obtained. The item composition of these sets of items usually includes multiple items, such as items A, B, C, etc., so it is complicated to simply calculate how much of each item you can obtain by clearing this quest. Furthermore, the composition of treasure chests varies greatly depending on the content and game, so if the game is different, of course, but if the content is different even within the same game, different simulation logic must be used, making the simulation complicated and time-consuming and labor-intensive.

[0010] For these reasons, looking at the overall balance of the game, including the income and expenditure of items, requires a huge amount of work and time. Furthermore, for example, when looking at the amount of item A acquired, in most cases the same item A can be acquired from multiple different pieces of content, and as mentioned above, different pieces of content have different master file structures, making it impossible to simulate them simultaneously. Therefore, the simulation results for each piece of content had to be calculated separately, and it was a very time-consuming task to show in a single graph how much of a certain item could be acquired from which piece of content.

[0011] When trying to simulate the balance of a game, it takes an enormous amount of work to create detailed gameplay scenarios, and when the game, content, or functions are different, it is necessary to create different simulation logic each time in order to perform the simulation. As a result, it has been virtually impossible to perform a comprehensive and detailed simulation of the balance of the entire game in the past.

[0012] Ultimately, if a game's income and expenditure balance is poor, the result will likely be unstable monthly sales for that game or unexpectedly low sales, which will result in low total revenue from that game. [Problem to be solved by the invention]

[0013] The problem that the present disclosure aims to solve is, as described above, the inability to maximize game sales by adjusting game parameters in advance and further optimizing the parameters by visualizing item income and expenditures before the game is released.

[0014] In the conventional method, a simulation was performed using a structured master and an assumed play scenario. In this method, the developer had to think up and set in detail how the user would play the game. For example, if there were quests from 1-1 to 1-10 and there were 5 chapters, the developer had to set the granularity of which quest would be played on which day and how many times for each of the 50 quests. However, in reality, it is difficult to set up such detailed scenarios, so in this invention, the settings (expected play scenarios) can be created automatically.

[0015] Furthermore, we invented a method to automatically tune the parameters so that they are balanced as intended when the game is actually played after the gameplay simulation is created. In other words, the method of the present invention can automatically create parameter settings that will result in the game's desired difficulty.

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

[0017] Another aspect of the present invention allows for parameter values ​​to be adjusted based on optimal play. [Means for solving the problem]

[0018] The game evaluation method according to the present disclosure includes a step in which a computer executes the steps of (A) calculating, based on master parameters, the multiplication of the expected value of acquiring and consuming each item when a player takes an action and the expected number of times the player will take the action, and (B) visualizing the balance of each item based on the result of the multiplication.

[0019] Another method according to the present disclosure includes the steps of: inputting a master including play assumptions; calculating more detailed play assumptions by reinforcement learning based on the play assumptions so as to maximize efficiency; and calculating an optimal play based on the more detailed play assumptions so as to maximize the average status or the average value of the total amount of acquired resources within a specified period of time, all of which are executed by a computer.

[0020] Another method according to the present disclosure includes a step of calculating an optimal play based on predetermined parameter setting values, a step of comparing the amount of acquired resources, the amount of expanded status, or the amount of acquired content obtained as a result of the calculation of the optimal play with each predetermined value, and a step of changing the predetermined parameter setting values ​​based on the result to learn to reduce the difference between the amount of acquired resources, the amount of expanded status, or the amount of acquired content and the predetermined value, and a step of outputting the parameter setting values ​​at that time when the difference becomes equal to or less than the predetermined value.

[0021] In addition, these comprehensive or specific aspects may be realized by a system, an apparatus, a method, an integrated circuit, a computer program, or a recording medium, or may be realized by any combination of a system, an apparatus, a method, an integrated circuit, a computer program, and a recording medium. Effect of the Invention

[0022] According to the present disclosure, by simulating the game balance before the game is released, the income / expense balance of the game can be easily evaluated and necessary adjustments can be made to each parameter. As a result of such parameter adjustments before the game is released, the game can steadily increase sales every month, which in turn makes it possible to increase the total sales from the game. [Brief description of the drawings]

[0023] [Figure 1] A diagram showing the steps in game level design [Diagram 2] A diagram showing the basic patterns of social game sales trends [Diagram 3] A diagram showing the amount of damage a player takes at each level when conquering a dungeon in a certain game. [Figure 4] A diagram showing an example of visualizing parameters by organizing masters. [Diagram 5] FIG. 1 shows an example of improving game operation by applying the present disclosure. [Figure 6] A diagram showing the balance of magic stones in a game before and after the application of the present disclosure. [Figure 7] Flowchart showing the application procedure of the present disclosure [Figure 8] Diagram showing non-standard nested masters [Figure 9] Diagram showing non-standard nested masters [Figure 10] FIG. 1 shows a standard master according to the method of the present disclosure. [Figure 11] A table showing each item and its quantity and weight in accordance with FIG. 10 showing the standard master of this disclosure. [Figure 12] A diagram showing the expected values ​​of each item calculated from Figure 11, which shows the output when this disclosure is applied. [Figure 13] Diagram showing non-standard masters [Figure 14] A diagram showing the non-standard master of FIG. 13 converted into a standard master by applying the present disclosure. [Figure 15] FIG. 15 shows the output of the standard master to which the present disclosure is applied as shown in FIG. [Figure 16] FIG. 15 is a diagram showing a list of expected values ​​of the standard master to which the present disclosure shown in FIG. 14 is applied. [Figure 17] Diagram showing expected play [Figure 18] A diagram showing the number of items acquired per day for each action [Figure 19] A chart showing the number of items acquired each day based on expected play [Figure 20] Table explaining item consumption [Figure 21] A table showing the income and expenditure for each item [Figure 22] FIG. 1 is a block diagram of a computer executing a program that performs operations according to the present disclosure. [Diagram 23] A flowchart outlining how to calculate the optimal play [Figure 24] A diagram showing the relationship between quest categories and play order [Diagram 25] Diagram showing reinforcement learning [Figure 26] Flowchart showing the procedure when using the Monte Carlo method [Figure 27] A graph showing the relationship between total value and the date of first acquisition of a rarity 5 card [Figure 28] A graph showing the average value for each date in Figure 27 [Figure 29] Flowchart showing an outline of the third embodiment [Diagram 30] 1 is a flowchart showing a method for automatically adjusting a master according to the present invention. [Diagram 31] A graph showing the change in combat power depending on the number of times [Diagram 32] FIG. 1 shows a master before and after adjustment by the automatic adjustment method of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0024] In this specification, the term "game" includes any type of computer game using any computer, including, without limitation, arcade games, consumer games, video games, portable games, PC games, mobile phone games, smartphone games, social games, browser games, NFT games, blockchain games, and crypto games. In addition, in DeFi (Decentralized Finance) using NFT and blockchain technology, unlike centralized mechanisms, there is no intermediary and transactions are conducted between users. However, unlike centralized mechanisms, there is no mechanism for a specific person to bear the various costs of intermediating the transaction and receive a reward in exchange, so transactions are difficult to complete as is. Therefore, in the field of DeFi, it is necessary to design a system that allows an unspecified number of users to earn some kind of reward in exchange for paying the transaction costs so that transactions can be conducted smoothly between an unspecified number of users, and it is necessary to optimize the reward balance defined in the smart contract, but the technology of the present application can be applied to such fields as well.

[0025] In this specification, for convenience of explanation, social games are mainly used as an example of games, but the application of the present disclosure is not limited to social games and can be applied to all types of games.

[0026] In this specification, a "social game" refers to an online game that is enjoyed by one or a group of users, and includes elements such as community and cooperation or competition between users. For example, in social games, players perform actions such as building a farm or a town, collecting cards and fighting with a deck, and progressing through stages while solving specific puzzles. The basic fee for playing a social game is usually free, and game providers make profits in the form of charges for purchasing items. Social games are also called "sociage."

[0027] Since basic terms in the social gaming field are not necessarily standardized among game manufacturers, the terms used in this specification are defined as follows.

[0028] A "character" is a person, animal, robot, machine, or fictional animal that appears in a game, and is a character involved in the game's story that is manipulated by the player to make the game happen. A "character" is also called a "character" or "game character."

[0029] The name "gacha" comes from a machine called "gacha gacha" or "gachapon," and in games it is a mechanism for randomly drawing items to obtain them. "Gacha" is usually partly free and partly paid.

[0030] A "card" is like an alter ego of the player used in the game. A deck (or team) is created by collecting multiple cards, and the deck is used to battle enemies or other players in the game. Cards are also called monsters in some games.

[0031] A "card" generally has four elements: "rarity," "cost," "parameters," and "skills." "Rarity" represents the rarity of the card. Generally, the rarer the card, the more difficult it is to obtain, i.e., the lower the probability of drawing it, and the more expensive it is. "Cost" is used as the "cost limit," which is the upper limit of the total cost of cards when multiple cards are lined up in a deck. "Parameters" are values ​​that represent the strength associated with the card. In general, other parameters are set, such as "attack power" or "defense power." The higher the "attack power," the stronger the damage the opponent will inflict by attack, and the higher the "defense power," the less damage the opponent will receive from the same attack power. "Skills" are unique abilities that the card can use. For example, there are abilities such as increasing one's own attack power or being able to attack first.

[0032] A "quest" is a task given to the player, and is used, for example, to help a character in trouble.

[0033] A "stage" is a structural unit of the game and represents a division of time.

[0034] A "dungeon" is an area where monsters appear and other traps are present, and the dungeon is the climax of the game.

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

[0036] An "item" is any item that a character can possess within the game.

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

[0038] A "boss" is the guardian of each stage, and by defeating the boss you can proceed to the next stage. EXAMPLES

[0039] Figure 1 is a diagram showing the steps in game level design. In general, in game development, "level design" refers to the task of adjusting the difficulty (i.e., numerical values) of various parameters used in the game. In apps such as social games, there is a strong image that level design = parameter setting. However, in this specification, level design is defined as a series of steps, starting from the upstream UX (User eXperience) policy, that is, the definition of what kind of experience should be delivered to the user, and including the subsequent data analysis.

[0040] If there is a problem with the upstream UX (user experience) policy decision 101 or game logic design 102, it may be difficult to increase sales no matter how much you adjust the parameter settings 103. Also, unless you analyze and check whether the parameter settings 103 satisfy the UX (user experience), you may not be able to adjust the parameters appropriately.

[0041] In this specification, level design includes steps such as UX (user experience) policy decision 101, game logic design 102, parameter setting 103, UX (user experience) visualization 104, KPI design 105, and UX (user experience) confirmation 106, as shown in Fig. 1. Although Fig. 1 illustrates six steps for convenience of explanation, these steps may be further divided, and some of the six steps may be integrated.

[0042] In this specification, level design includes a series of steps, from upstream UX policy decisions 101, i.e., the definition of what kind of experience should be delivered to the user, to the subsequent data analysis.

[0043] UX Policy Decision 101 is the stage where you decide the user experience policy, i.e. the specifications of the game.

[0044] In the next step, game logic design 102, consideration is given to what mechanism will allow users to enjoy the game, based on the UX policy decided in step 101. In other words, consideration is given to what logic or formulas will be used to realize the decided UX policy. For example, in a scene where players want to enjoy a group battle, the game logic corresponds to how many people will fight against each other, how long it will take, what attack methods are available, etc. On the other hand, when it comes to character growth, deciding what constraints to impose and how users will be able to use trial and error is included in game logic design 102.

[0045] In game logic design 102, the formula representing the difficulty level is considered based on a mathematical formula or the like to determine UX (user experience), such as whether the difficulty level should increase monotonically over time, whether the difficulty level should increase at an accelerated pace in the latter half of the game, or whether the difficulty level should ultimately converge to a certain value. If the game logic is broken or the formula representing the difficulty level is set inappropriately, it will be difficult to implement a game that sells based on that game logic, no matter how good the UX policy decided on upstream in the level design process is.

[0046] In the next step, parameter setting 103, a numerical value is assigned to each parameter in accordance with the previously determined UX policy and the designed game logic. In this parameter setting 103, it is necessary to quantitatively convert the outline of the UX policy into parameters.

[0047] For example, in the case of a city-building game, a UX policy for a certain accident that occurs might be, "This accident occurs surprisingly frequently and also inflicts great damage, making it a thrilling experience." In that case, the "occurs surprisingly frequently" part can be quantified, for example, to "occur once every 60 minutes," and the "damage is great" part can be quantified, for example, to "can wipe out up to 70% of the player's money." The "thrilling" part can also be set with a certain degree of range, for example, to "damage varies randomly each time between 10% and 70% of the player's money."

[0048] By determining the UX policy in this way, the player of this game can have a "thrilling experience" according to the determined UX policy. Also, by repeating the process of quantifying the UX policy into parameters in this way, parameter setting 103 that is less likely to cause errors is possible.

[0049] The next step is UX visualization 104, where the parameter settings are visualized and confirmed to be in line with the determined UX policy. In this case, test plays of the game by the players are necessary, but as a preliminary step, if the UX can be visualized at a numerical level to enable confirmation of parameters, accidents such as parameter setting errors can be significantly reduced. For example, UX is roughly expressed numerically, such as "how many days it takes to develop a certain character." In response to this, for example, a simulation can be performed and the UX can be visualized by organizing the master that describes each parameter.

[0050] By using a simulator to visualize the UX, it is possible to provide a mechanism to prevent a drop in sales due to incorrect parameter settings during operation.

[0051] For example, when entering a dungeon in a game to obtain an item, how much time it takes to get in that dungeon and how many items it takes are important UX (user experience). This can be visualized by organizing the master, which can help prevent accidents caused by parameter setting errors.

[0052] Next, in KPI Design 105, it is necessary to design KPIs (Key Performance Indicators) and make preparations to check the difference between the expected UX and the actual UX when playing the game. For example, if the game is expected to run on the image of "a heavy user plays a certain number of times a day, and takes a certain number of days to complete a quest up to this point," then the number of times that player group plays and the quest completion status will be the KPIs for checking that UX.

[0053] In the final step, UX confirmation 106, before the release of the game, the designed KPIs are checked to see if the expected UX is being provided. If the UX determined in UX policy determination 101 is not being provided as a result in UX confirmation 106, the process returns to game logic design 102 to reset the game logic, or returns to parameter setting 103 to readjust the parameters.

[0054] Figure 2 is a diagram showing the basic pattern of changes in sales of 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, it can be seen that there are three phases in game sales after the game goes on sale: "expansion phase 201", "rapid decline phase 202", and "gradual decline phase 203". The first stage after the game's release is the "expansion phase 201", where the number of users and average customer spending rise rapidly, resulting in a rapid increase in sales from the game. Next is the "rapid decline phase 202", where the number of users drops sharply and sales drop sharply. The last stage is the "gradual decline phase 203", where the number of users drops to a certain extent and sales also decrease.

[0056] A good game, in other words a game that sells, will gradually increase the number of users and sales after release, and even after the peak of maximum sales, the decline in sales will be gradual (i.e., there will be no sudden drop in the period of rapid decline 202). On the other hand, a game that does not sell will gradually increase the number of users and sales after release, and then the maximum peak sales will not be high, and thereafter, the number of users and sales will often rapidly decrease.

[0057] The maximum value (peak value) of sales depends largely on the potential of the game itself, that is, the appeal of the game itself, but by performing level design properly, it is possible to maximize sales during the expansion period 201 and to some extent prevent users from dropping out and sales from declining during the rapid decline period 202 or gradual decline period 203 after sales peak, which results in a significant increase in profits in the long term.

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

[0059] In contrast to the above-mentioned example where Rebeza was successful (solid line), in the example where Rebeza failed (dashed line), the maximum value of sales did not increase much during the expansion period 201, and the peak value of sales was also low (symbol 220). Then, sales dropped sharply during the subsequent rapid decline period 202 and gradual decline period 203 (symbol 221). As a result, in the example where Rebeza failed (dashed line), the total amount of sales from the start of sales to the final end of sales was also smaller than in the example where Rebeza was successful (solid line).

[0060] Before a game is released, it is often thought that the most important thing is whether it will sell, i.e., the maximum sales amount for a certain period of time. However, unlike in the past, it is now becoming more important to maintain sales that have been achieved once, so appropriate level design is more important than ever before.

[0061] There are several important elements associated with each of the three phases of the expansion phase 201, the rapid decline phase 202, and the gradual decline phase 203 shown in Figure 2. First, what contributes greatly to the first expansion phase 201 is "core enjoyment (204)". This core enjoyment (204) refers to the enjoyment of the in-game aspect of the app itself, as well as the appeal of the IP, characters, and worldview. Even in-game, it is possible to increase the enjoyment through game logic and parameter settings, but there may be some aspects of the core enjoyment (204) that simply cannot be achieved through level design alone.

[0062] Referring to the table at the bottom of FIG. 2, the importance of the core enjoyment of the game (204) through in-game and IP, etc. is high (◎) during the expansion period 201, and the importance of the core enjoyment of the game (204) is low (△) during the rapid decline period 202 and the gradual decline period 203.

[0063] The importance of the "feeling of growth (205)" due to status inflation and the like is high (◎) in the rapid decrease period 202, and is medium (○) in the expansion period 201 and the gradual decrease period 203.

[0064] The importance of the "sense of heroism (206)" resulting from the desire for recognition and the desire for self-exhibitionism tends to gradually increase over time, going from the expansion period (△) to the rapid decline period (○) to the gradual decline period (◎).

[0065] The sales of each game naturally depends on the potential of the game itself, that is, the appeal of the game itself, but even for the same game, by appropriately designing the level, it is possible to maximize sales early in the expansion period 201 and delay the attenuation in the subsequent rapid decline period 202 and gradual decline period 203, thereby maximizing the income obtained from a single game.

[0066] The important element in the rapid decline period 202 is the "sense of growth (205)." In other words, it is important for players to always experience the feeling that they are getting stronger the more they play the game. For example, in a card game, this corresponds to the inflation of card status (in other words, the phenomenon in which status, firepower, etc. continue to increase over time), but rather than simply inflating the card status, it is also important to create a mechanism that provides feedback to the player on the strength of the card.

[0067] The important element in the final tapering period 203 is the "sense of heroism (206)". This sense of heroism (206) is whether the player feels that he or she is doing something good. For example, the player may be ranked highly in the game, or the other players may think that the player is amazing because he or she has good cards or characters.

[0068] Especially in games that have long-lasting high sales, the design of this sense of heroism (206) is extremely important in the long term. If the player feels a sense of heroism (206), the possibility of playing the game for a long time and paying for it increases, which can lead to an increase in sales and the prevention of a decrease in sales.

[0069] These three important elements, core enjoyment (204), growth feeling (205) and heroism (206), cannot be completely separated from each other, but they roughly correspond to the three phases, expansion phase 201, rapid decline phase 202 and gradual decline phase 203, as mentioned above.

[0070] Figure 3 shows the amount of damage received by players at each level when clearing a dungeon in a certain game, i.e., the winning rate. The horizontal axis of the table lists the player's level in five levels, from beginner, novice, intermediate, advanced, and ranker, from the worst to the best at the game. 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 lists the wins and losses of players at each level in each area as win rates (%). Also, referring to the legend on the right side of Figure 3, the win rates are classified into five levels, from lowest to highest, in terms of UX (user experience): crushing defeat, narrow defeat, hard win, win, and easy win.

[0071] For example, in the case of an RPG (role-playing game) in which multiple areas are explored, the amount of damage (i.e., the amount of damage taken) that each player or party receives until each area is cleared is simulated. In FIG. 3, it is assumed that the boundary between winning and losing is 100% damage, and that if the amount of damage exceeds 100, it is a loss, and if the amount of damage is 100 or less, it is a win. With this simulation, for example, a beginner cannot clear Area 5 (the amount of damage taken is 110%, i.e., a close loss), but can just about clear Area 4, which is one level below Area 5 (the amount of damage taken is 90%, i.e., a close win).

[0072] On the other hand, an advanced player will easily clear Area 3 (40% damage taken, i.e., a breeze), barely clear Area 6 (75% damage taken, i.e., a tight win), and barely clear Area 7 (90% damage taken, i.e., a tight win).

[0073] In this way, the player's level and the difficulty of each area (i.e., the amount of damage taken) are listed in a table, and the UX is visualized comprehensively. Therefore, by visualizing the parameters as in Figure 3, parameter accidents caused by incorrect parameter setting can be significantly reduced.

[0074] In many cases, the reason sales drop significantly during actual game operation is that the parameters are not set properly. For example, parameter setting errors can occur, such as distributing too many important items and destroying the balance of the sense of growth, or making a certain character unbalanced and losing the sense of heroism, and in the long term, sales do not increase as much as expected.

[0075] Ultimately, these causes are due to incorrect parameter settings, but the direct cause could be a lack of visualization of UX (user experience).

[0076] Fig. 4 is a diagram showing an example of visualizing parameters by organizing the master (or master file) that defines the parameters. In the table (410) on the left side of Fig. 4, quest IDs, item IDs, and quantities contained in the game master are listed from the left column. Based on this table (410) on the left side, the table (420) on the right side organizes items by quest. In the table (420) on the right side, IDs, item names, and quest names are listed from the left column, and within the larger groupings of quest names, more detailed specific names of quests are listed, such as grassland, cave, and mine.

[0077] For example, in the table on the right of Figure 4 (420), in the row with ID=1, the item name is a medicinal herb, and it can be seen that there is one of this herb in the grassland, two in the cave, and three in the mines. Similarly, in the row with ID=2, the item name is a minor recovery potion, and it can be seen that there are two of this minor recovery potion in the cave, but none in the grassland or the mines. In the row with ID=3, the item name is a fragment, and it can be seen that there is one of this fragment in the grassland, but none in the cave or the mines. For IDs 4 to 6, the table on the right (420) lists how many iron ores, gems, and cards there are in each quest.

[0078] In this way, the table on the right (420) was created by organizing the table on the left (410) in the game's master format by item, and it is easier to understand from the table on the left (410) how many of each item can be obtained in each quest.

[0079] Fig. 5 is a diagram showing an example of improving game operation by applying the present disclosure. When designing a game, it is necessary to divide users into several categories and prepare content that players in each category can enjoy. In the example of Fig. 5, for simplicity, users are divided into three categories according to their game proficiency, namely, beginners, intermediate players, and core players (advanced players).

[0080] For example, when the game difficulty level for each user group is evaluated in the early stages of game design before the game is released, a situation may occur in which many players can clear the beginner content, but few players can clear the intermediate content, as shown in the left diagram (510) of FIG. 5. In such a case, players may get stuck in the intermediate level midway through the game. In such a situation, intermediate players in particular will not be able to move up to the higher core level, and so will lose motivation to play the game continuously. This will result in a decrease in sales from the large number of intermediate players, and sales of the game as a whole will also decrease.

[0081] In the case where the balance of players at each level who can clear the game is poor, as in the left diagram (510) of Fig. 5, the parameter evaluation of the present disclosure can be applied to the game before the game is released, making the content for the intermediate level easier than that in the left diagram (510), thereby achieving a balance in the number of players who can clear the content for each level, for beginners, intermediate level, and core level. In the right diagram (520), as a result of making the content for the intermediate level easier than that in the left diagram (510), more players can clear the content for the intermediate level (i.e., the number of players who can challenge the content for the core level increases), and intermediate level players continue to play more, so that the income obtained from the game as a whole can be further maximized.

[0082] FIG. 6 is a diagram showing the balance of magic stones in a game before and after the application of the present disclosure. As described above, magic stones are a type of item, and play a role similar to currency in the game. The horizontal axis of the diagram (600) before the application of the present disclosure and the diagram (650) after the application of the present disclosure, both show the number of days of play, from the first day of play on the leftmost side to the 60th day of play on the rightmost side. The vertical axis of the diagram (600) before the application of the present disclosure and the diagram (650) after the application of the present disclosure both show the balance (number) of magic stones. Of the three bar graphs for each number of days of play in each diagram, the leftmost bar graph shows the amount of magic stones acquired, the middle bar graph shows the amount of magic stones consumed, and the rightmost bar graph shows the difference (balance) obtained by subtracting the amount of magic stones consumed from the amount of magic stones acquired. From the left graph (600) and the right graph (650) of FIG. 6, it can be seen that in either case, the amount of magic stones acquired and consumed increases according to the number of days the player plays the game.

[0083] Referring to the diagram 600 before the application of the present disclosure, it can be seen that the balance (gain minus consumption) increases with the number of days played, from 1 day, 3 days, 5 days, 7 days, 14 days, 30 days, and 60 days. In addition, at the time of the 60th day of play, the amount of acquisition is 13,100, which is the total of 4,500 paid stones purchased, 5,000 from events, 3,000 from normal quests, and 600 from login bonuses. Referring to the diagram 600 before the application of the present disclosure, at the time of the 60th day of play, the amount of consumption is 8,400, which is the total of 6,000 from event gacha (even gacha) and 2,400 from normal gacha (free gacha is not considered here). Therefore, the balance, which is the amount of acquisition minus consumption, at the time of the 60th day of play before the application of the present disclosure is 4,700.

[0084] In contrast, referring to FIG. 650 after the application of the present disclosure, as the number of days played increases from 1 day to 3 days, 5 days, 7 days, 14 days, 30 days, and 60 days, the balance, which once increased on the third day, then fluctuates slightly, but eventually decreases. Also, at the point where the number of days played is 60 days, the amount of acquisition is 8350, which is the sum of 4500 purchased paid stones, 2500 events, 1050 regular quests, and 300 login bonuses. Referring to FIG. 650 after the application of the present disclosure, at the point where the number of days played is 60 days, the amount of consumption is 8400, which is the sum of 6000 event gacha (even gacha) and 2400 regular gacha. Therefore, the balance, which is the amount of acquisition minus the amount of consumption after the application of the present disclosure, is -50.

[0085] Thus, the balance on the 60th day of play before applying the present disclosure is 4700, which is a poor balance between the amount of magic stones acquired and the amount of magic stones consumed (i.e., the amount consumed is too small compared to the amount acquired).In contrast, the balance on the 60th day of play after applying the present disclosure is -50, which is a small difference between the amount of magic stones acquired and the amount consumed (i.e., a good balance between the amount consumed and the amount acquired), and the amount of magic stones consumed is also large, which encourages charging for gacha, and therefore income from the game can be further maximized.

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

[0087] In some cases, the parameters of all elements used in the game are described in a single master, but in other cases, the contents of a parent master are described in stages by child masters, grandchild masters, etc. In such cases, the masters have a multi-level nested structure. When masters have a nested structure, for example, an item in a parent master is specified in further detail in a child master, and in such cases, the details of that item cannot be known by looking at only the parent master.

[0088] First, when the program according to the method of the present disclosure is executed by a computer, a master in a non-standard master format is converted into a standard master format to which the present disclosure is applied (S701). The conversion of a non-standard master format into a standard master format (S701) may be performed by a computer or may be performed manually. Usually, all masters used in the game are provided by a game development company in a non-standard master format. Even if the games are developed by the same game development company, the master formats are not standardized for different games, or different versions of the same game, and the master formats are often different. The same standardized format is used as the standard master format regardless of the game production company, game, or game version.

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

[0090] Next, the amount of items acquired, consumed, and the balance between the amount of items acquired and consumed are simulated, and the results are visualized, thereby making it possible to visualize the results using the target parameters (S703). A diagram that visualizes the results of simulating the amount of items acquired, consumed, and the balance is, for example, the diagram (600) shown in FIG. 6, which has already been described.

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

[0092] By applying the present disclosure, game developers can improve the balance of item income and expenditure by looking at this imbalance in the diagram (600) in the upper left of Fig. 6 and appropriately adjusting each parameter in the master. The result of improving the income and expenditure by adjusting the parameters in this way is shown in the diagram (650) in the lower right of Fig. 6. Looking at the diagram (650) in the lower right of Fig. 6, it can be seen that the income and expenditure are balanced for each number of days of play since the start of the game, especially from the seventh day onwards (i.e., the height of the bar graph for income and expenditure is relatively low compared to the height of the bar graphs for the amount acquired and the amount consumed), and that the adjusted parameters are more appropriate in terms of maximizing sales.

[0093] After adjusting the parameters in S704, optionally, the process returns to S702 and calculates the expected value x assumed value again based on the adjusted parameters, and the item balance is simulated again based on the newly calculated result in S702, and the parameters are visualized again in S703. As a result, if further fine-tuning of the parameters is required, the parameters may be adjusted again in S704 based on the results of this simulation.

[0094] As a result of re-adjusting the parameters, steps S702 to S704 may be repeated once more if necessary.

[0095] The processes related to S701 and S702 in Fig. 7 will now be described in more detail with reference to Fig. 8 to Fig. 16. Fig. 8 and Fig. 9 show non-standard masters created by game production companies when creating a game, and Fig. 10 shows a standard master to which the present disclosure is applied.

[0096] Figure 8 shows a conventional, non-standard nested master structure. Four masters are shown in Figure 8, and their relationships will now be explained.

[0097] The top table in Figure 8 is the master (parent master) of a certain game, and is named story_quest_master (801). First of all, as a structure of such a non-standard (i.e. non-standard) master, when you draw a quest or gacha, if you take that action, what you can get, and with what probability, is included in the information of this master.

[0098] In some cases, the items that can be obtained are specified directly in a single master table, but in other cases, the ID of a group list of items that can be obtained indirectly is specified in the form of a reward group, etc. In addition, when you refer to another master that contains details of the target ID written in the master, a nested structure may be created in which yet another group list is specified there.

[0099] For example, in the example in Figure 8, there is a table called story_quest_master (801), which is the master (i.e. parent master), and the IDs of each story are written in the leftmost ID column as "10001", "10002", and "10003". 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 (first time), and a random_reward_group_id, which is the ID of an item that can be obtained every time. Each of these is listed in order in the columns to the right of the story ID column, such as 10001.

[0100] For example, in FIG. 8, if the story id is 10001, the group list of items specified by first_reward_group_id is 1001, and the group list of items specified by random_reward_group_id is 201.

[0101] In contrast, for a group of rewards that are only available the first time, there is another master (child master) called first_reward_group_master (802), which describes that a group with a group ID of "1001" can obtain "10" items (amount) with an item ID of "11" (flow 810). In this way, unless you go through two or more masters (in this case, two masters, a parent and a child), you may not be able to know specifically how many items you can obtain in the final target quest. For example, you can find out the amount of item 11 by referencing the child master called first_reward_group_master (802) from the parent master called story_quest_master (801).

[0102] Next, if the ID in story_quest_master (801) is "10001", the ID (random_reward_group_id) of the item that can be obtained each time is "201". When referring to yet another master (child master) random_reward_group_master (803), it is found that the random_reward_id of this item with ID "201" is "2001" (flow 820). Next, when referring to another master (grandchild master) random_reward_master (804), it is found that the item ID (item_id) for random_reward_id "2001" is "21", the weight is 10000, and the amount is "5" (flow 825). For random_reward_group_id, you cannot know the probability of getting which item unless you go through two separate masters (child master and grandchild master) called random_reward_group_master (803) and random_reward_master (804) (flows 820 and 825). In other words, in this case, the master has a three-tiered structure (i.e., there are three masters: 801, 803, and 804).

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

[0104] FIG. 9 is a diagram showing an example of the master structure of a gacha. FIG. 8 shows the master structure of a quest, while FIG. 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, as in FIG. 8. Referring to FIG. 9, first, the gacha_master (901) master records the gacha IDs as "50001" and "50002". For the items you can get for each gacha ID, the group to be referenced is specified in the lot_table_id column as "501" and "502". In other words, even if you only refer to the parent master gacha_master (901), you won't know what you'll get with what probability (in other words, the parent master gacha_master (901) does not have a column that indicates weight).

[0105] Next, by looking at the master gacha_lot_table_master (902), we can see that within the gacha group with ID "501", there are three levels of rarity: SR (Super Rare), SSR (Super Super Rare), and UR (Ultra Rare) (flow from 910). In the case of gacha, something can be obtained with a certain weight, so for example, if the gacha ID is 50001, the weights available for 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 and represents the relative ratio of occurrence of each event. Therefore, the probability of occurrence of each event is the weight of the target event divided by the total weight of the events in the same group. For example, in this case, for gacha ID 501, the probability of SR occurring is the sum of the weight of SR itself divided by the sum of the weights of all three of SR, SSR, and UR, that is, 100 (= 80 + 15 + 5), so the probability of SR occurring is 80 ÷ 100 = 80%. Similarly, the probability of SSR occurring is 15%, and the probability of UR occurring is 5%. However, the occurrence probability may be directly entered in the master without using the weight.

[0107] Next, for rarity, refer to gacha_prize_table_master (903), which is a master that describes what can be obtained in each group of SR, SSR, and UR. Referring to gacha_prize_table_master (903), the SR group contains three types of characters, "SR_A", "SR_B", and "SR_C", and the weight value of each is all "10" (flow of 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 each character has a probability of 33.3% (=10÷(10+10+10)).

[0108] In this way, with regard to the quest master, there are cases where a reward group is specified, such as first_reward_group_id (802) in Figure 8 mentioned above, or a group master (i.e., gacha_lot_table_master (902)) is specified, such as the gacha SR shown in Figure 9, and weights are applied to the percentage of items that will appear from among them. In addition, there are also cases where a group name such as SR, SSR, UR, etc. is specified rather than an individual item name, and a multiple nested structure is created where further detailed specifications are made within that group.

[0109] Typically, each master for each game has a one or more level nested structure, but the inventors thought that it would be possible to convert them into a unified standard master by specifying which are intermediate group combinations and which are final disassembled groups.

[0110] FIG. 10 is a diagram showing standard masters according to the method to which the present disclosure is applied. In the method to which the present disclosure is applied, the parent master is specified as group_trans_1_conf (1010). In group_trans_1_conf (1010), which columns are large and small groupings are specified. In a table according to the method to which the present disclosure is applied, the master (input_file) that is the input source 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 the story_quest_master (801) in FIG. 8 and the gacha_master (901) in FIG. 9, respectively.

[0112] In the method disclosed herein, the group_id_column in the three input masters in Fig. 10 is the quest name, and the column to the right of that is the separation_id_column, which specifies what can be obtained in that quest. In the case of a story quest, the ID of the main quest can be specified in the group_id_column, and the reward that can be obtained can be specified in the separation_id_column.

[0113] In the method disclosed herein, the largest master is specified as group_trans_1_conf (1010). In group_trans_1_conf (1010), which columns are large and which are small groups are specified. Furthermore, in select_type_column, if a reward can be obtained only the first time, it is specified as "first", and if a reward can be obtained every time, it is specified as "loop". In this example, select_type_column specifies two types, "first (only the first time)" and "loop (every time)", but this type 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, but since these group ids themselves cannot become the smallest unit called item_id, 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, it references the random_reward_group_master and gacha_lot_table_master in group_trans_2_conf (1020) to determine what group ID it has and which ID to ultimately look at. In the case of first_reward_group_master, the final item_id is listed in the separation_id_column in group_trans_2_conf (1020), so the value in group_trans_2_conf (1020) will be the final value for separation (reference), and the amount_column specifies the number of items to be acquired. For example, if the amount_column is blank, the quantity can be specified as "1".

[0116] Next, it refers to the random_reward_master and gacha_prize_table_master in group_trans_3_conf (1030) to determine what group ID it has and which ID to ultimately look at. In the case of random_reward_master, the final item_id is entered in the separation_id_column in group_trans_3_conf (1030), so the value in group_trans_3_conf (1030) becomes the final value for separation, the number of items acquired is specified in the amount_column, and the weight is specified in the weight_column. For example, if the amount_column is blank, the quantity can be set to "1".

[0117] By repeating this operation, you can create a standard master that can be used for any title from any game maker. 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 breaks down that even further is group_trans_2_conf (1020), which breaks down that even further is group_trans_3_conf (1030), and so on, creating a structure in which masters of the same structure can be linked one after another. When mapping is performed in this state, the output will show group_id and separation_id according to the logic described above, and the references will be separated depending on whether it is a first-time reward or a reward that can be received each time.

[0118] Fig. 11 is a table in which each item and its quantity and weight are organized according to Fig. 10 showing the standard master of this disclosure. In each table in Fig. 11, from the left column, the row number, group_id, separation_id, select_type, amount (quantity), and weight are listed.

[0119] The three masters, group_trans_1 (1110), group_trans_2 (1120), and group_trans_3 (1130) shown in FIG. 11, are in a format where if you take the action indicated in the group_id column, you will receive the amount indicated in the separation_id column. Next, the separation_id becomes the group_id of the next group_trans_x (where x is an integer equal to or greater than 1). For example, if the group_id of group_trans_1 (1110) is specified as "10001" and the separation_id is "1001", the group_id of the next group_trans_2 (1120) will be "1001" (the flow of 1111), and it will be further decomposed into the item id (separation_id) of "11", and the relationship between group and decomposed items will be gradually formed. In this way, all masters are standardized and can be migrated to the standard master of the template to which the present disclosure is applied.

[0120] Based on this, a calculation is made to determine the expected number of items that will ultimately be obtained when the action "10001" is executed 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 group_id(x) is obtained in group_trans_x, it is possible that multiple separation_id(x,m(1)), separation_id(x,m(2)), ..., separation_id(x,m(n)) are obtained for one 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, for each k: 1≦k≦n, let W(separation_id(x,m(k))) be the weight of separation_id(x,m(k)).

[0124] In this case, Equation 1 becomes:

number

[0125] Next, assume the following: A: Action I: Items Depth(A,I): A variable x such that separation_id(x,m(k)) = item I in formula 1 when action A is performed (in the figure below, x = 3) E(A,I): The expected number of items I obtained when taking action A. s(i,k): separation_id used in group_trans_i to calculate the expected number of items I obtained when action A is performed

number

[0126] Some specific examples will be described below with reference to FIG.

[0127] <Quest reward> When you play quest 10001 once, you will get item group 1001 and item group 201. The breakdown of each group is as follows: The first item you can take (select_type is first) is Item group 1001 = item 11 x 10 (see row 1 of group_trans_2) Items that can be taken each time (select_type is loop) are: Item group 201 = 5 items 21 + 5 items 22 (see rows 3 and 4 of group_trans_2 and rows 1 and 2 of group_trans_3) So, adding up both, Quest 10001 = Item 11 x 10 + Item 21 x 5 + Item 22 x 5 It becomes.

[0128] <In the case of gacha> In quest 10001, when you draw gacha 501 once, the expected value of UR_A is calculated as follows, referring to line 7 of group_trans_1. In gacha 501, UR is 5% (see row 11 of group_trans_2), and among the UR there are UR_A and UR_B (see rows 11 and 12 of group_trans_3), Expected value = 1 x 0.05 x 0.5 = 0.025 Therefore, the expected value of UR_A when drawing Gacha 501 once is 0.025.

[0129] Fig. 12 is a diagram showing the expected value of each item calculated from Fig. 11 showing the output to which the present disclosure is applied. The flag in the rightmost column "First Time" in Fig. 12 is "TRUE" if that action is the first time, and is "FALSE" from the second time onwards. In other words, a row with TRUE in the "First Time" column indicates an item for which that action is given only the first time, and a row with FALSE in the "First Time" column indicates an item for which that action is given from the second time onwards.

[0130] 12, rows 1 to 9 show items that can be obtained from quests, and rows 10 to 17 and rows 19 to 26 show items that can be obtained from gacha. That is, rows 1 to 9 have quest numbers in the action name column, and rows 10 to 17 and rows 19 to 26 have gacha numbers in the action name column.

[0131] For example, looking at row 1 in Figure 12, if you execute action 10001, you will receive a quantity of 10.0 for item 11 only the first time (i.e., the first time column is TRUE). Looking at row 2, you can see that even if you execute the same action 10001 as in row 1, you will receive a quantity of 5.0 for item 21 if you execute the action for the second or subsequent time (i.e., the first time column is FALSE).

[0132] On the other hand, row 10 in Figure 12 shows that when action 50001, which is a gacha, is performed, the item SR_A will be obtained with a probability of 0.266 from the second time onwards. In this example, the first gacha column listed in rows 10 to 27 all have "FALSE (second time onwards)".

[0133] 8 to 12 have described an example in which the masters of the parent of FIG. 8 and FIG. 9 have a nested structure, but FIGS. 13 to 16 show an example in which the master of the parent of FIG. 13 does not have a nested structure.

[0134] Figure 13 shows non-standard masters. The masters shown in Figure 13 are non-standard masters, and include battle_master (1310), which is a master related to battle, and event_gacha_master (1320), which is a master related to gacha. Each master is a single master, and does not have a nested structure (i.e., a hierarchical structure) without any child masters to refer to.

[0135] The ID and quantity of the final item that can be obtained the first time and the ID and quantity of the final item that can be obtained from the second time onwards are recorded in one master, linked to the ID of battle_master (1310) in Figure 13 (i.e., 3001, 3002, 3003, 3004, and 3005).

[0136] For example, looking at battle_master (1310) for battles, the IDs of the items you get the first time are listed in the first_tresure_id column as 111, 111, 111, 111, 111, and the quantities you get for each ID are listed in the first_tresure_amount column as 5, 10, 15, 20, 25, and the IDs of the items you get every time are listed in the random_tresure_id column as 222, 222, 222, 222, and the quantities you get for each ID are listed in the random_tresure_amount column as 50, 100, 150, 200, 250 ...

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

[0138] Moreover, in the other master in Fig. 13, event_gacha_master (1320) for gacha, the weight of each card is described in association with 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] Fig. 14 is a diagram in which the non-standard masters in Fig. 13 are converted into standard masters to which the present disclosure is applied. The masters battle_master (1310) and event_gacha_master (1320) in Fig. 13 contain final information about the quantity or weighting of each item that can be received, and have a simple structure that is not hierarchical. Therefore, even if the masters battle_master (1310) and event_gacha_master (1320) in Fig. 13 are converted into standard masters, only one table, group_trans_1_conf, is required for mapping.

[0140] The basic structure of FIG. 14 is the same as that of 1010 in FIG. 10, so a detailed description is omitted.

[0141] When the master in FIG. 13 is converted into a standard master to which the present disclosure is applied, it can be organized into the output shown in FIG. 15, just like the master shown in FIG. 8, and a list of expected values ​​as shown in FIG. 16 can be calculated.

[0142] FIG. 15 is a diagram showing the output of the standard master to which the present disclosure shown in FIG. 14 is applied. In this diagram, rows 1 to 10 represent quests, and rows 11 to 26 represent gacha. For example, in the case of quests, referring to row 1 of group_trans1, if group_id is 3001 and separation_id is 111, select_type is first (first time) and amount (quantity) is 5. Similarly, in the case of gacha, referring to row 11, if group_id is 100001 and separation_id is UR_AA, select_type is random, amount (quantity) is 1, and weight (weight) is 1.

[0143] In line 1, select_type is first (first time) not because separation_id is 111, but simply as a setting, when a quest with group_id 3001 is done, the items that can be received are set, and the setting value of receiving 5 items with separation_id 111 is set in the original master as an initial reward that can only be received the first time. Here, select_type is written as first so that it is clear that it is an initial reward. For example, when a quest with group_id 3001 is done, 5 items with separation_id 111 are given the first time (first), and it is also possible that the setting value is set so that one item is given each time (loop) other than the first time as a loop reward.

[0144] Fig. 16 is a diagram showing a list of expected values ​​of the standard master to which the present disclosure shown in Fig. 14 is applied. In this diagram, rows 1 to 10 represent quests, and rows 11 to 26 represent gacha. For example, referring to row 1 in Fig. 16, it can be seen that when the action name is 3001, an item with the item name 111 can be obtained for the first time only (TRUE) with a quantity of 5.0. Also, referring to row 11, it can be seen that when the action name is 100001, an item with the item name UR_AA can be obtained with an expected value of 0.01.

[0145] FIG. 17 is a diagram showing a play assumption. In this table, an expected number of actions per day (i.e., play assumption) is created for each action. Specifically, two play assumption tables are described: a story_quest_master (1710) table related to quests, and a gacha_master (1720) table related to gacha. In the ID column of story_quest_master (1710) at the top of FIG. 17, the IDs of the quests are described as 10001, 10002, and 10003 from the top. The three columns to the right of the ID column describe the number of times each quest is performed by the player on each day (day1 (first day), day2 (second day), and day3 (third day)). For example, assume that the player performs a quest with a quest ID of 10001 five times on day1, three times on day2, and zero times on day3. In this case, the blank in action_num (number of actions) represents 0 times.

[0146] Additionally, in the ID column of gacha_master (1720) at the bottom of Figure 17, the gacha IDs are listed as 50001, 50002 from the top. The three columns to the right of the gacha IDs list the number of times each gacha will be performed by the player on each day (day1 (first day), day2 (second day), day3 (third day)). For example, assume that the player performs the gacha with gacha ID 50001 twice on day1, three times on day2, and zero times on day3. In this case, the blank space for action_num (number of actions) indicates 0 times.

[0147] Figure 18 is a diagram showing the number of items that can be acquired each day for each action. The expected value shown in Figure 12 above is multiplied by the number of actions performed each day in the assumed play shown in Figure 17 to calculate how many items can be acquired each day for each combination of action and item.

[0148] In FIG. 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". With reference to FIG. 17 above, the number of actions was 5 on day 1 (first day), 3 on day 2 (second day), and 0 on day 3 (third day), so multiplying the amount of the corresponding row in FIG. 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, for example, looking at row 10, the action name is "50001" and the item name is "SR_A". The number of actions was 2 on day1 (first day), 3 on day2 (second day), and 0 on day3 (third day), so multiplying the amount of the corresponding row in FIG. 12 by the number of times on each day gives the amount acquired on each day. For example, in the case of row 10, the amount acquired on day1 is 0.266×2=0.532, the number acquired on day2 is 0.266×3=0.798, and the number acquired on day3 is 0.266×0=0.

[0151] In Fig. 18, the same item is described in combination with multiple actions. For example, the item name "11" is described in lines 1, 4, 7, and 18 with different actions 10001, 10002, 10003, and 50001, respectively.

[0152] FIG. 19 is a chart showing the total number of items acquired each day according to expected play. By adding up the number of the same items that can be acquired by each action, it is possible to predict the number of items acquired when playing over multiple days. The examples of day 1 (first day), day 2 (second day), and day 3 (third day) in FIG. 19 show the totals calculated by organizing the results of the calculations for each day of the aforementioned expected number of plays x expected value for each item. The example on the far right, total, shows the total for each item over the three days from day 1 to day 3.

[0153] For example, of items with an item name of 11, you can obtain a total of 10 on day 1 (the first day), a total of 20 on day 2 (the second day), and a total of 130 on day 3 (the third day), so if you play the game over these three days, you can obtain a total of 160 items 11.

[0154] Also, for example, an item with the name SR_A can be obtained in a total of 0.532 on day1 (the first day), in a total of 0.798 on day2 (the second day), and in a total of 0.532 on day3 (the third day), so if you play the game over these three days, you can obtain a total of 1.862 of item SR_A.

[0155] In FIG. 19, item names 11, 21, and 22 are items that can be obtained through quests, and SR_A to UR_E represent items that can be obtained through gacha.

[0156] FIG. 20 is a table explaining the consumption amount of items. While FIG. 19 explained the amount of each item acquired, FIG. 20 explains the consumption amount of each item. Consumption of items is similar to acquisition of items, and since negative values ​​in the quantity column in the expected value list in FIG. 12 indicate the number of items consumed, the type and amount of items consumed can be determined by multiplying the number of items consumed by the number of plays. In FIG. 12 showing the expected values, the two items with negative amounts are item 11 in row 18 and item 21 in row 27. Conversely, items other than item 11 and item 21 are not consumed in the example of FIG. 12.

[0157] Looking at the row for item 11 in Figure 20, consumption on day 1 was 40 units, consumption on day 2 was 60 units, and consumption on day 3 was 0 units, so the total consumption of item 11 for these three days is 100.

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

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

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

[0161] For example, the balance of item SR_A on day 1 is 0.532, on day 2 it is 0.798, and on day 3 it is 0.532, 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 by the method described with reference to Figures 14 to 20. In this way, the amount acquired and the amount consumed for each item in quests and gacha are calculated, and the balance is calculated by subtracting the amount consumed from the amount acquired, thereby making it possible to calculate the balance of magic stones as described above in Figure 6.

[0163] In this way, by comparing the income and expenditure of each item before and after parameter adjustment, and adjusting the balance of income and expenditure of each item or all items after parameter adjustment, it is possible to discover better parameters, i.e., game parameters that will earn you more money.

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

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

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

[0167] For example, a program including instructions for executing steps S701, S702, S703, and S704 described with reference to FIG. 7 may be executed using the computer 2200 described with reference to FIG.

[0168] The methods according to the present disclosure may be performed using AI, including machine learning or deep learning.

[0169] For the sake of convenience, the present disclosure has been described on the premise of a game, but the present disclosure is not limited to games and can be applied to simulations in general, such as web services. For example, in a service where a user can write an article, an element used in a game, such as a login bonus, is included when the user writes an article. Similarly, in a manga-related app where a user can read manga using points, items can be obtained or used depending on the number of days logged in and actions. The present disclosure is a concept that can be applied to fields that incorporate game mechanisms, such as web services or apps. Even in the field of such services, apps, and games, a player is also called a user. EXAMPLES

[0170] Now, a description will be given of Example 2. Example 2 may be implemented, for example, by a program called Auto Params according to the present invention.

[0171] <Overall Overview of Example 2> As described above, it is generally not easy to search for an optimal solution for a game or to set an optimal master. Therefore, the Auto Params of the present invention is a method for searching for an optimal play for a general game, and then automatically adjusting the master based on the search result, thereby adjusting the degree of growth of the player. In particular, there are two patterns for searching for an optimal play: (1) a case where the result changes due to randomness even if the user's behavior is the same, and (2) a case where the user's behavior is calculated by representing it with an expected value in order to reduce the load of the calculation amount from a practical viewpoint. In searching for each optimal play, reinforcement learning of AI, etc. may be used.

[0172] Fig. 23 is a flow chart showing an outline of a method for calculating an optimal play. In the case of Fig. 23, first, a rough play assumption is created (step 2301), instead of a detailed play assumption as in the conventional method.

[0173] Next, since the efficiency of status growth and resource gathering is important in game play, detailed play assumptions that maximize the efficiency under the assumed play conditions are calculated using the reinforcement learning ε-greedy method or the like (step 2302). Here, efficiency means, for example, that the total value of the increase in the status parameters of various cards and characters that indicate the advantage or disadvantage of the game, and the value of resources such as acquired items, is the highest for a certain playing time and charge amount. Note that, basically, the increase in the status parameters is given more importance, but the degree of emphasis may be changed for each game.

[0174] At the end of FIG. 23, the optimal play is calculated based on detailed play assumptions, that is, what kind of play will maximize the average status and amount of acquired resources in the same period for each content (step 2303). Each step is explained in detail below. Even if the user's behavior is the same, the result is usually influenced by probability, such as the probability of drop rewards in gacha or quests. Therefore, there are two methods: one that takes into account the influence of the distribution of the result, and one that does not take it into account and calculates based on the expected value. However, since most of the parts are the same, differences will be described as necessary where there are differences.

[0175] In other words, there are two patterns for creating optimal play assumptions: (1) a method that is computationally intensive but accurate, and (2) a method that is somewhat less accurate but has a low computational load. When calculating in detail (1), it is desirable to use a method in which the efficiency of play is analyzed, including variance, when multiple plays are performed using the Monte Carlo method under the condition that there are both hits and misses, such as uncertain factors in each content, such as hits and misses in gacha and rewards that are sometimes given when defeating enemies, and the efficiency of the play is defined as the index with the maximum efficiency, the average efficiency, the median efficiency, or a combination of these with the standard deviation of the distribution, and the optimal play is found based on the results by combining the reinforcement learning epsilon-greedy method or the like. The computationally intensive but accurate method (1) above imposes a heavy computational load, and in many cases less accuracy is sufficient in practice. Therefore, a method that uses a reinforcement learning epsilon-greedy method or the like to find the play scenario that maximizes the efficiency of play based on the expected values ​​of the resources that can be consumed and acquired when playing each piece of content is defined, and the efficiency of play is calculated based on the expected values. This method is slightly less accurate but less computationally intensive than the method (2).

[0176] <Program Structure> The Auto Pramas program may include one or more of the following components: General game model - Searching for optimal gameplay (greedy methods, reinforcement learning, etc.) -Monte Carlo simulation considering the randomness of gacha ·Master Auto Adjustment

[0177] <Preparation for execution> Here is an example of how to implement this using the PYTHON (registered trademark) programming language. In this implementation, move to the local directory as shown below and execute PYTHONPATH. cd $auto_params / local PYTHONPATH=$PWD / This allows you to execute various test functions as follows: python tests / test_*py

[0178] <input file> To run this program, the following input files are commonly required: action.csv master_user_level_exp.csv resource.csv power.csv level_up.csv setting_value.pickle setting_time.pickle

[0179] <General game model> In this method, implementation is considered assuming a general-purpose game in which a quest is cleared using a deck of n cards. As mentioned above, cards have rarity, level, etc., and their power value may be determined by these values. In the game model (hereinafter also referred to as game function), a player object (hereinafter also simply referred to as player) plays the game according to its selection. The game function mainly enables the following actions, for example: Play a quest -Draw gacha

[0180] The various setting values ​​may be read from, for example, the standard master of the applicant, Precious Analytics Co., Ltd. (hereinafter, also referred to as Pre-Ana). In addition, all items consumed or acquired in the game and characters that compose the deck have a predetermined value, and the player may aim to maximize the overall value of the acquired items and characters by playing for a set period of time (hereinafter, it is assumed that the player plays in order to maximize the total value).

[0181] <Quest> FIG. 24 is a diagram showing the relationship between quest categories and play order. Quests are categorized by categories with any type (for example, "Story A", "Event A", "Event B", etc.). A play order is set within each category, and the next quest in the play order is only unlocked (i.e., becomes playable by the player) once a quest assigned an earlier play order has been cleared. Also, each quest may be set with different stamina consumption values ​​and play reward values ​​for the first time and for the second or subsequent times, and the player may be able to play a quest by consuming the required stamina value and receive a play reward as a result.

[0182] For example, looking at the upper half of FIG. 24, chapter n 2401 of story A is listed as a quest category, and at this stage, chapter n 2401 of story A has not yet been played (i.e., not yet cleared). Next, the player plays chapter n 2401 of story A (Action!). As a result of the play, chapter n 2402 of story A is cleared (cleared state), and the player becomes able to play the next chapter n+1 2403 of story A. Also, when the player clears chapter n of story A for the first time, a first-time reward 2404 may be obtained. In reality, it is not always possible to clear chapter n 2401 of story A in the first play, but for simplicity's sake, it is assumed that the chapter can be cleared in the first play.

[0183] Meanwhile, looking at the lower half of FIG. 24, chapter n 2411 of story A is listed as the quest category, and it can be seen that at this stage, it has already been cleared and the player has already cleared chapter n of story A. Next, the player plays chapter n 2411 of story A again (Action!). As a result of the play, chapter n 2412 of story A is cleared again (cleared state), and this time the player may obtain a loop reward 2413 given for clearing the story for the second or subsequent times, rather than an initial reward. In this case, since chapter n of story A has been cleared more than twice, chapter n+1 of story A may not be opened as a new quest.

[0184] <Quest play restrictions> When playing a quest, the program according to the present disclosure may set the following restrictions by master settings, if necessary. Minimum total power value: By setting this minimum total power value, if a player reaches a certain quest and the total power value of the deck at that time is less than the preset value, the 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 the player has exceeded the play limit set for that quest, the quest cannot be played. (For example, this is intended for scenario stories that can only be performed once, or event quests that have a play limit.)

[0185] <Regarding features where results are determined by probability, such as gacha and drop rewards> In the program according to the present disclosure, 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. In addition, for rewards such as quests, which are known as drop rewards that can be obtained depending on the probability, two types of rewards may be implemented: an expected value-based drop reward and a random drop reward. Expected value gacha: In the case of expected value gacha, cards are obtained as expected values ​​(for example, if you draw a 10-series gacha once with a 5% probability of getting a rarity 5, you will statistically get 0.5 cards of rarity 5). Players keep track of the cumulative number of cards of each rarity, and when the cumulative number of cards of each rarity exceeds 1, you will get one level 1 card, and 1 will be subtracted from the cumulative number 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 released according to the set probability. --gacha_type "random" This allows you to specify a random gacha.

[0186] <Player> For example, a game player's daily activities are as follows: 1. Draw 10 gachas at once every 10 days. 2. Repeat the following until you run out of stamina. -Play the best quest from the available quests based on player choice -Growth assessment according to the master, character strengthening

[0187] <How to strengthen your character> In the method disclosed herein, for example, a greedy method is adopted in which the most efficient level increase is determined from among the characters possessed by the player based on the ratio of the total value consumed to increase that character by one level to the increased combat power value, and the level of that character is increased.

[0188] <How to run> For example, the following test function allows for test calculations of 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 onwards can be omitted, and as an example, all the settings in this example are default values. max_level is the maximum level of the characters in the deck, and can be a natural number below 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", which acts randomly, "greedy", which uses a greedy method, or "qlearning", which uses reinforcement learning. Greedy methods and reinforcement learning will be described later. input_path and output_path are the path to the CSV file for input and the path to the output location, respectively. gacha_type is the type of character gacha, and can be set to "random", which randomly dispenses one card at a time with an expected value-based "expect" probability. debug_mode is an argument prepared for debugging, and if set to True, the processing time of main processes can be output as a log.

[0189] <Searching for optimal gameplay> In this method, three different strategies are implemented: playing quests randomly (random), playing the game using a greedy method where the efficiency of playing each quest is known (greedy), and playing the game optimally using reinforcement learning (qlearning). Greedy: In greedy mode, the most efficient quest is selected based on the ratio of the total value gained by playing each quest to the stamina consumed. --action_type "greedy" It can be specified by: ·qlearning: To search for 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 an optimal solution even if the amount of items obtained from a quest is not known in advance. In reinforcement learning, generally, the important things are the state s indicating 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. The state s may be the date and stamina, and the action a may be the play of a quest. The action a may consume stamina, obtain a reward, and strengthen the deck. The reward may be the increment in total value obtained by the acquired items and strengthening the deck.

[0190] FIG. 25 is a diagram showing reinforcement learning. First, the master to be used is input (step 2501). Next, the optimal play or random selection is selected, reinforcement learning is performed using the ε-greedy method, and a reward is calculated (step 2511). Next, the calculated reward is used to update the Q value using the Monte Carlo method (step 2512). The training of this step 2510 is repeated in reinforcement learning. Finally, the optimal play solution is output (step 2502). Details of each step in FIG. 25 are explained below.

[0191] <ε-greedy method> The ε-greedy method is a type of reinforcement learning that takes random actions with a certain unlikely probability ε in order to avoid falling into a local solution due to bias in the initial values. As learning progresses, ε is updated so that it converges to 0. Learning is determined to be complete when, for example, ε becomes equal to or less than a certain value.

[0192] <Update of Q value using Monte Carlo method> On date d, in state s = (d, s), the reward r t If we obtain the Q value for the next learning, Q s,a(t+1) is calculated as follows:

number

number

[0193] <Monte Carlo Simulation> The Monte Carlo simulation module can simulate the relationship between the date on which the highest rarity card is first obtained (hereinafter referred to as day 5 (the 5th day)) and the total value and total power value of the deck when the gacha is completely random. Normally, if many simulations are performed, the distribution of day 5 counted by date will be skewed, but in order to collect data uniformly, the module is implemented so that day 5 can be specified for a certain gameplay.

[0194] 26 is a flow chart showing the procedure when using the Monte Carlo method. First, the master and the number of simulations are input (2601). Next, the optimal play or total strength calculation is selected (2602). Finally, the statistical distribution of the optimal play results is output (2603).

[0195] The Monte Carlo method is executed, for example, as follows. 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 As the first argument, you need to specify how many cycles of Monte Carlo simulation to perform. Other than that, it is the same as the arguments of the game function, but the gacha type can be fixed to "random". However, to prevent overwriting, if a file required as input exists in the output file path specified by output_path, the file on the output file path will be read.

[0196] <Output file> The input file in input_path is copied to the path specified by -output_path, and montecalo.log is generated. A sample of the generated file is shown below. [Table 1]

[0197] In the above example, cycle, power, rare5_first, and values ​​respectively represent the number of simulations, total power value, day5 (the first day rarity 5 was obtained), and total value. As an example, when 10,000 simulations were performed using sample data, the scatter plot of MP and total value is as shown in Figure 27. If the average of the total value for each day5 is taken, it can be seen that the distribution is as shown in Figure 28.

[0198] FIG. 27 is a graph showing the relationship between the total value and the day on which a rarity 5 card was first acquired. The vertical axis of FIG. 27 shows the total value (total power value), and the horizontal axis shows the day on which a rarity 5 card was first acquired. As the number of days on the horizontal axis changes from left to right from 0 to 60, the total strategic value also changes. For example, when the number of days on the horizontal axis is 0, the total power value can be 136,000 or one of the six values ​​below that, but when the number of days on the horizontal axis exceeds 10, that is, even if a rarity 5 card is first acquired after the 10th day, it can be seen that the probability of the total power value 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 shows the average value for each day of total value (total power value), and the horizontal axis shows the date when a rarity 5 card was first acquired. As can be seen from Figure 28, the average value of total value rises from 0 to about 5 days on the horizontal axis, and then as the number of days increases, the average value of total value drops again, and once the number of days exceeds 40 days, the average value begins to rise again in a wavy manner, and finally, once the number of days exceeds 55 days, the average value drops sharply. EXAMPLES

[0200] Fig. 29 is a flow chart showing an outline of the third embodiment. Once the details of the optimal play are presented, the amount of acquired resources and the amount of status growth at that time, as well as the amount acquired (calculated) for each of those contents (regular quests, event quests, PvP, gacha, etc.) are compared with the values ​​intended by the developer, and as a result, the parameter setting values ​​are changed to learn so that the difference becomes smaller (step 2901). Next, when the difference becomes equal to or less than a certain value, it is considered to have converged, and parameter setting values ​​are obtained such that when the user plays with optimal efficiency, the amount of acquired items, the growth of status, and the distribution ratio for each content will approach those intended by the developer (step 2902).

[0201] <Master auto adjustment (auto params)> An "auto params" module in accordance with the present invention may automatically adjust the master settings to achieve the expected total strength value for optimal play, as shown diagrammatically in FIG.

[0202] Fig. 30 is a flow chart showing a method for automatically adjusting a master according to the present invention. Referring to Fig. 30, first, a master and an expected strength value are input (step 3001). Next, an optimal play and a total strength value are calculated (step 3011). Then, the master is adjusted based on the calculated optimal play and total strength value (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, an adjusted master is output (step 3002).

[0203] Expected power value P e , the power value P in the optimal play at the current master value (t) Then, the vector m of the master values ​​before adjustment (t) The adjustment formula for may be as follows. For example, a is calculated by determining a specific value such as 0.8 or 1.2.

number

[0204] The first argument may be the maximum power value expected for optimal play. In addition, this method allows you to specify the story type and item type for adjustment, and you may create and specify the following "auto_params.csv" file in addition to the input files required otherwise. id, major category name, Item, and adjustment factor are the index, story type, item to be adjusted, and the factor to be adjusted initially, respectively. By specifying an adjustment factor of 0 or more, the amount of the item acquired that is initially specified is multiplied by the adjustment factor. If it is 0, no adjustment is made. As with the Monte Carlo simulation, to prevent overwriting, if a file required as input exists in the output file path specified by output_path, the file on the output file path is read.

[0205] [Table 2]

[0206] <Output file> Along with the master file with the adjusted power, a log file, params.log, showing the process of adjusting the power value may be generated with the following contents: In the example below, the total power value from the optimal play before adjustment is 990, and the total power value is adjusted to 900. [Table 3]

[0207] The adjustment process is shown in Figures 31 and 32. Figure 31 is a graph showing the change in power value depending on the number of cycles. Figure 31 shows that the power value (Power) gradually converges from 400 to around 300 by repeating the number of cycles.

[0208] Figure 32 is a diagram showing the master before and after adjustment by the automatic adjustment method of the present invention. Referring to Figure 32, the table on the left (3210) shows the value of the character strengthening material for each quest before adjustment, and the table on the right (3220) shows the value of the character strengthening material for each quest after adjustment. Although this tendency does not always hold, in the case of Figure 32, it can be seen that the value of the character strengthening material for each quest and event is smaller from before adjustment (3210) to after adjustment (3220).

[0209] The examples in Figures 31 and 32 show how the total power value from the optimal play before adjustment (i.e., number 0) is 399, and how it is adjusted so that the final total power value (i.e., number 5) becomes 301 (i.e., 300±1) (Figure 31), and how the master value actually changes (Figure 32). In this way, it can be seen that by adjusting the total power value from the optimal play, it is possible to approach the desired total strategic value.

[0210] Summary of this disclosure A game evaluation method according to a first embodiment of the present disclosure includes a step in which a computer executes the steps of (A) calculating, based on master parameters, the multiplication of an expected value of acquiring and consuming each item when a player takes an action and an expected number of times the player will take the action, and (B) visualizing the balance of each item based on the result of the multiplication.

[0211] A game evaluation method according to a second embodiment of the present disclosure is the game evaluation method described in the first embodiment, further comprising 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 expected number of times based on the changed parameters, and visualizing the balance of each item based on the recalculated multiplication results.

[0212] A game evaluation method according to a third embodiment of the present disclosure is the game evaluation method described in the second embodiment, in which a computer repeats steps (C) to (D) until the balance becomes equal to or less than a predetermined value.

[0213] A game evaluation method according to an embodiment 4 of the present disclosure is the game evaluation method described in embodiment 1, wherein the master is a master having a unified format among the multiple games that has been converted from a non-standard master having a format that is not unified among the multiple games.

[0214] A game evaluation method according to a fifth embodiment of the present disclosure is the game evaluation method according to the first embodiment, wherein in the step (B), a time change in the balance of each of the items is visualized.

[0215] A game evaluation method according to a sixth embodiment of the present disclosure is the game evaluation method according to the fifth embodiment, further comprising visualizing the change over time in the amount of each item acquired and consumed in the step (B).

[0216] A game evaluation device according to a seventh embodiment of the present disclosure is a game evaluation device having a processor and a memory for storing instructions, which (A) calculates the multiplication of an expected value of acquiring and consuming each item when a player takes an action and an expected number of times the player will take the action based on master parameters, and (B) visualizes the balance of each item based on the result of the multiplication.

[0217] A game evaluation program according to an eighth embodiment of the present disclosure causes a processor to execute instructions to execute the following steps: (A) calculating the multiplication of the expected value of acquiring and consuming each item when a player takes an action by the expected number of times the player will take the action based on master parameters; and (B) visualizing the balance of each item based on the result of the multiplication.

[0218] A method for evaluating an app according to a ninth embodiment of the present disclosure includes the steps of: (A) calculating the multiplication of the expected value of acquiring and consuming each item when a user performs an action and the expected number of times the user performs the action based on master parameters; and (B) visualizing the income and expenditure of each item based on the result of the multiplication.

[0219] The method according to the embodiment 2-1 of the present disclosure includes the steps of inputting a master including a play assumption; A step of calculating more detailed play assumptions by reinforcement learning based on the play assumptions so as to maximize efficiency; A step of calculating an optimal play that maximizes the average status or the average value of the total amount of acquired resources within a predetermined period based on the more detailed play assumptions; How to run it on your computer.

[0220] The method according to Example 2-2 of the present disclosure uses the ε-greedy method, as described in Example 2-1.

[0221] The method according to Example 2-3 of the present disclosure is the method according to Example 2-2, in which the ε-greedy method calculates rewards based on play assumptions or random selection.

[0222] A method according to an embodiment 2-4 of the present disclosure is the method according to any one of the embodiments 2-1 to 2-3 of the present disclosure, in which the Q value is updated by a Monte Carlo method in the reinforcement learning.

[0223] The method according to Examples 2-5 of the present disclosure is a method executed by a computer, comprising the steps of inputting a master including play assumptions, and calculating more detailed play assumptions using reinforcement learning based on the play assumptions so as to maximize efficiency.

[0224] The method according to Examples 2-6 of the present disclosure is a method executed by a computer, which includes the steps of inputting a master including play assumptions and the number of simulations, calculating an optimal play or a total strength 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 according to the embodiment 2-7 of the present disclosure is a program including instructions for causing a processor to execute the methods described in the embodiments 2-1 to 2-6.

[0226] The apparatus according to Example 2-8 of the present disclosure includes a processor and a memory, and is for executing the methods according to Examples 2-1 to 2-6.

[0227] A method according to Example 3-1 of the present disclosure is a method performed by a computer, which includes the steps of: calculating an optimal play based on predetermined parameter setting values; comparing the amount of acquired resources, the amount of expanded status, or the amount of acquired content 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 setting values ​​to learn so as to reduce the difference between the amount of acquired resources, the amount of expanded status, or the amount of acquired content and the predetermined values; and, when the difference becomes equal to or less than the predetermined value, outputting the parameter setting values ​​at that time.

[0228] A method according to Example 3-2 of the present disclosure is a method executed by a computer, which includes the steps of (A) inputting a master including an optimal play and an expected strength value, (B) calculating a total strength value based on the optimal play, and (C) adjusting the value of the master based on the total strength value.

[0229] A method according to Example 3-3 of the present disclosure is the method described in Example 3-2, in which the steps (B) and (C) are repeated until the total combat power value is equal to or less than a predetermined value.

[0230] A program according to an embodiment 3-4 of the present disclosure includes instructions for causing a processor to execute the methods described in the embodiments 3-1 to 3-3.

[0231] An apparatus according to an embodiment 3-5 of the present disclosure includes one or more processors and a memory, and is for executing the methods according to the embodiments 3-1 to 3-3. [Industrial Applicability]

[0232] The present disclosure is applicable, for example, to a method, device, or program for evaluating a game. [Explanation of symbols]

[0233] 101 UX Policy Decision 102 Game logic design 103 Parameter Settings 104 UX Visualization 105 KPI design 106 Checking UX 201 Expansion Period 202 Rapid decline 203 Decreasing Period 204 Core Fun 205 Realization of growth 206 Heroism 210 Maximizing Sales with Rebedeza 211 Rebedeza maintains sales 2200 Computer 2210 Processor 2220 Graphics 2230 chipset 2240 Memory 2250 Network Control 2260 Keyboard / Mouse 2270 Storage 3210 Master before adjustment 3220 Adjusted Master

Claims

1. A step of inputting a master including a play expectation of how a player will play gamification consisting of a plurality of contents; calculating more detailed play assumptions for each content by reinforcement learning based on the play assumptions so that status growth and resource gathering efficiency are maximized; A step of calculating an optimal play that maximizes the average status or the average value of the total amount of acquired resources within a predetermined period based on the more detailed play assumptions; How to run it on your computer.

2. The method described in claim 1, wherein the reinforcement learning uses an epsilon-greedy method.

3. The method described in claim 2, wherein the ε-greedy method calculates rewards based on play assumptions or random selection.

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

5. A step of inputting a master including a play expectation of how a player will play a gamification consisting of a plurality of contents; calculating more detailed play assumptions for each content by reinforcement learning based on the play assumptions so that status growth and resource gathering efficiency are maximized; How to run it on your 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 a memory for carrying out a method according to any one of claims 1 to 5.

Images