JP7519199B2 - Electronic game information processing device and electronic game information processing program - Google Patents

Description

The present invention relates to an electronic game information processing device and an electronic game information processing program.

Conventionally, electronic game information processing devices that provide electronic games are known. Conventionally, electronic game information processing devices analyze the playing status of a player in an electronic game (in other words, the way the player plays the electronic game) to obtain analytical information. For example, a game planner who creates an electronic game can refer to such analytical information when updating the electronic game or creating other electronic games to be released in the future.

For example, Patent Document 1 discloses an electronic game information processing device that displays statistical data indicating the performance effect value of each character in an electronic game based on log data from the electronic game in which players compete using game elements (characters) that can activate skills depending on the game situation.

JP 2018-175830 A

However, in electronic games involving multiple game elements (such as in-game characters or players playing the game), it can be difficult to ascertain whether the overall game balance is being properly maintained. Game balance is not being properly maintained when, for example, a particular game element is too advantageous in the game, a game element with a particular attribute is always advantageous over game elements with other attributes, there are game elements that are useful in any game state, or a game element behaves differently from what the game planner expected.

The object of the present invention is to make it easy to understand whether the overall game balance is being properly maintained in an electronic game involving multiple game elements.

The present invention is an electronic game information processing device characterized by comprising: a graph generation unit that generates a graph representing relationships between a plurality of game elements related to an electronic game, the graph including a plurality of nodes representing a plurality of game elements related to the electronic game and edges connecting each node, based on log data of the electronic game; a learning processing unit that trains a learning model to predict relationships between the plurality of game elements immediately after the occurrence of an event, using as learning data the content of a past event that has occurred in the electronic game, an embedded representation of the plurality of nodes obtained from the graph generated immediately before the occurrence of the past event, and the relationship between the plurality of game elements immediately after the occurrence of the past event; a prediction graph generation unit that generates a prediction graph, which is the graph showing the relationships between the plurality of game elements immediately after the occurrence of the new event, by inputting the content of a new event that has not yet occurred in the electronic game and the embedded representation of the plurality of nodes obtained from the graph generated immediately before the occurrence of the new event into the trained learning model; and a display control unit that displays the graph and the prediction graph on a display unit.

Preferably, the system further includes a community processing unit that defines a plurality of communities in the graph, the communities being the nodes corresponding to the game elements that are highly related to each other, and detects relationships between the plurality of communities, and the display control unit causes the display unit to display information indicating the relationships between the plurality of communities.

Preferably, the predicted graph generation unit generates the predicted graph showing the relationships between the multiple game elements immediately after the occurrence of the new event sequence by inputting into the trained learning model the contents of a new event sequence, which is a series of new events, in which the relationships between the multiple game elements immediately after the occurrence of the new event sequence change when the order of occurrence of the new events contained in the new event sequence changes, and embedded representations of the multiple nodes obtained from the graph generated immediately before the occurrence of the new event sequence.

The present invention is also an electronic game information processing device comprising: a graph generation unit that generates a graph based on log data of an electronic game, the graph including a plurality of nodes representing operation contents of a plurality of players in the electronic game and edges connecting each node, and representing the relationship between the operation contents of the plurality of players; a display control unit that displays the graph on a display unit; a weighting unit that assigns a weight to the edge connecting the two nodes depending on values of player parameters of the player when the player performed the operation contents represented by the two nodes; and an operation pattern extraction unit that extracts from the graph an operation pattern of the player having a specific value of a specific player parameter based on the weight.

The present invention is also an electronic game information processing program that causes a computer to function as: a graph generation unit that generates, based on log data of an electronic game, a graph including a plurality of nodes representing a plurality of game elements related to the electronic game and edges connecting each node, and that represents the relationships between the plurality of game elements; a learning processing unit that trains a learning model to predict the relationships between the plurality of game elements immediately after the occurrence of an event, using as learning data the content of a past event that has occurred in the electronic game, an embedded representation of the plurality of nodes obtained from the graph generated immediately before the occurrence of the past event, and the relationships between the plurality of game elements immediately after the occurrence of the past event; a prediction graph generation unit that generates a prediction graph, which is the graph showing the relationships between the plurality of game elements immediately after the occurrence of the new event, by inputting the content of a new event that has not yet occurred in the electronic game and the embedded representation of the plurality of nodes obtained from the graph generated immediately before the occurrence of the new event into the trained learning model; and a display control unit that causes the graph and the prediction graph to be displayed on a display unit.
The present invention is also an electronic game information processing program that causes a computer to function as: a graph generation unit that generates a graph including a plurality of nodes representing operation contents of a plurality of players in an electronic game and edges connecting each node, based on log data of the electronic game, and representing the relationship between the operation contents of the plurality of players ; a display control unit that displays the graph on a display unit; a weighting unit that assigns weights to the edges connecting the two nodes depending on values of player parameters of the player when the player performed the operation contents represented by the two nodes; and an operation pattern extraction unit that extracts from the graph an operation pattern of the player having a specific value of a specific player parameter based on the weight.

According to the present invention, in an electronic game involving multiple game elements, it is easy to determine whether the overall game balance is being properly maintained.

1 is a schematic diagram illustrating the configuration of an electronic game system according to an embodiment of the present invention. FIG. 2 is a schematic diagram illustrating the configuration of a game server according to the present embodiment. FIG. 2 is a conceptual diagram showing an example of the contents of log data. FIG. 13 is a diagram showing an example of a character match table obtained from log data. FIG. 13 is a diagram showing edge values based on a character match table. FIG. 13 is a conceptual diagram showing an example of a graph. FIG. 13 is a diagram showing an example of a displayed graph. FIG. 11 is a diagram showing an example of a histogram indicating the strength of each character. FIG. 13 is a diagram showing an example of the number of characters used simultaneously obtained from log data. FIG. 13 is a diagram showing edge values based on the number of characters used simultaneously. FIG. 1 is a conceptual diagram illustrating multiple communities defined in a graph. This is a histogram showing the number of communities that a node belongs to. FIG. 13 is a diagram illustrating an example of a heat map showing relationships between communities. FIG. 1 is a conceptual diagram showing the learning process of a learning model. 1 is a conceptual diagram showing a new event sequence and graphs generated before and after the occurrence of the new event sequence. FIG. 13 is a diagram showing a player's operation pattern obtained from log data. FIG. 13 is a diagram showing a part of a graph obtained from a player's operation pattern. FIG. 13 is a conceptual diagram showing how actions are weighted according to values of player parameters. FIG. 13 is a diagram showing each operation pattern extracted according to each LTV. 1 is a histogram showing the number of players versus LTV.

Figure 1 shows a schematic diagram of the configuration of a game system 10 according to this embodiment. The game system 10 includes a player terminal 12 used by a player of an electronic game provided by the game system 10 (hereinafter referred to as "this game"), a planner terminal 14 used by a game planner of this game, and a game server 16 as an electronic game information processing device. The player terminal 12 and the game server 16, and the planner terminal 14 and the game server 16 are connected to each other so as to be able to communicate with each other via a communication line 18. The communication line 18 is, for example, the Internet or a local area network (LAN). Note that while only one player terminal 12 and one planner terminal 14 are shown in Figure 1, the game system 10 may be provided with multiple player terminals 12 used by multiple players and multiple planner terminals 14 used by multiple game planners.

In the game system 10 of this embodiment, the game program for operating the game is stored in the game server 16, and the game is provided to the player by accessing the game server 16 from the player terminal 12.

This game is a game in which multiple game elements related to this game are involved. Examples of game elements include, but are not limited to, in-game objects used in this game (e.g., characters, cards, etc.), players playing this game, the operations of players in this game, or the game state in this game. This game may be a battle-type game. In a battle-type game, for example, multiple players may each select a character and battle using the selected characters. In particular, each player may select multiple characters and battle using the selected multiple characters. In a battle-type game, the opponent of a player (hereinafter, referred to as "own player" when distinguishing from an opponent player) may be another player who is an opponent player, or may be a computer.

This game is a so-called online game provided by the game server 16. Therefore, the game planner who created this game can update this game at any time by accessing the game server 16 from the planner terminal 14. For example, the game planner can change the characters and cards that can be used in this game at any time (for example, adding new characters or deleting existing characters). In addition, this game can be played by any player who has a player terminal 12 that can access the game server 16. In other words, the number of players playing this game will increase or decrease at any time. In this way, in this game, game elements related to this game can dynamically increase or decrease.

The player terminal 12 and the planner terminal 14 may each be a general computer, such as a personal computer or a mobile terminal (e.g., a tablet terminal or a smartphone). The player terminal 12 and the planner terminal 14 each include a processor including, for example, a CPU (Central Processing Unit) or a microcomputer, a communication interface including, for example, a network adapter, an input interface including, for example, a mouse, a keyboard, or a touch panel, a display including, for example, a liquid crystal display, and a memory including, for example, a hard disk, a RAM (Random Access Memory), or a ROM (Read Only Memory).

Figure 2 shows a schematic diagram of the configuration of the game server 16. In this embodiment, the game server 16 is configured by a server computer, but the game server 16 may be any device as long as it performs the functions described below.

In the following description, the game is a battle game in which multiple players each select multiple characters and battle using the selected characters. Specifically, in this game, the player selects multiple characters to use in the battle from a group of characters assigned to the player (that the player owns in the game). In this specification, the multiple characters selected by the player to use in the battle are called a "deck." The opponent, who is a competing player or a computer, also selects multiple characters and organizes a deck. Then, the player and the opponent battle using their respective decks. In addition, players can acquire new characters in exchange for money or in-game points at a shop in this game. In addition, players can acquire new characters through events such as gacha (paid or free lottery) that are intermittently held by the game planner. New characters can be used at any time by updating the game from time to time by the game planner. In other words, when a new character is defined by the game planner, each player can acquire the new character through the above-mentioned shop or gacha.

Each character has character parameters. Character parameters include attack power, HP (hit points), skills, character attributes, and the like. The player's character (hereinafter referred to as "player's character") performs a normal attack on an opponent's character (hereinafter referred to as "opponent's character"), thereby reducing the opponent's character's HP by an amount corresponding to the attack power. In addition, the player's character activates a skill when a specific condition is met. There may be various types of skills, such as those that reduce the opponent's character's HP more than a normal attack, those that recover the player's character's HP, those that temporarily increase the player's character's attack power, and those that improve the character parameters of other player's characters in the deck simply by placing them in the deck. Character attributes indicate the characteristics of the character. For example, a character with a first attribute is set to be strong against a character with a second attribute, a character with a second attribute is set to be strong against a character with a third attribute, and a character with a third attribute is set to be strong against a character with a first attribute. For example, a normal attack by a character with a first attribute on a character with a second attribute can deal more damage than a normal attack on a character with a first or third attribute. Alternatively, advantageous effects (such as improved character parameters or the activation of special skills) may occur when all characters in a deck have the same attribute. When the HP of all characters in either the player's or opponent's deck reaches 0, the player loses and the other wins.

The communication interface 20 includes, for example, a network adapter and has the function of communicating with the player terminal 12 and the planner terminal 14 via the communication line 18.

The memory 22 includes, for example, a hard disk, RAM, or ROM. The memory 22 stores an electronic game information processing program for causing each part of the game server 16 to function. The memory 22 also stores the game program for the game. The electronic game information processing program and the game program may be an integrated program. As shown in FIG. 2, the memory 22 also stores a game log DB (database) 24 and a learning model 26.

The game log DB24 is a database that stores log data indicating the play history of the game, which is obtained by the player playing the game. Each time the player plays the game, log data is accumulated in the game log DB24.

An example of the contents of the game log DB 24 is shown in FIG. 3. In FIG. 3, the contents of the game log DB 24 are shown in table format, with each piece of log data being shown as a record. Each time a player performs an operation, a record is added as log data. In this embodiment, the log data is information that associates together a player ID that uniquely identifies a player, player parameters, and information regarding operations performed by the player in the game.

In this embodiment, the player parameters include, but are not limited to, a player level and a life time value (LTV). The player level is the level of the player at the time of operation in the game. The player level is a parameter that increases, for example, when the player wins a predetermined number of matches. When the player level increases, the player is more advantageous in the game, for example, by being able to include stronger characters in the deck. The LTV indicates the amount of money that the player has charged (paid) for the game up to the time of operation or within a predetermined period (for example, within one month) from the time of operation. In addition to the above, other player parameters include, for example, the number of days since the first play of the game, the progress (degree of progress) in the game, the number of consecutive days played in the game, and the time when play ended last time.

In addition, in this embodiment, the information regarding the player's operation includes the operation content and the operation time. As shown in FIG. 3, the operation content can be, for example, deck organization, battle, or shop, but is of course not limited to these. If the operation content is a battle, the log data is further associated with a used character ID that identifies the player's character used by the player (own player) in the battle, an opponent player ID that identifies the opponent player, an opponent character ID that identifies the opponent character used by the opponent player in the battle, and the result of the battle (win or loss).

The game log DB 24 also stores event data relating to events that the game planner has previously implemented in the game. Each time the game planner implements an event, event data is accumulated in the game log DB 24. The event data is stored in association with the content of the event and the time the event was implemented.

The learning model 26 is a learning device that is composed of, for example, a neural network. Details of the learning method of the learning model 26 and how it is used will be described later, along with the processing of the learning processing unit 36.

The processor 28 includes, for example, a CPU, a GPU (Graphics Processing Unit), or a microcomputer, and controls each part of the game server 16 according to an electronic game information processing program stored in the memory 22. As shown in FIG. 2, the processor 28 also functions as a graph generation unit 30, a display control unit 32, a community processing unit 34, a learning processing unit 36, a predicted graph generation unit 38, a weighting unit 40, and an operation pattern extraction unit 42 according to the electronic game information processing program.

The graph generation unit 30 generates a graph showing the relationships between multiple game elements in the game based on the log data stored in the game log DB 24. Specifically, the graph generated by the graph generation unit 30 includes multiple nodes representing multiple game elements related to the game and edges connecting each node, and is a graph showing the relationships between the multiple game elements.

The graph generating unit 30 can generate various graphs related to the game. For example, a graph can be generated in which each game element is a character used in the game, each node represents a character, and the number of wins and losses in battles for each character, i.e., the strength of each character. In this case, the graph generating unit 30 first creates a battle table between characters as shown in FIG. 4 based on log data in which the operation content is "battle". In the table in FIG. 4, the character IDs arranged vertically represent the player's character, and the character IDs arranged horizontally represent the opponent's character. For example, the table in FIG. 4 shows that the character indicated by the character ID "C001" (hereinafter, referred to as "character C001" or the like) has beaten character C002 100 times, and character C002 has beaten character C001 90 times. Note that in this game, decks including multiple characters battle against each other, so character C001 beating character C002 means that the deck including character C001 beats the deck including character C002.

Since character C001 has beaten character C002 100 times, the graph generation unit 30 draws an arrow (directed edge) having information of the value "100" from the node representing character C002 (hereinafter referred to as "node C002") to node C001, as shown in FIG. 5. This represents in the graph that character C001 has beaten character C002 100 times. In this embodiment, since character C002 has beaten character C001 90 times, conversely, an arrow (directed edge) having information of the value "90" is drawn from node C001 to node C002. Here, the graph generation unit 30 cancels out the information of the above two arrows and draws an arrow having information of the value "10 (100-90)" from node C002 to node C001.

In this way, the graph generation unit 30 generates a graph G including multiple nodes N and edges E connecting two nodes, as shown in FIG. 6, based on the results of battles between all characters defined in the game (between characters who have battled each other in the past). Although not shown in FIG. 6, in graph G representing the strength of characters, edges E are arrows as described above, so graph G is a directed graph. Graph G generated by the graph generation unit 30 is stored in the game log DB 24 in association with the time of generation.

The graph generating unit 30 may calculate the strength of each character by calculating a page rank in the generated graph. In this example, the page rank is a method of determining that character C001 is stronger when, for example, considering the relationship between character C001 and character C002, character C001 is stronger if character C002 has more wins than character C001 compared to when character C002 has few wins against characters other than character C001.

The display control unit 32 displays the graph generated by the graph generation unit 30 on a display serving as a display unit of the planner terminal 14. When the graph generation unit 30 calculates the strength of each character, the display control unit 32 may display information indicating the strength of each character on the planner terminal 14. Various methods may be adopted to express the strength of each character. For example, as shown in FIG. 7, the display control unit 32 changes the size of the node N corresponding to each character in the graph G according to the strength of each character. In the example of FIG. 7, the node Na is displayed prominently and large compared to the other nodes N. This allows the planner to easily grasp that the character corresponding to the node Na is prominently stronger than the other characters. Alternatively, the display control unit 32 may express the strength of each character by the color of each node N. The display control unit 32 may also display the distribution of the strength of each character generated by the graph generation unit 30 on the planner terminal 14 in the form of a histogram as shown in FIG. 8.

If necessary, the display control unit 32 can also display the graph generated by the graph generation unit 30 and information indicating the strength of each character on the display of the player terminal 12. The same applies to other information described below.

The graph generating unit 30 can generate a graph in which each game element is a character used in the game, each node represents a character, and the degree of association between the characters is represented. In this case, the degree of association between the characters means the likelihood of the characters being used simultaneously. In other words, when focusing on two characters, the more times they are used simultaneously, the higher the degree of association between the two characters. Characters used simultaneously means characters that are put into the same deck and used in a battle. First, the graph generating unit 30 creates a simultaneous use count table showing the number of simultaneous uses of each character, as shown in FIG. 9, based on the log data in which the operation content is "battle". In the table in FIG. 9, the character IDs arranged vertically represent the characters of interest, and the character IDs arranged horizontally represent the characters used simultaneously with the characters of interest. For example, the table in FIG. 9 shows that characters C001 and C002 have been used simultaneously 100 times, and characters C001 and C003 have been used simultaneously 80 times.

Because characters C001 and C002 are used simultaneously 100 times, the graph generation unit 30 connects node C001 and node C002 with an edge (undirected edge) having the value "100" as information, as shown in FIG. 10. This indicates in the graph that characters C001 and C002 are used simultaneously 100 times. Furthermore, because characters C001 and C003 are used simultaneously 80 times, the graph generation unit 30 connects node C001 and node C003 with an edge (undirected edge) having the value "80" as information, as shown in FIG. 10. In this way, the graph generation unit 30 generates a graph showing the degree of association between each character based on the number of times all characters defined in this game are used simultaneously. The graph showing the degree of association between each character is an undirected graph.

The graph generation unit 30 may calculate the versatility of each character by calculating closeness centrality or betweenness centrality in a graph representing the degree of association between each character.

Closeness centrality is an index that indicates centrality within a graph, and the closeness centrality of a focus node can be calculated as the sum of the edge values on the shortest path between the focus node and all other nodes in the graph. Therefore, the more closely related the focus node is to other nodes (the more frequently it is used simultaneously), the greater the closeness centrality of the focus node to all other nodes, and the more versatile the character represented by the focus node is.

Betweenness centrality is an index that indicates how frequently the node of interest is located on the shortest path between two other nodes. The higher the betweenness centrality of the node of interest, the more versatile the character it represents.

The display control unit 32 causes the planner terminal 14 to display the graph generated by the graph generation unit 30, which represents the relevance of each character. At this time, the display control unit 32 may cause the planner terminal 14 to display information indicating the calculated versatility of each character. For example, the size of the node corresponding to each character in the graph may be changed and displayed according to the versatility of each character. The display control unit 32 may also cause the planner terminal 14 to display a histogram indicating the distribution of versatility of each character.

The graph generating unit 30 can generate a graph based on all the log data stored in the game log DB 24, or can generate a graph based on a portion of the log data. For example, it can extract only the log data acquired during a specific period based on the operation time of the log data, and generate a graph based on the extracted log data.

The community processing unit 34 defines multiple communities, which are multiple nodes corresponding to multiple game elements that are highly related to each other, in the graph generated by the graph generation unit 30. The communities can be defined using known methods such as community detection. In this game, the relationship between multiple game elements that are often used simultaneously is high, so nodes corresponding to multiple characters that are particularly often used simultaneously belong to the same community. Figure 11 shows multiple communities C defined in graph G by the community processing unit 34.

By defining multiple communities in the graph, the community processing unit 34 can detect the versatility of each game element in the game. Specifically, the greater the number of communities to which the focus node belongs, the higher the degree of association between the game element corresponding to the focus node and many other game elements, and therefore the higher the versatility of the game element corresponding to the focus node. For example, in the example of FIG. 11, the number of community affiliations of nodes N other than node Nb is 1 or 2, but the number of community affiliations of node Nb is 4. Therefore, it can be detected that the versatility of the character represented by node Nb in the game is higher than that of other characters.

The display control unit 32 causes the planner terminal 14 to display information indicating the number of communities to which each node included in the graph belongs. For example, as shown in FIG. 12, the number of communities to which each node included in the graph belongs is displayed on the planner terminal 14 in the form of a histogram or the like. This allows the planner to easily grasp the versatility of each character.

The community processing unit 34 may also detect the relationship between the multiple communities defined. In this embodiment, the community processing unit 34 detects the strength between the communities, that is, the strength between the multiple characters represented by the multiple nodes included in a certain community and the multiple characters represented by the multiple nodes included in another community. The community processing unit 34 calculates the strength between the communities based on the log data stored in the game log DB 24. Specifically, based on a character match table (see FIG. 4) created based on the log data, the community processing unit 34 calculates the number of wins of the first community against the second community by subtracting the total number of wins of the multiple characters included in the second community against the characters included in the first community from the total number of wins of the multiple characters included in the first community against the characters included in the second community. The greater the number of wins, the stronger the first community is against the second community. The calculation of the strength between the communities may be performed by other methods.

The display control unit 32 causes information indicating the relationships between multiple communities (in this embodiment, the strengths and weaknesses between communities) detected by the community processing unit 34 to be displayed on the display of the planner terminal 14. For example, a heat map as shown in FIG. 13 is displayed on the planner terminal 14. In the heat map of FIG. 13, each vertical row represents a respective community, and each horizontal column represents an opposing community. The more wins the own community has against the opposing community, the more strongly the cell in the heat map corresponding to the pair of the own community and the opposing community is highlighted.

In addition, as the player progresses through the game, the relationships between the characters in the game also change, so the graph generation unit 30 may repeat generating the graph intermittently. Incidentally, the graph may of course change when the game planner updates the game (for example, by adding a new character or implementing an event), but the graph may also change even if the game is not updated. For example, if a player of the game posts on a social networking service (SNS) that a particular character is useful, the number of players using that character may increase, changing the relationships between the characters and causing a change in the graph.

Each time a new graph is generated by the graph generation unit 30, the community processing unit 34 defines the communities in that graph. By displaying the graphs generated at multiple points in time and the communities defined on the planner terminal 14, the planner can easily grasp how each community changes over time. Modes of change over time in a community include "growth," in which the game elements (characters in this embodiment) represented by the nodes belonging to the community increase, "contraction," in which the game elements (characters in this embodiment) represented by the nodes belonging to the community decrease, "merging," in which multiple communities are combined into one, "splitting," in which one community splits into multiple communities, "birth," in which a community that did not exist at the previous point in time is defined, and "disappearance," in which a community that existed at the previous point in time disappears.

Returning to FIG. 2, the learning processing unit 36 trains the learning model 26 to predict the relationship between the multiple game elements immediately after the occurrence of an event, using the contents of past events that occurred in the game, the embedded representation of the multiple nodes obtained from the graph generated by the graph generating unit 30 immediately before the occurrence of the past event, and the relationship between the multiple game elements immediately after the occurrence of the past event as learning data. Note that "immediately before the occurrence of an event" refers to a time before the occurrence of the event, and a time when the relationship between the multiple game elements does not change from that time to the time of the event occurrence. In other words, "immediately before the occurrence of an event" refers to a time when attention is paid to the change in the relationship between the multiple game elements, and does not directly define the length of time until the event occurs. Similarly, "immediately after the occurrence of an event" refers to a time after the occurrence of the event, and a time when the relationship between the multiple game elements does not change from the time of the event occurrence to that time. In other words, "immediately after the occurrence of an event" refers to a time when attention is paid to the change in the relationship between the multiple game elements, and does not directly define the length of time from the event occurrence.

Figure 14 shows how the learning processing unit 36 learns the learning model 26. First, the learning processing unit 36 refers to the game log DB 24 to identify the contents of a past event and a graph generated immediately before the occurrence of the past event. Next, the learning processing unit 36 performs a graph embedding process on the identified graph and extracts an embedded representation of each node included in the graph. A known technology (e.g., GraphSAGE) can be used as the graph embedding process. The embedded representation of the node of interest includes features that indicate the relationship between the node of interest and other nodes in the graph. In other words, it can be said that the embedded representation of the node of interest includes the game element corresponding to the node of interest and features that indicate the relationship with the other game elements. Therefore, the embedded representations of multiple nodes that are surrounded by similar node groups in the graph (that are closely related to the same type of node group) will show similar features.

Then, the learning processing unit 36 inputs one pair of the obtained embedded expressions (in the example of FIG. 14, the pair of the embedded expressions of nodes C001 and C002) and the contents of the past event to the learning model 26. From the input, the learning model 26 outputs the relationship between nodes C001 and C002 immediately after the occurrence of the past event. Specifically, the learning model 26 predicts and outputs the value that the edge connecting nodes C001 and C002 has as information immediately after the occurrence of the past event.

Furthermore, the learning processing unit 36 trains the learning model 26 so that the difference between the relationship between the multiple game elements immediately after the occurrence of the past event, which is the teaching data (in this example, the value of the edge connecting node C001 and node C002 immediately after the occurrence of the past event) and the relationship output by the learning processing unit 36 (in this example, the predicted value of the edge connecting node C001 and node C002 immediately after the occurrence of the past event) is small. For example, the weights and biases of each neuron in the learning model 26 are adjusted.

By the learning processing unit 36 repeating the above-mentioned learning process, the learned learning model 26 becomes able to predict the relationships (edge values) between each node in the graph generated immediately after the occurrence of a new event that has not yet occurred, based on the embedded representation of each node obtained from the graph generated by the graph generation unit 30 immediately before the occurrence of the new event and the content of the new event.

When the planner specifies a new event that has not yet occurred in the game, the predicted graph generating unit 38 inputs the content of the new event and the embedded representation of each node obtained from the graph generated by the graph generating unit 30 immediately before the occurrence of the new event to the trained learning model 26. In this embodiment, the predicted graph generating unit 38 inputs the graph generated by the graph generating unit 30 at the current time to the learning model 26 as the graph immediately before the occurrence of the new event. Based on the input, the learning model 26 predicts and outputs the relationship of each node immediately after the occurrence of the new event. Based on the output of the learning model 26 (the relationship of each node immediately after the occurrence of the new event), the predicted graph generating unit 38 generates a predicted graph that is a graph showing the relationship between multiple game elements immediately after the occurrence of the new event. The display control unit 32 displays the generated predicted graph on the display of the planner terminal 14.

This allows the planner to easily grasp how the relationships between multiple game elements of the game will change after a new event scheduled for implementation in the future occurs. For example, if the new event is the addition of a new character, the planner can easily grasp whether the game balance will be properly maintained, such as whether the addition of the new character will make a particular character extremely strong or extremely weak.

The predicted graph generating unit 38 may also generate a predicted graph showing the relationships between multiple game elements immediately after the occurrence of the new event sequence by inputting the contents of the new event sequence, which is a series of new events, and the embedded representation of each node obtained from the graph generated by the graph generating unit 30 immediately before the occurrence of the new event sequence into the trained learning model 26. By displaying the predicted graph on the planner terminal 14, the planner can grasp the relationships between multiple game elements of the game after the new event sequence occurs.

A new event sequence may be one in which, when the order of occurrence of new events contained therein is changed, the relationship between multiple game elements immediately after the occurrence of the new event sequence changes. For example, in the new event sequence shown in FIG. 15, the order of occurrence of each new event is "Strengthen character A" → "Add character B" → "Implement gacha" → "Implement campaign" → "Add character C", and the graph showing the relationship between multiple game elements immediately after the occurrence of this new event sequence is graph Ga. Here, if the order of occurrence of new events in the new event sequence is changed, for example, to "Strengthen character A" → "Add character B" → "Add character C" → "Implement gacha" → "Implement campaign", the relationship between multiple game elements immediately after the occurrence of the new event sequence will change, and the graph showing the relationship between multiple game elements immediately after the occurrence of the new event sequence will not necessarily be the same as Ga.

Therefore, the planner can rearrange the order in which new events occur in the new event sequence, input the rearranged order into the learning model 26, and compare the multiple predicted graphs obtained to determine the optimal order in which new events occur that will provide the best game balance for the game prior to implementing the new event sequence.

The predicted graph generating unit 38 sequentially inputs the contents of the multiple new events included in the new event sequence into the learning model 26 to obtain the relationships between the multiple game elements immediately after the occurrence of the new event sequence. Explaining with reference to FIG. 15, the predicted graph generating unit 38 first inputs the contents of the event "Strengthen character A" and the embedded representation of each node obtained from the graph generated at the current time into the learning model 26 to generate a first intermediate predicted graph showing the relationships between the multiple game elements immediately after the occurrence of the event "Strengthen character A". Next, the predicted graph generating unit 38 inputs the contents of the event "Add character B" and the embedded representation of each node obtained from the first intermediate predicted graph into the learning model 26 to generate a second intermediate predicted graph showing the relationships between the multiple game elements immediately after the occurrence of the event "Add character B". This process is repeated to obtain the relationships between the multiple game elements immediately after the occurrence of the new event sequence.

The prediction graph generation unit 38 can also input the contents of multiple new events included in a new event sequence all at once to the learning model 26 to obtain the relationships between multiple game elements immediately after the occurrence of the new event sequence. For example, if the learning model 26 includes an RNN (recurrent neural network), the contents of multiple new events included in a new event sequence can be input all at once. In this case, the relationships between multiple game elements immediately after the occurrence of the new event sequence are obtained without generating an intermediate prediction graph.

The learning processing unit 36 may also use the contents of a past event sequence, which is a series of past events that occurred in the game, the embedded representations of multiple nodes obtained from the graph generated by the graph generating unit 30 immediately before the occurrence of the past event sequence, and the relationships between multiple game elements immediately after the occurrence of the past event sequence as learning data to train the learning model 26 to predict the relationships between multiple game elements immediately after the occurrence of the event sequence. In this case, the predicted graph generating unit 38 inputs the contents of a new event sequence and the embedded representations of each node obtained from the graph generated by the graph generating unit 30 immediately before the occurrence of the new event sequence to the trained learning model 26, so that the learning model 26 can output the relationships between multiple game elements immediately after the occurrence of the new event sequence. The predicted graph generating unit 38 generates a predicted graph showing the relationships between multiple game elements immediately after the occurrence of the new event sequence based on the output of the learning model 26.

The weighting unit 40 and the operation pattern extraction unit 42 (see FIG. 1) will be described below. In the following description of the weighting unit 40 and the operation pattern extraction unit 42, the graph generation unit 30 generates a graph in which each game element is an operation content of each player in the game, each node represents each operation content, and the relationship between each operation content, specifically, the flow of each operation (operation pattern). In this case, the graph generation unit 30 represents the flow of operations of a certain player with nodes and edges based on the player ID, operation content, and operation time in the log data. For example, referring to FIG. 3, when focusing on the operation of the player indicated by the player ID "P001", the operation content is operation A (hereinafter referred to as "operation A") → operation B → operation C in that order. Therefore, the graph generation unit 30 draws an arrow from node A corresponding to operation A to node B corresponding to operation B, and draws an arrow from node B to node C corresponding to operation C, as shown at the top of FIG. 16. In this way, the graph generation unit 30 represents the operation patterns of each player with nodes and edges.

The graph generation unit 30 then merges the nodes and edges generated for each player to generate graph G as shown in FIG. 17. For example, if the operation pattern for each player is represented by nodes and edges as shown in FIG. 16, the operation performed after operation A is operation B, operation D, or operation E. Therefore, the graph generation unit 30 draws arrows from node A to node B, node D, and node E. Similarly, the operation performed after operation B is operation C or operation D. Therefore, the graph generation unit 30 draws arrows from node B to node C and node D. The graph generation unit 30 repeats this process to generate graph G.

In this embodiment, in order to indicate the order of each operation by the player, each edge is an arrow (directed edge) and graph G is a directed graph; however, the order of each operation by the player does not need to be taken into consideration, in which case each edge may be an undirected edge and graph G may be an undirected graph.

The weighting unit 40 assigns weights to edges connecting two nodes in a graph generated by the graph generating unit 30, which represents the operation patterns of one or more players, depending on the values of the player parameters of the player when the player performs the operation contents represented by the two nodes.

With reference to FIG. 18, the details of the processing of the weighting unit 40 will be described. In the following example, LTV is used as the player parameter. First, the weighting unit 40 extracts a combination of two operations by each player based on the log data. In this specification, a combination of two operations is called an "action". For example, an action may be an operation A → operation B, an operation B → operation C, etc. Table Ta shown in FIG. 18 shows the actions of multiple players extracted from the log data and the LTV of each player when the action was performed. For example, table Ta shows that when a certain player performs an action of operation A → operation B, the LTV of the player is "50", and when a certain player performs an action of operation B → operation C, the LTV of the player is "40". Incidentally, if the player's LTV when performing two operations included in an action is different, the player's LTV when performing either the previous or next operation may be used as the player's LTV when performing that action, or the average of the player's LTV when performing the two operations may be used.

Next, the weighting unit 40 aggregates the LTVs of each player for the same action based on table Ta. In this embodiment, the weighting unit 40 sets the average value of the LTVs of each player for the same action as the aggregated LTV of the action. For example, table Ta includes two actions, operation A → operation B, and when one player performs the action of operation A → operation B, the LTV is 50, and when another player performs the action of operation A → operation B, the LTV is 10. Therefore, the weighting unit 40 sets the aggregated LTV of the action of operation A → operation B to 30, which is the average value of 50 and 10. In this way, the LTVs of each player for the same action are aggregated to obtain table Tb.

Furthermore, the weighting unit 40 assigns a weight to each action according to the aggregated LTV for each action based on the table Tb. Since an action is composed of a combination of two operations, the weight of an action can be defined as the weight of an edge connecting nodes corresponding to two operations in the graph.

There are various methods for weighting. In this embodiment, the weighting unit 40:
(1) A weight that has a larger value as the LTV approaches the maximum value (2) A weight that has a larger value as the LTV approaches the minimum value (3) A weight that has a larger value as the LTV approaches the median value (4) A weight that has a larger value as the LTV approaches the average value (5) A weight that has a larger value as the LTV approaches the midpoint value is assigned to each action. In this embodiment, each weight takes a value between 0 and 1. The maximum value, minimum value, median value, average value, and midpoint value in the above are the maximum value, minimum value, median value, average value, and midpoint value of multiple LTVs in table Tb. Incidentally, the midpoint value is the intermediate value between the maximum value and the minimum value.

式１において、ｍａｘはテーブルＴｂにおけるＬＴＶの最大値、ｍｉｎはテーブルＴｂにおけるＬＴＶの最小値、ｘは重みの対象となるＬＴＶの値を示す。
上記（２）ＬＴＶが最小値に近い程大きな値を有するような重みｆ（ｘ_ｍｉｎ）は、以下の式２で算出することができる。

上記（３）ＬＴＶが中央値に近い程大きな値を有するような重みｆ（ｘ_{ｍｅｄｉａｎ}）は、以下の式３で算出することができる。

式３において、ｍｅｄｉａｎはテーブルＴｂにおけるＬＴＶの中央値を示す。
上記（４）ＬＴＶが平均値に近い程大きな値を有するような重みｆ（ｘ_ｍｅａｎ）は、以下の式４で算出することができる。

式４において、ｍｅａｎはテーブルＴｂにおけるＬＴＶの平均値を示す。
上記（５）ＬＴＶが中点値に近い程大きな値を有するような重みｆ（ｘ_ｍｉｄ）は、以下の式５で算出することができる。

式５において、ｍｉｄｒａｎｇｅはテーブルＴｂにおけるＬＴＶの中点値を示す。 The weight f(x _max ) having a larger value as the above (1) LTV approaches the maximum value can be calculated by the following formula 1.

In formula 1, max is the maximum value of the LTV in table Tb, min is the minimum value of the LTV in table Tb, and x is the value of the LTV to be weighted.
The weight f(x _min ) having a larger value as the above (2) LTV approaches the minimum value can be calculated by the following formula 2.

The weight f(x _median ) having a larger value the closer the LTV is to the median (3) can be calculated by the following formula 3.

In Equation 3, median indicates the median value of LTV in table Tb.
The weight f(x _mean ) having a larger value as the LTV (4) is closer to the average value can be calculated by the following formula 4.

In Equation 4, mean represents the average value of LTV in table Tb.
The weight f(x _mid ) having a larger value as the LTV (5) approaches the midpoint value can be calculated by the following formula 5.

In Equation 5, midrange indicates the midpoint value of the LTV in table Tb.

18 shows, as an example, a table Tc indicating a weight f(x _max ) for each behavior (1) that increases as the LTV approaches the maximum value, and a table Td indicating a weight f(x _min ) for each behavior (2) that increases as the LTV approaches the minimum value, which are assigned based on the table Tb. In this manner, the weights (1) to (5) assigned to each behavior are stored in the memory 22.

The operation pattern extraction unit 42 extracts from the graph an operation pattern of a player having a specific value of a specific player parameter based on the weighting applied by the weighting unit 40.

Specifically, when the planner specifies a specific player parameter and a specific value, and information indicating them is sent from the planner terminal 14 to the game server 16, the operation pattern extraction unit 42 extracts from the graph the operations performed by the player who has the specific value (or a value close to the specific value) of the specific player parameter, based on the weight corresponding to the specific value of the specific player parameter.

For example, when the planner specifies LTV as a player parameter and the maximum value as a value, the operation pattern extraction unit 42 extracts actions for which the weight f(x _max ) in (1) given to each action is equal to or greater than a predetermined threshold value (e.g., 0.8). An example of an extracted graph, which is a part of a graph extracted in this way, is shown in Fig. 19(a). The extracted graph shown in Fig. 19(a) shows actions that are often performed by players whose LTV is close to the maximum value.

Similarly, for example, if the planner specifies LTV as the player parameter and minimum, median, average, and midpoint as the values, the operation pattern extraction unit 42 extracts actions for which the weight f(xmin) in (2), the weight f( _xmedian ) in (3), the weight f( _xmean ) _in (4), and the weight f( _xmid ) in (5) given to each action are equal to or greater than a predetermined threshold value (e.g., 0.8). Examples of extracted graphs, which are parts of graphs extracted in this way, are shown in Figures 19(b), (c), (d), and (e), respectively.

As shown in FIG. 20, LTV and player level tend to have a distribution in which the number of players peaks at low values and the number of players in the high value range is quite small. Therefore, when a planner wants to extract actions that are often performed by the majority of players, it is preferable to specify the median value rather than the average or midpoint value to extract an extraction graph. Of course, the distribution varies depending on the player parameters, and for example, in the case of player parameters in which the number of players is distributed according to a normal distribution, it may be preferable to specify the average or midpoint value when extracting actions that are often performed by the majority of players. Therefore, in this embodiment, by applying multiple weights such as those in (1) to (5) above to each action, the planner can extract an extraction graph based on an appropriate representative value according to the player parameters (distribution).

Each of the extracted graphs shown in FIG. 19 is displayed on the planner terminal 14. This allows the planner to easily understand the actions that are often performed by a player who has a specific value of a specific player parameter.

In addition, the planner can specify a specific period, which allows the operation pattern extraction unit 42 to extract an extraction graph for the specific period. In this case, the graph generation unit 30 generates a graph based on the log data acquired during the period specified by the planner, and the operation pattern extraction unit 42 extracts an extraction graph from the graph.

Although the embodiment of the present invention has been described above, the present invention is not limited to the above embodiment, and various modifications are possible without departing from the spirit of the present invention.

For example, in this embodiment, the game log DB 24 and the learning model 26 are stored in the memory 22 of the game server 16, but these may also be stored in the memory of another device rather than the game server 16.

10 Game system, 12 Player terminal, 14 Planner terminal, 16 Game server, 20 Communication interface, 22 Memory, 24 Game log DB, 26 Learning model, 28 Processor, 30 Graph generation unit, 32 Display control unit, 34 Community processing unit, 36 Learning processing unit, 38 Prediction graph generation unit, 40 Weighting unit, 42 Operation pattern extraction unit.

Claims (6)

a graph generating unit that generates a graph including a plurality of nodes representing a plurality of game elements related to the electronic game and edges connecting the respective nodes, and that represents relationships between the plurality of game elements, based on log data of the electronic game;
a learning processing unit that trains a learning model to predict relationships between the plurality of game elements immediately after the occurrence of an event, using as learning data the contents of past events that have occurred in the electronic game, embedded representations of the plurality of nodes obtained from the graph generated immediately before the occurrence of the past events, and relationships between the plurality of game elements immediately after the occurrence of the past events;
a predicted graph generation unit that generates a predicted graph, which is the graph showing the relationship between the plurality of game elements immediately after the occurrence of the new event, by inputting into the trained learning model the content of a new event that has not yet occurred in the electronic game and an embedded representation of the plurality of nodes obtained from the graph generated immediately before the occurrence of the new event;
a display control unit that displays the graph and the predicted graph on a display unit;
An electronic game information processing device comprising: a community processing unit that defines a plurality of communities in the graph, the communities being a plurality of nodes corresponding to a plurality of the game elements that have a high degree of association with each other, and detects relationships between the plurality of communities;
Further equipped with
the display control unit causes information indicating relationships between the plurality of communities to be displayed on the display unit.
2. The electronic game information processing device according to claim 1 . the prediction graph generation unit generates the prediction graph showing the relationships between the multiple game elements immediately after the occurrence of the new event sequence by inputting into the trained learning model the contents of a new event sequence, which is a series of new events, where a change in the order of occurrence of the new events included in the new event sequence changes the relationships between the multiple game elements immediately after the occurrence of the new event sequence, and embedded representations of the multiple nodes obtained from the graph generated immediately before the occurrence of the new event sequence;
2. The electronic game information processing device according to claim 1 . a graph generating unit that generates a graph including a plurality of nodes each representing operation contents of a plurality of players in the electronic game and edges connecting each node, and that represents a relationship between the operation contents of the plurality of players , based on log data of the electronic game;
a display control unit that displays the graph on a display unit;
a weighting unit that assigns a weight to the edge connecting the two nodes in accordance with a value of a player parameter of the player when the player performs an operation having operation contents represented by the two nodes;
an operation pattern extraction unit that extracts, from the graph, an operation pattern of the player having a specific value of a specific player parameter based on the weight;
An electronic game information processing device comprising: Computer,
a graph generating unit that generates a graph including a plurality of nodes representing a plurality of game elements related to the electronic game and edges connecting the respective nodes, and that represents relationships between the plurality of game elements, based on log data of the electronic game;
a learning processing unit that trains a learning model to predict relationships between the plurality of game elements immediately after the occurrence of an event, using as learning data the contents of past events that have occurred in the electronic game, embedded representations of the plurality of nodes obtained from the graph generated immediately before the occurrence of the past events, and relationships between the plurality of game elements immediately after the occurrence of the past events;
a predicted graph generation unit that generates a predicted graph, which is the graph showing the relationship between the plurality of game elements immediately after the occurrence of the new event, by inputting into the trained learning model the content of a new event that has not yet occurred in the electronic game and an embedded representation of the plurality of nodes obtained from the graph generated immediately before the occurrence of the new event;
a display control unit that displays the graph and the predicted graph on a display unit;
4. An electronic game information processing program comprising: Computer,
a graph generating unit that generates a graph including a plurality of nodes each representing operation contents of a plurality of players in the electronic game and edges connecting each node, and that represents a relationship between the operation contents of the plurality of players , based on log data of the electronic game;
a display control unit that displays the graph on a display unit;
a weighting unit that assigns a weight to the edge connecting the two nodes in accordance with a value of a player parameter of the player when the player performs an operation having operation contents represented by the two nodes;
an operation pattern extraction unit that extracts, from the graph, an operation pattern of the player having a specific value of a specific player parameter based on the weight;
4. An electronic game information processing program comprising:

Images