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: calculating an optimal play on the basis of a predetermined parameter setting value; comparing an acquired resource amount, an extension status amount, or an acquisition amount of each content obtained as a result of the calculation of the optimal play, with respective predetermined values, changing the predetermined parameter setting value on the basis of the comparison result, and learning so as to make a difference between the acquired resource amount, the extension status amount, or the acquisition amount of each content and the predetermined values small; and, when the difference is equal to or less than a predetermined value, outputting a parameter setting value at that time.SELECTED DRAWING: Figure 29

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), it has been common to evaluate sales information such as the game's sales or actual player play, and then change the parameters necessary for the game's operation. However, it has not been common to evaluate a game from a player's perspective before the game is released (launched), visualize each parameter of the game based on that evaluation, and then change or adjust the parameters of the game accordingly.

[0003] In the game industry, during the development stage of a new game, it is common to create a gameplay scenario that describes how a player will play the game. Based on the master parameter settings for the created gameplay scenario, simulations are partially performed to determine how many items a player will acquire and consume over time, or how much a player's status will grow.

[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 five 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 simulations are cumbersome and time-consuming when there are a large number of quests and items, and so have not been carried out in practice.

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

[0006] [Patent Document 1] Japanese Patent Application Publication No. 2019-457 Summary of the Invention

[0007] As mentioned above, it is possible to create gameplay scenarios and calculate the amount of items and other items acquired in each content based on those scenarios. However, for example, if a chapter contains 10 quests and there are 10 chapters, then 10 quests x 10 chapters = a total of 100 pieces of content. In such a case, creating gameplay scenarios would require creating 100 detailed gameplay scenarios for each of the 100 pieces of content. Furthermore, typical games contain a variety of content other than quests, and creating gameplay scenarios for each of these pieces of content, by detailed classification such as difficulty level and stage, would be too time-consuming and unrealistic. Therefore, such simulations have often not been conducted before a game is released, or even if they have been conducted, they have been partial and limited.

[0008] On the other hand, the previous work mentioned above only allowed visualization of the amount of items acquired. The amount of items consumed also changes depending on the character's strengthening status, so the amount of items consumed is also influenced by circumstances such as how the character is developed. What is important for game balance is the balance between the amount of items acquired and consumed, rather than the amount of items acquired alone. Calculating the balance of such items required separate calculations of the amount of items acquired and consumed, and then comparing these to determine whether the balance was appropriate, which was even more time-consuming.

[0009] Furthermore, each parameter in a master file, which contains parameter settings, may have complex relationships with other parameters, and may even have nested structures within multiple masters. For example, when calculating the items obtainable in Quest Chapter 1, Part 1, Quest Chapter 1 is further divided into three stages, each of which contains enemy monsters. Defeating these monsters results in the appearance of three treasure chests (gold, silver, and bronze) with a certain probability. Opening each treasure chest yields a corresponding set of items. Because these sets typically contain multiple items (e.g., Item A, B, C, etc.), simply calculating how much of each item will be obtained by completing a quest becomes complex. Furthermore, the structure of treasure chests varies considerably depending on the content and game. Therefore, different simulation logic must be used for different games, and even for different content within the same game, resulting in complex simulations that require time and effort.

[0010] For these reasons, trying to see the overall balance of a game, including item income and expenditure, requires a huge amount of work and time. Furthermore, when looking at the amount of Item A obtained, for example, in most cases the same Item A can be obtained from multiple different pieces of content. As mentioned above, the master file structure differs for different pieces of content, making it impossible to simulate them simultaneously. Therefore, the simulation results for each piece of content had to be calculated separately, and it was extremely time-consuming to plot a single graph showing how much of a certain item could be obtained from which piece of content.

[0011] When attempting to simulate game balance, it takes a huge amount of time to create detailed gameplay scenarios, and when the game, content, or functions differ, it is necessary to create different simulation logic each time. As a result, it has traditionally been virtually impossible to comprehensively and precisely simulate the balance of an entire game.

[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 likely result in a slump in 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 visualizing the balance of items before the game is released, thereby adjusting game parameters in advance and further optimizing the parameters.

[0014] In conventional methods, simulations are performed using structured masters and gameplay assumptions. In these methods, developers must carefully consider and configure the expected gameplay patterns of users. For example, if there are 50 quests, numbered from 1-1 to 1-10, across five chapters, the developer must specify how many times each quest will be played on which day. However, since it is difficult to achieve such detailed configurations in practice, this invention automatically creates these settings (expected gameplay patterns).

[0015] Furthermore, we have invented a method for automatically tuning 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 this invention can automatically create parameter settings that will achieve the game difficulty desired by the designer.

[0016] According to another aspect of the present invention, it is 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 (A) calculates 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 based on the master parameters, and (B) visualizes 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 using 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, all of which are carried out by a computer.

[0020] Another method according to the present disclosure 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 each predetermined value; and, based on the result, 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 value; and, when the difference becomes equal to or less than the predetermined value, outputting the parameter setting values ​​at that time.

[0021] These comprehensive or specific aspects may be realized as a system, an apparatus, a method, an integrated circuit, a computer program, or a recording medium, or may be realized as any combination of a system, an apparatus, a method, an integrated circuit, a computer program, and a recording medium. [Effects of the Invention]

[0022] According to the present disclosure, by simulating the game balance before the game's release, it is possible to easily evaluate the game's income and expenditure balance and make necessary adjustments to each parameter. As a result of adjusting the parameters before the game's release, the game can generate stable sales every month, which in turn makes it possible to increase the total sales from the game. [Brief explanation of the drawings]

[0023] [Figure 1] A diagram showing the steps in game level design [Figure 2] A diagram showing the basic pattern of social game sales trends [Figure 3] A diagram showing the amount of damage a player takes at each level when clearing a dungeon in a certain game. [Figure 4] An example of visualizing parameters by organizing masters. [Figure 5] FIG. 1 shows an example of improving game operations 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 traditional, non-standard nested masters [Figure 9] Diagram showing traditional, 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, its quantity and weight in accordance with FIG. 10, which shows 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 to which the present disclosure is applied. [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 graph 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] 1 is a block diagram of a computer executing a program that performs operations according to the present disclosure. [Figure 23] A flowchart outlining how optimal plays are calculated [Figure 24] A diagram showing the relationship between quest classification and play order [Figure 25] Diagram showing reinforcement learning [Figure 26] Flowchart showing the procedure when using the Monte Carlo method [Figure 27] Graph showing the relationship between total value and the date of first acquisition of a rarity 5 card [Figure 28] Graph showing the average value for each date in Figure 27 [Figure 29] Flowchart showing an outline of Example 3 [Figure 30] 1 is a flowchart illustrating a method for automatically adjusting a master according to the present invention. [Figure 31] A graph showing the change in combat power value depending on the number of times [Figure 32] 1 is a diagram showing a master before and after adjustment by the automatic adjustment method of the present invention; DETAILED DESCRIPTION OF THE INVENTION

[0024] As used herein, "games" refers to any type of computer game, including, without limitation, arcade games, consumer games, video games, handheld games, PC games, mobile phone games, smartphone games, social games, browser games, NFT games, blockchain games, and crypto games. Furthermore, in DeFi (Decentralized Finance) using NFT and blockchain technology, transactions are conducted between users without an intermediary, unlike centralized systems. However, unlike centralized systems, there is no mechanism for a specific person to bear the various costs of intermediating the transaction in exchange for receiving rewards, making it difficult for transactions to be completed as is. Therefore, in the DeFi field, a design is required that allows transactions to be conducted smoothly between an unspecified number of users, allowing them to earn some kind of reward in exchange for paying transaction costs. The reward balance defined in the smart contract must be optimized, and the technology of the present application can be applied to such fields as well.

[0025] For the sake of convenience, this specification will mainly use social games as an example of games, but the application of the present disclosure is not limited to social games and can be applied to any type of game.

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

[0027] Since basic terms in the social game 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 creature that appears in a game, and is a character involved in the game's story that is controlled 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 originally called "gacha gacha" or "gachapon," and in games it is a system for randomly drawing items to obtain them. "Gacha" is usually partly free and partly paid.

[0030] A "card" is like a player's avatar used in the game. Multiple cards are collected to create a deck (or team), which is then 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 placed in a deck. "Parameters" are values ​​that represent the strength associated with the card. Generally, other parameters are set, such as "attack power" or "defense power." The higher the "attack power," the more damage the opponent will inflict by attack, and the higher the "defense power," the less damage the opponent will receive from an opponent with the same attack power. "Skills" are unique abilities that the card can use. For example, they can increase your own attack power or allow you to attack first.

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

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

[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] "Items" refer to any equipment that a character can possess in the game.

[0037] "Magic Stones" are an item that acts as a 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 this boss you can proceed to the next stage. [Example]

[0039] Figure 1 shows the steps in game level design. In game development, "level design" generally refers to the process of adjusting the difficulty (i.e., numerical values) of various parameters used in the game. In apps such as social games, level design is often thought of as simply parameter setting. However, in this specification, level design is defined as the entire process, starting from the upstream UX (User eXperience) policy, i.e., the definition of what kind of experience should be delivered to the user, and including subsequent data analysis.

[0040] If there are problems 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 confirm whether the parameter settings 103 satisfy the UX (user experience), it may not be possible to adjust the parameters appropriately.

[0041] In this specification, level design includes steps such as UX (user experience) policy determination 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. For convenience of explanation, Fig. 1 shows six steps, but 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., defining what kind of experience should be delivered to the user, to subsequent data analysis.

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

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

[0045] In game logic design 102, the formula for expressing difficulty is considered based on mathematical formulas and other factors to determine UX (user experience), such as whether the difficulty should increase monotonically over time, whether the difficulty should increase at an accelerated pace in the latter half of the game, or whether the difficulty should ultimately converge to a certain value. If the game logic is flawed or the formula for expressing difficulty 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 in the upstream level design stage is.

[0046] In the next step, parameter setting 103, numerical values ​​are assigned to each parameter in accordance with the UX policy decided upon and the game logic designed up to that point. In parameter setting 103, it is necessary to quantitatively convert the general framework of the UX policy into parameters.

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

[0048] By determining the UX policy in this way, players of this game can have a "thrilling experience" that is the result of the determined UX policy. Furthermore, by repeating the process of quantifying the UX policy into parameters in this way, parameter setting 103 that is less likely to result in errors can be achieved.

[0049] The next step is UX visualization 104, where the parameter settings are visualized to confirm whether they are in line with the determined UX policy. In this case, test play of the game by players is required, but as a preliminary step, visualizing UX at a numerical level and being able to check parameters can significantly reduce accidents caused by parameter setting errors. For example, UX can be roughly expressed numerically, such as "how many days it takes to develop a certain character." In contrast, UX can be visualized by, for example, running a simulation and organizing the master that describes each parameter.

[0050] By using a simulator to visualize UX, it is possible to provide a system that prevents sales declines 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 there and how many items is an important part of the UX (user experience). This can be visualized by organizing the master, which can help prevent accidents caused by incorrect parameter settings.

[0052] Next, in KPI Design 105, you need to design KPIs (Key Performance Indicators) and 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 an image such as "a heavy user plays a certain number of times per day and completes a certain number of quests in a certain number of days," then the number of plays and quest completion status of that player group will become 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 of 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 social game sales trends. In Figure 2, the horizontal axis represents time, and the vertical axis represents the sales of the social game.

[0055] Referring to Figure 2, we can see that game sales go through three phases after the game goes on sale: "Expansion Phase 201," "Sudden Decline Phase 202," and "Gradual Decline Phase 203." The first stage after the game's release is "Expansion Phase 201," in which the number of users and average customer spending steadily increase, resulting in steadily increasing sales from the game. Next is "Sudden Decline Phase 202," in which the number of users drops sharply and sales drop sharply. The final stage is "Gradual Decline Phase 203," in which 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 will have a gradual decline in sales even after peaking (i.e., there is no sudden drop in the sharp decline period 202). On the other hand, a poorly selling game will gradually increase the number of users and sales after release, and will not have a high peak in sales, after which the number of users and sales will often decline rapidly.

[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 carrying out proper level design (also called level design), it is possible to help maximize sales during the expansion period 201 and to some extent prevent users from dropping off or sales from declining during the sudden 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 game 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 successful level design during the expansion period 201, and sales do not drop 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 example of a successful Lebedeza (solid line) mentioned above, in the example of a failed Lebedeza (dashed line), the maximum sales did not increase significantly during the expansion period 201, and the peak sales value was low (symbol 220). Then, sales dropped sharply in the subsequent rapid decline period 202 and gradual decline period 203 (symbol 221). As a result, in the example of a failed Lebedeza (dashed line), the total sales from the start of sales to the final end of sales was smaller than in the example of a successful Lebedeza (solid line).

[0060] Before a game is released, it is often thought that the most important thing is whether it will sell, that is, 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.

[0061] There are several important elements associated with each of the three phases shown in Figure 2: Expansion 201, Rapid Decline 202, and Gradual Decline 203. First, what contributes greatly to the first Expansion 201 is "Core Fun (204)." This Core Fun (204) refers to the fun of the app's in-game content itself, as well as the appeal of its IP, characters, and worldview. Even within the in-game environment, it is possible to increase the fun factor through game logic and parameter settings, but there may be some aspects of Core Fun (204) that simply cannot be achieved through level design alone.

[0062] Referring to the table at the bottom of Figure 2, the importance of the core enjoyment of the game (204) through in-game and IP is high (◎) during the expansion period 201, and decreases (△) 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, etc. is high (◎) in the rapid decrease period 202, and 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 self-exhibitionism tends to gradually increase over time, from the expansion period (△), to the rapid decline period (○), to the gradual decline period (◎).

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

[0066] The key element in the rapid decline period 202 is the "sense of growth (205)." In other words, it is important for players to constantly 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 stats (in other words, the phenomenon in which stats, firepower, etc. continue to increase over time). However, rather than simply inflating the stats, it is also important to create a system that provides feedback to players on the actual feeling of that strength.

[0067] The important factor in the final tapering period (203) is the "sense of heroism" (206). This sense of heroism (206) is whether the player feels that they are doing something great. For example, a player may achieve high rankings in the game, or other players may think that the player is amazing because they have good cards or characters.

[0068] Especially in games that maintain high sales for a long time, designing this sense of heroism (206) is extremely important in the long run. If players themselves feel a sense of heroism (206), they will be more likely to play the game for a long time and make in-game purchases, which can lead to increased sales and prevent sales declines.

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

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

[0071] For example, in an RPG (role-playing game) in which multiple areas are explored, the amount of damage (i.e., the amount of damage taken) taken by each player or party at each level until each area is cleared is simulated. In Figure 3, the boundary between winning and losing is set to 100% damage, and it is assumed 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. In this simulation, for example, a beginner player will not be able to clear Area 5 (110% damage taken, i.e., a close loss), but will barely clear Area 4, which is one level below Area 5 (90% damage taken, i.e., a close win).

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

[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 settings can be significantly reduced.

[0074] In many cases, a significant drop in sales during actual game operation is due to improper parameter settings. For example, distributing too many important items can disrupt the balance of the sense of growth, or a specific character can become unbalanced and lose their sense of heroism. These parameter setting errors can actually result in sales not increasing as expected in the long term.

[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] Figure 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 Figure 4, the quest ID, item ID, and quantity 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, the ID, item name, and quest name are listed from the left column, and within the larger grouping of quest names, the specific names of the more detailed quests are listed, such as grassland, cave, and mine.

[0077] For example, in the table (420) on the right of Figure 4, the row with ID=1 has the item name "Herbal Herb," ​​and it can be seen that there is one of this herb in the grassland, two in the cave, and three in the mine. Similarly, the row with ID=2 has the item name "Small Healing Potion," and it can be seen that there are two of this small healing potion in the cave, but none in the grassland or the mine. The row with ID=3 has the item name "Shard," and it can be seen that there is one of this hard piece in the grassland, but none in the cave or the mine. For IDs 4 to 6, the table (420) on the right lists the number of iron ore, gems, and cards 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 which quest.

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

[0080] For example, when evaluating the difficulty of a game for each user demographic in the early stages of game design before release, a situation may arise in which many players can clear the beginner content but few can clear the intermediate content, as shown in the left diagram (510) of Figure 5. In such a case, players may get stuck in the intermediate tier midway through the game's overall progression. In this situation, intermediate players in particular will find it difficult to progress to the higher core tier, which will reduce their motivation to continue playing the game. This will result in a decrease in sales from the large number of intermediate players and a decrease in overall sales for the game.

[0081] 5 (left diagram 510), the balance of the levels of completion for each level of player is poor. By applying the parameter evaluation of the present disclosure to this game before the game is released, it is possible to balance the number of players who can complete content for each level of beginner, intermediate, and core players by making the content for the intermediate level easier than in the left diagram 510. In the right diagram 520, as a result of making the content for the intermediate level easier than in the left diagram 510, more players can complete the content for the intermediate level (i.e., more players can challenge the content for the core level), and intermediate players will continue to play more, which makes it possible to further maximize the revenue obtained from the game overall.

[0082] FIG. 6 shows the balance of magic stones in a game before and after the application of the present disclosure. As mentioned above, magic stones are a type of item and function similarly to currency in the game. The horizontal axis of the graph (600) before parameter adjustment before the application of the present disclosure and the graph (650) after parameter adjustment after the application of the present disclosure both represent the number of days of play, from the first day of play on the left to the 60th day of play on the right. The vertical axis of the graph (600) before the application of the present disclosure and the graph (650) after the application of the present disclosure both represent the balance of magic stones (number). Of the three bar graphs for each number of days of play in each graph, the leftmost bar represents the amount of magic stones acquired, the middle bar represents the amount of magic stones consumed, and the rightmost bar represents the difference (balance) between the amount of magic stones acquired and the amount consumed. From the left diagram (600) and the right diagram (650) of FIG. 6, it can be seen that in both cases, the amount of magic stones acquired and consumed increases according to the number of days the player plays the game.

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

[0084] In contrast, referring to Figure 650 after applying the present disclosure, as the number of play days elapses (1, 3, 5, 7, 14, 30, and 60 days), the balance initially increases on the third day, but then fluctuates slightly thereafter, eventually decreasing. Furthermore, at 60 days of play, the amount earned is 8,350, which is the sum of 4,500 paid stones purchased, 2,500 from events, 1,050 from regular quests, and 300 from the login bonus. Referring to Figure 650 after applying the present disclosure, at 60 days of play, the amount consumed is 8,400, which is the sum of 6,000 from the event gacha (event gacha) and 2,400 from the regular gacha. Therefore, the balance (amount earned minus amount consumed) after applying the present disclosure is -50.

[0085] As described above, the balance after 60 days of play before applying the present disclosure was 4700, which means that the balance between the amount of magic stones acquired and the amount of magic stones consumed was poor (i.e., the amount consumed was too small compared to the amount acquired). In contrast, after applying the present disclosure, the balance after 60 days of play was -50, which means that the difference between the amount of magic stones acquired and the amount consumed was small (i.e., the balance between the amount consumed and the amount acquired was good), and the amount of magic stones consumed was also large, which encouraged in-game purchases, making it possible to further maximize income from the game.

[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 for 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 the parent master are further described in stages using 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 the parent master is further specified in more detail in the child master, and in such cases, the details of that item cannot be known by looking at the parent master alone.

[0088] First, when a 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 using a computer or manually. Typically, a game developer provides all masters used in the game in a non-standard master format. Even for games developed by the same game developer, different games or different versions of the same game often have different master formats, with no standard master format being used. The same standard master format is used regardless of the game development 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 visualizing 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 balance of the items acquired and consumed for each day elapsed since the start of the game is balanced as shown in diagram (600) in Figure 6. Looking at 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 balance of +4700.

[0092] By applying the present disclosure, game developers can improve the balance of item income and expenditure by looking at the imbalance in the diagram (600) in the upper left of Figure 6 and appropriately adjusting each parameter in the master. The results of improving income and expenditure through parameter adjustment in this way are shown in the diagram (650) in the lower right of Figure 6. Looking at the diagram (650) in the lower right of Figure 6, it can be seen that the balance of income and expenditure is good 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 amount acquired and amount consumed), and that the adjusted parameters are more appropriate for maximizing sales.

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

[0094] As a result of further parameter adjustment, steps S702 to S704 may be repeated if necessary.

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

[0096] Figure 8 shows a conventional, non-standard nested master structure. Figure 8 shows four masters, the relationships between which 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 this is a non-standard (i.e., non-standard) master structure, when you draw a quest or gacha, if you take that action, what you can get, with what probability, etc. 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. Then, when you refer to another master that contains details of the target ID listed in the master, there may be a nested structure 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 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 the item that can only be obtained the first time (first time), and a random_reward_group_id, which is the ID of the item that can be obtained every time. Each of these is written in order in the column 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 states that the group with group ID "1001" can obtain "10" items (amount) with item_id "11" (flow 810). In this way, unless you go through two or more masters (in this case, two masters, a parent and a child), it may not be possible to know specifically how many items you can obtain in the final target quest. For example, you can find out how much item 11 you can obtain 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." For this item with ID "201," referencing yet another master (child master) random_reward_group_master (803) reveals that the random_reward_id is "2001" (flow 820). Next, referencing another master (grandchild master) random_reward_master (804) reveals that the item ID (item_id) for random_reward_id "2001" is "21," the weight is 10000, and the quantity is "5" (flow 825). For random_reward_group_id, it is not possible to know the probability of obtaining an item unless it passes through two separate masters (child master and grandchild master), 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] Figure 9 is a diagram showing an example of the master structure of a gacha. While Figure 8 showed the master structure of a quest, Figure 9 shows the master structure of a gacha. Even for things like gacha, where the prize is unknown and subject to a certain probability, masters usually have a nested structure with several levels, as in Figure 8. Referring to Figure 9, first, the gacha IDs "50001" and "50002" are entered in the master called gacha_master (901). For the items that can be obtained for each gacha ID, the group to be referenced is specified in the lot_table_id column, such as "501" and "502". In other words, even if you only refer to the parent master, gacha_master (901), you cannot know what you will receive and with what probability (in other words, the parent master, gacha_master (901), does not have a column indicating weight).

[0105] Next, by looking at the master called 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 80, 15, and 5, respectively, as listed in gacha_lot_table_master (902).

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

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

[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 where 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 which items will appear and in what proportion.In addition, instead of individual item names, group names such as SR, SSR, UR, etc. are specified, and then further detailed specifications are made within these group names, creating a multi-layered nested structure.

[0109] As such, each master for each game usually has a nested structure of one or more levels, but the inventor thought that it would be possible to convert them into a unified standard master by specifying which are intermediate groupings and which are final disassembled groups.

[0110] FIG. 10 is a diagram showing a standard master 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 defined 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, in group_trans_1_conf (1010), the four input masters are, from top to bottom, story_quest_master, story_quest_master, gacha_master, and gacha_master. Here, story_quest_master and gacha_master appear twice, but the child masters referenced in each row are different.

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

[0112] In the method disclosed herein, the group_id_column in the three input masters in Figure 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 defined as group_trans_1_conf (1010). group_trans_1_conf (1010) specifies which columns are large and small groups. Furthermore, select_type_column therein specifies "first" if a reward can be obtained only the first time, and "loop" if a reward can be obtained every time. In this example, select_type_column specifies two types, "first (only the first time)" and "loop (every time)", but there may be three or more types.

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

[0115] Next, 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) becomes the final value for separation (reference), and the amount_column specifies the number of items acquired. For example, if the amount_column is blank, the quantity can be set to "1".

[0116] Next, it references 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 listed 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 those groups further is group_trans_2_conf (1020), which breaks down those even further is group_trans_3_conf (1030), and so on, creating a structure in which masters with the same structure can be linked together 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 the first reward or a reward that is given each time.

[0118] Fig. 11 is a table that lists each item and its quantity and weight, based on Fig. 10, which shows the standard master of this disclosure. In each table shown 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 shown in Figure 11, group_trans_1 (1110), group_trans_2 (1120), and group_trans_3 (1130), are formatted so that when you perform the action indicated in the group_id column, you receive the amount indicated in the separation_id column for the amount. Next, the separation_id becomes the group_id of the next group_trans_x (where x is an integer greater than or equal to 1). For example, if 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 1111 flow), and it will be further decomposed into the item ID (separation_id) of "11." In this way, the relationships between group and decomposed items are gradually established. In this way, all masters are standardized and can be migrated to the standard master of a template to which the present disclosure is applied.

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

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

[0122] Here, when group_id(x) is obtained in group_trans_x, it is possible to obtain multiple separation_id(x,m(1)), separation_id(x,m(2)), ... separation_id(x,m(n)) 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, W(separation_id(x,m(k))) is the weight of separation_id(x,m(k)).

[0124] In this case, Equation 1 becomes:

number

[0125] Next, assume the following: A: Action I:Item Depth(A,I): Variable x (in the diagram below, x = 3) such that separation_id(x,m(k)) = item I in formula 1 when action A is performed. 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 taking action A

number

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

[0127] <Quest reward> If 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 get (select_type is first) is Item group 1001 = 11 items x 10 (see row 1 of group_trans_2) As an item that can be taken each time (select_type is loop), 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 both together, Quest 10001 = Item 11 x 10 + Item 21 x 5 + Item 22 x 5 This becomes:

[0128] <In the case of gacha> In quest 10001, the expected value of UR_A when drawing gacha 501 once 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 there are UR_A and UR_B among the UR (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] Figure 12 is a diagram showing the expected value of each item calculated from Figure 11, which shows the output to which the present disclosure is applied. The flag in the rightmost column "First Time" in Figure 12 is "TRUE" if that action is the first time, and is "FALSE" from the second time onwards. In other words, a row where the "First Time" column is TRUE indicates an item to which that action is given only the first time, and a row where the "First Time" column is FALSE indicates an item to which that action is given from the second time onwards.

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

[0131] For example, looking at row 1 in Figure 12, if you perform 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 perform the same action 10001 as in row 1, you will receive a quantity of 5.0 for item 21 if you perform that action the second time onwards (i.e., the first time column is FALSE).

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

[0133] 8 to 12 have explained examples in which the masters of the original FIGS. 8 and 9 have a nested structure, but FIGS. 13 to 16 show examples in which the master of the original 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), a master related to battle, and event_gacha_master (1320), a master related to gacha. Each master has only one master, does not refer to a child master, and does not have a nested structure (i.e., a hierarchical structure).

[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 listed 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, if you look at the battle_master (1310) for battles, the IDs of the items you receive the first time are listed in the first_tresure_id column as 111, 111, 111, 111, 111, in order from top to bottom, and the quantities you can receive for each ID are listed in the example of first_tresure_amount as 5, 10, 15, 20, 25, in order from top to bottom. On the other hand, the IDs of the items you receive each time are listed in the random_tresure_id column as 222, 222, 222, 222, 222, in order from top to bottom, and the quantities you can receive for each ID are listed in the example of random_tresure_amount as 50, 100, 150, 200, 250, in order from top to bottom.

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

[0138] Additionally, in the other master in Figure 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] Figure 14 is a diagram showing the non-standard masters of Figure 13 converted into standard masters to which the present disclosure is applied. The masters battle_master (1310) and event_gacha_master (1320) of Figure 13 contain the final information about the quantity or weighting of each item, and have a simple, non-hierarchical structure. Therefore, even if the masters battle_master (1310) and event_gacha_master (1320) of Figure 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, similar to 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 gachas. 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 set 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 received the first time (first), and it is also possible that the setting value is such that one item is received each time (loop) as a loop reward, even if it is not the first time.

[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 of FIG. 16, it can be seen that when the action name is 3001, an item with an item name 111 will be obtained in quantity 5.0 (TRUE) only the first time. Also, referring to row 11, it can be seen that when the action name is 100001, an item with an item name UR_AA will be obtained with an expected value of 0.01.

[0145] FIG. 17 is a diagram showing expected play. In this table, the expected number of actions per day (i.e., expected play) is created for each action. Specifically, two expected play tables are shown: a story_quest_master (1710) table for quests and a gacha_master (1720) table for gacha. The ID column of story_quest_master (1710) at the top of FIG. 17 lists the quest IDs, 10001, 10002, and 10003, from top to bottom. The three columns to the right of the ID column list the number of times the player will perform each quest on each day (day 1 (first day), day 2 (second day), and day 3 (third day)). For example, assume that the player performs the quest with quest ID 10001 five times on day 1, three times on day 2, and zero times on day 3. In this case, the blank action_num (number of actions) column represents zero.

[0146] Additionally, the ID column of gacha_master (1720) at the bottom of Figure 17 lists the gacha IDs, 50001, 50002 from top to bottom. The three columns to the right of the gacha ID list the number of times the player will perform each gacha on each day (day 1 (first day), day 2 (second day), day 3 (third day)). For example, assume that the player performs the gacha with gacha ID 50001 twice on day 1, three times on day 2, and zero times on day 3. In this case, a blank space in action_num (number of actions) indicates 0 times.

[0147] Figure 18 shows the number of items acquired per day for each action. The expected value shown in Figure 12 is multiplied by the number of actions performed per day in the assumed play scenario shown in Figure 17 to calculate how many items can be acquired per 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." Referring to FIG. 17 above, the number of actions was 5 on day 1 (the first day), 3 on day 2 (the second day), and 0 on day 3 (the third day). Therefore, 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 x 5 = 50, the number of items acquired on day 2 is 10 x 3 = 30, and the number of items acquired on day 3 is 10 x 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 day 1 (day 1), 3 on day 2 (day 2), and 0 on day 3 (day 3), so multiplying the amount in the corresponding row in Figure 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 day 1 is 0.266 x 2 = 0.532, the number acquired on day 2 is 0.266 x 3 = 0.798, and the number acquired on day 3 is 0.266 x 0 = 0.

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

[0152] Figure 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 acquired by each action, it is possible to predict the number of items acquired when playing over multiple days. The examples for day 1 (first day), day 2 (second day), and day 3 (third day) in Figure 19 are the numbers calculated by summing up the results of the calculation for each day of the aforementioned expected number of plays x expected value, organized by 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, if you have an item named 11, you can obtain a total of 10 items on day 1 (the first day), 20 items on day 2 (the second day), and 130 items on day 3 (the third day), so if you play this game over these three days, you can obtain a total of 160 items 11.

[0154] For example, if you play the game over these three days, you can obtain a total of 1.862 of the item SR_A, which means that you can obtain a total of 0.532 of the item on day 1 (the first day), 0.798 on day 2 (the second day), and 0.532 on day 3 (the third day).

[0155] In Figure 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] Figure 20 is a table explaining the amount of items consumed. Figure 19 explained the amount of each item acquired, but Figure 20 explains the amount of each item consumed. Item consumption is similar to item acquisition; in the expected value list in Figure 12, negative values ​​in the quantity column indicate the number of items consumed, so by multiplying the number of items consumed by the number of plays, you can determine the type and amount of items consumed. In Figure 12, which shows expected values, the two items with negative amounts are item 11 in row 18 and item 21 in row 27. Conversely, in the example in Figure 12, no items other than item 11 and item 21 are consumed.

[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 units.

[0158] For example, in the example shown in Figure 20, it can be seen that 100 and 40 items 11 and 21 will be consumed in total 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 of 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 each item acquired and the number 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 using the method described with reference to Figures 14 to 20. Using this method, the amount acquired and consumed for each item in quests and gacha is calculated, and the balance is calculated by subtracting the amount consumed from the amount acquired, thereby calculating the balance for 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 allow you to earn more.

[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, memory 2240, network control 2250, keyboard / mouse 2260, and 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 or optical disk, and is controlled by the processor 2210 via the chipset 2230 to store data and / or instructions.

[0167] For example, a program 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 convenience of explanation, the present disclosure has been described assuming a game, but the present disclosure is not limited to games and can be applied to general simulations such as web services. For example, in a service that allows users to write articles, the articles written by the user are used as login bonuses in games. Similarly, in a manga app that allows users to 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 fields of such services, apps, and games, players are also called users. [Example]

[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 mentioned above, it is generally not easy to find the optimal solution for a game or to set the optimal master. Therefore, the Auto Params feature of the present invention is a method for finding the optimal play for a general game and then automatically adjusting the master based on the results, thereby adjusting the player's level of growth. In particular, there are two patterns for finding the optimal play: (1) a method that takes into account cases where the results change due to randomness even when the user's behavior is the same, and (2) a method that calculates the user's behavior by representing it with an expected value to reduce the computational load from a practical perspective. AI reinforcement learning, etc., may be used in the search for each optimal play.

[0172] Fig. 23 is a flowchart showing an outline of a method for calculating an optimal play. In 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 efficiency under the assumed play conditions are calculated using a reinforcement learning epsilon-greedy method or the like (step 2302). Here, efficiency refers to, for example, the highest total value of the increase in 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, for a certain amount of play time and charge. Note that, while the increase in status parameters is generally given more importance, the degree of emphasis may vary from game to game.

[0174] At the end of Figure 23, the optimal play for each content is calculated based on detailed play assumptions, i.e., what type of play will maximize average status and resource acquisition amounts over the same period (step 2303). Each step is explained in detail below. Note that even if the user's behavior is the same, the results are usually influenced by probability, such as with gacha or quest drop reward probability. Therefore, there are two methods: one that takes into account the influence of the distribution of results, and one that does not take this into account and calculates based on expected value. However, since most aspects are the same, any differences will be described as necessary.

[0175] In other words, there are two ways to create optimal play assumptions: (1) a computationally intensive but accurate method, and (2) a less computationally intensive method with slightly lower accuracy. When calculating (1) in detail, it is desirable to use a method that analyzes the efficiency of play when multiple plays are performed using the Monte Carlo method, taking into account the uncertainties in each content, such as hits and misses due to the randomness of gacha draws and the occasional rewards received when defeating enemies, and defines the efficiency of the play as the index that maximizes efficiency, the average efficiency, the median efficiency, or a combination of these with the standard deviation of the distribution, and then uses the results to find the optimal play by combining methods such as reinforcement learning epsilon-greedy methods. This computationally intensive but accurate method (1) imposes a heavy computational load on the above approach, and in many cases, less accuracy is sufficient in practice. Therefore, a method that uses a reinforcement learning epsilon-greedy method or similar to find the play scenario that maximizes the efficiency of play based on the expected value of the resources that can be consumed and acquired when playing each piece of content, and calculates the efficiency of play based on that expected value, is a slightly less computationally intensive but more accurate method (2).

[0176] <Program Structure> The Auto Pramas program may include one or more of the following components: General game model Optimal gameplay search (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 it 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 run various test functions as follows: python tests / test_*py

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

[0179] <General game model> This method is implemented assuming a general-purpose game in which a player completes a quest 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 simply referred to as player) plays the game according to its selection. The game function mainly enables the following actions, for example: Play quests Pull gacha

[0180] The various setting values ​​may be read, for example, from the standard master of the applicant, Precious Analytics Inc. (hereinafter also referred to as Pre-Ana). In addition, all items consumed or acquired in the game and characters that make up 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 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 unlocked (i.e., becomes playable for the player) only after the quest assigned to 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 subsequent plays, and the player may be able to play the quest by consuming the required stamina value and receive a play reward as a result.

[0182] For example, in the upper half of Figure 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., it is in an uncleared state). 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, they may receive a first-time reward 2404. In reality, it is not always possible to clear Chapter n 2401 of Story A on the first playthrough, but for simplicity's sake, it is assumed that the chapter can be cleared on the first playthrough.

[0183] On the other hand, if we look at the bottom half of Figure 24, we can see that Chapter n 2411 of Story A is listed as a quest category, and 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 playing, Chapter n 2412 of Story A is cleared again (cleared state), and this time the player may receive a loop reward 2413 given for clearing the story from the second time onwards, rather than a first-time reward. In this case, because Chapter n of Story A has been cleared more than once, Chapter n+1 of Story A may not be unlocked 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 as necessary. Minimum Total Power: By setting this minimum total power, if a player reaches a certain quest and their deck's total power is less than the preset value, they 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 assumed for scenario stories that can only be played once, or event quests with 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. Also, for so-called drop rewards, which are rewards for quests and the like and whose acquisition depends on probability, two types 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 based on the expected value (e.g., if you draw 10 consecutive gachas with a 5% chance of getting a rarity 5, you will statistically get 0.5 rarity 5 cards). Players keep track of the cumulative number of cards of each rarity, and when the cumulative number of cards of each rarity exceeds 1, they 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 consecutive gachas once every 10 days. 2. Repeat the following until you run out of stamina. - Choose the best quest from the available ones and play it based on your choice -Growth assessment according to the master, character strengthening

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

[0188] <How to run> For example, the following test function allows for test calculation 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 Arguments from the second line onwards are optional; as an example, all settings in this example are default values. max_level is the maximum level of characters in the deck; for example, a natural number below 70 can be specified. deck_num is the number of cards in the deck. action_type is the player's action guideline; it can be "random," which acts randomly, "greedy," which uses a greedy method, or "qlearning," which uses reinforcement learning. Greedy methods and reinforcement learning are discussed 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 character gacha type; it can be "random," which randomly dispenses one card at a time with an expected value-based "expect" probability. debug_mode is an argument provided for debugging; if set to True, the processing time of major processes can be output as a log.

[0189] <Searching for optimal gameplay> In this method, three strategies are implemented: randomly playing quests (random), greedy gameplay where the efficiency of playing each quest is known (greedy), and optimal gameplay using reinforcement learning (qlearning). Greedy: In Greedy, 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 can be used, and the Monte Carlo method can 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 the quest is not known in advance. In reinforcement learning, the important factors are generally state s, which indicates the environment and situation at that time, action a taken by the agent (in this program, the player) at that time, and the reward obtained from action a. State s can be the date and stamina, and action a can be playing a quest. Action a can consume stamina, obtain a reward, and strengthen the deck. The reward can be the increase in total value obtained by the acquired items and strengthening the deck.

[0190] FIG. 25 is a diagram illustrating 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). Training in this step 2510 is repeated in reinforcement learning. Finally, the optimal play solution is output (step 2502). Each step in FIG. 25 is explained in detail below.

[0191] <ε-greedy method> The ε-greedy (epsilon-greedy) method is a type of reinforcement learning that takes random actions with a certain unlikely probability ε 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 ε falls below a certain value, for example.

[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 you first obtain the highest rarity card (hereafter referred to as day 5 (the fifth day)) and the total value and total deck power when gacha is completely random. Normally, if many simulations are performed, the distribution of day 5 counted by date will be skewed and peak-shaped, but in order to collect data uniformly, the module has been implemented so that day 5 can be specified for a certain gameplay.

[0194] Figure 26 is a flowchart 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 The first argument must specify how many cycles of Monte Carlo simulation to perform. The rest are the same as the arguments for the game function, except that 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 in 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. An example of the generated file is shown below. [Table 1]

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

[0198] Figure 27 is a graph showing the relationship between total value and the date on which a rarity 5 card was first acquired. The vertical axis of Figure 27 represents total value (total power value), and the horizontal axis represents the date on which a rarity 5 card was first acquired. As the number of days on the horizontal axis changes from 0 to 60 from left to right, the total strategic value also changes. For example, when the number of days on the horizontal axis is 0, a total power value of 136,000 or one of the six values ​​below that is possible. However, when the number of days on the horizontal axis exceeds 10, i.e., even if a rarity 5 card is first acquired after the 10th day, 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 of total value (total power value) for each day, and the horizontal axis shows the date on which 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 falls again, and once the number of days exceeds 40, the average value begins to rise in waves, and finally, once the number of days exceeds 55, the average value drops sharply. [Example]

[0200] Figure 29 is a flowchart outlining Example 3. Once the details of the optimal play are presented, the amount of resources acquired and the amount of status growth at that time, as well as the amount acquired (calculated) for each content (regular quests, event quests, PvP, gacha, etc.), are compared with the values ​​intended by the developer. Based on the results, parameter settings are changed to reduce the difference (step 2901). Next, when the difference falls below a certain threshold, convergence is considered to have occurred. When the user plays at optimal efficiency, parameter settings are determined so that the amount of items acquired, the growth of status, and the distribution ratio for each content approach those intended by the developer (step 2902).

[0201] <Master auto-tuning (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 schematically in Figure 30.

[0202] Fig. 30 is a flowchart 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 combat power value P e , the power value P in the optimal play at the current master value (t) Then, the vector m of master values ​​before adjustment (t) The adjustment formula for can be as follows. For example, a can be calculated by setting a specific value such as 0.8 or 1.2.

number

[0204] The first argument can be the maximum power value expected for optimal play. This method also allows you to specify the story type and item type for adjustment. In addition to any other required input files, you can also create and specify the "auto_params.csv" file shown below. The id, major category name, Item, and adjustment multiplier represent the index, story type, item to be adjusted, and initial adjustment multiplier, respectively. Specifying an adjustment multiplier greater than 0 multiplies the amount of the initially specified item by the adjustment multiplier. Setting it to 0 does not perform any adjustment. As with Monte Carlo simulation, to prevent overwriting, if a file required as input exists in the output file path specified by output_path, the file in the output file path will be read.

[0205] [Table 2]

[0206] <output file> Along with the power-adjusted master file, a log file, params.log, showing the process of adjusting the power value may be generated with the following content: 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 as the number of cycles is repeated, the power value gradually converges from 400 to around 300.

[0208] Figure 32 is a diagram showing the master before and after adjustment using the automatic adjustment method of the present invention. Referring to Figure 32, the table on the left (3210) shows the 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. While this trend is not always observed, in the case of Figure 32, it can be seen that the value of the character strengthening material for each quest and event decreases 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 (A) calculates, 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) visualizes 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, in which the computer further executes 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 Example 3 of the present disclosure is a game evaluation method according to Example 2, in which a computer repeats steps (C) to (D) until the balance is below a predetermined value.

[0213] A game evaluation method according to Example 4 of the present disclosure is the game evaluation method described in Example 1, wherein the master is a master with a unified format across multiple games that has been converted from a non-standard master with a format that is not unified across 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), the time change in the balance of each item is visualized.

[0215] A game evaluation method according to Example 6 of the present disclosure is a game evaluation method according to Example 5, wherein step (B) further visualizes the change over time in the amount of each item acquired and consumed.

[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 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 based on the parameters of a master, 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 perform 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 the parameters of a master; and (B) visualizing the balance of each item based on the result of the multiplication.

[0218] An app evaluation method 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 takes an action based on master parameters and the expected number of times the user will take the action; and (B) visualizing the income and expenditure of each item based on the result of the multiplication.

[0219] The method according to Example 2-1 of the present disclosure includes the steps of inputting a master including a play assumption; 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 value of the status or 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, wherein the ε-greedy method calculates the reward based on play assumptions or random selection.

[0222] A method according to Example 2-4 of the present disclosure is the method according to any one of Examples 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, which includes 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 the optimal play or total strength value based on the master and the number of simulations, and outputting the statistical distribution of the calculation results of the optimal play.

[0225] The program according to Example 2-7 of the present disclosure is a program including instructions for causing a processor to execute the methods described in Examples 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 an apparatus for executing the methods of Examples 2-1 to 2-6.

[0227] A method according to Example 3-1 of the present disclosure is a method that is performed by a computer, comprising 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] The 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 step (B) and step (C) are repeated until the total combat power value becomes 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 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 an apparatus for executing the methods of embodiments 3-1 to 3-3. [Industrial Applicability]

[0232] The present disclosure is applicable to, for example, 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 UX Check 201 Expansion Period 202 Rapid Decline 203 Tapering Period 204 Core Fun 205 Realizing Growth 206 Heroism 210 Maximizing Sales Through Lebedeza 211 Maintaining sales through Lebedeza 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) inputting a master including an optimal play, the optimal play being a play that maximizes the average status or the average value of the total amount of acquired resources within a predetermined period, and the master defining the values ​​of parameters used in the game; (B) calculating a total strength value based on the optimal play; (C) adjusting the value of a parameter included in the master based on the total combat power value; A method for performing the above by a computer.

2. 2. The method of claim 1, wherein steps (B) and (C) are repeated until the total combat power value is equal to or less than a predetermined value.

3. A program comprising instructions for a processor to execute the method according to claim 1 or 2.

4. 3. Apparatus for carrying out the method of claim 1 or 2, comprising one or more processors and a memory.

Images