JP7633718B2 - GAME MANAGEMENT DEVICE, GAME SYSTEM, GAME MANAGEMENT METHOD AND PROGRAM - Google Patents

Description

The present invention relates to a game management device, a game system, a game management method, and a program for managing games.

Games have been proposed in which various pre-determined events occur during the game (for example, see Patent Literature 1). A user progresses through the game while enjoying the events that occur during the game.

JP 2004-33488 A

Normally, a variety of events are prepared in advance as events that occur during a game. However, because the events that occur during a game are fixed, as a user plays the game multiple times, the same events may occur repeatedly, which can cause the user to become bored with the game.

The present invention was made in consideration of the above circumstances, and its purpose is to provide a highly entertaining game that users can play repeatedly without getting bored.

1) A game management device (3, 201, 203) according to one aspect of the present invention includes a setting means (71) for setting at least one character selected by a user from among a plurality of characters owned by the user as a first character for generating an event, and an event management means (72) for generating an event related to the first character during a game in accordance with the first character or a combination of a plurality of the first characters.

The game management device of this configuration can be configured, for example, by a computer (dedicated game machine, personal computer, smartphone, etc.) as a game device. Alternatively, this game management device can be configured by a computer such as a server that can communicate with each user's game terminal. Alternatively, this game management device can be configured by multiple computers (servers, game terminals) that communicate with each other.

In games managed by this game management device, users can own multiple characters. Depending on the content of the game, various characters can be used, such as people, animals, plants, imaginary creatures (monsters, etc.), and non-living things (materials, tools, etc.). Furthermore, within the game, characters can be displayed in various forms, such as two-dimensional or three-dimensional images, card-type images, etc.

In addition, in a game managed by this game management device, a user can select at least one character from among a plurality of characters owned by the user and set it as a character for generating an event. The at least one character selected by the user is set as the "first character for generating an event" by the setting means.

Then, the event management means generates an event related to the first character during the game according to the first character or a combination of multiple first characters set for event generation. Here, in a game based on a sports theme, an event related to the first character may be, for example, an event in which the first character practices or competes against a rival. In addition, the first character may act (for example, practice, eat, travel) together with a character that is an alter-ego of the user (my character). Note that the event related to the first character is not limited to an event in which the first character appears on the screen. For example, it may be an event in which a quiz related to the first character is given. In addition, it may be an event in which other characters related to the first character (friends, seniors, juniors, coaches, rivals, etc.) talk about the first character, or an event in which the rival of the first character practices to beat the first character.

When a first character or multiple first characters are set for an event to occur, the event may always occur, the event may occur with a predetermined probability, or the event may occur when a predetermined condition is met.

In addition, the event related to the first character can be an event related to the parameters (characteristic parameters) of the first character. For example, if the first character is a character with excellent specific abilities (the parameters of the specific abilities are higher than a predetermined standard), the event related to the first character can be an event related to the specific abilities (utilizing the specific abilities). As a specific example, if the first character is a player with excellent batting abilities (the parameters of the batting abilities are higher than a predetermined standard), the event related to the first character can be an event related to batting, such as batting training or a home run contest.

The event related to the first character may be an event related to the relationship between the first character and a second character (such as the user's My Character) described below. For example, if the first character and the second character are rivals in the game, the event related to the first character may be an event in a confrontation scene between the two characters.

In particular, by combining multiple first characters, events occur according to the combination, resulting in a very wide variety of events. That is, if a user selects and combines r characters from the n characters they own, the number of combinations is expressed as n!/{(n-r)!r!}. For example, if a user selects three characters from the 10 characters they own and sets them as first characters, there are 120 possible combinations, and by changing the combination of characters set as first characters, the user can expect a variety of events to occur according to the combination.

In addition, when multiple first characters are combined, an event may be generated according to the relationship between the multiple first characters. Alternatively, an event may be generated according to the relationship between multiple characters, including multiple first characters and a second character. An example is shown below.

Example 1: If characters A and B are rivals in the game, by setting both characters A and B as the first characters for event occurrence, it can be expected that an event of a confrontation scene will (might) occur (or the user can imagine an event that could occur).

Example 2: If characters P, Q, and R are classmates at the same school in the game, then by setting these three characters P, Q, and R as the first characters for event generation, it is expected that an event will (might) occur in which the three go on a trip together. Furthermore, if characters P, Q, and R and a second character are classmates at the same school, then by setting these three characters P, Q, and R as the first characters for event generation, it is expected that an event will (might) occur in which the four of them, including the second character, go on a trip together.

Although an event will not necessarily occur, if the user knows the parameters, characteristics, relationships with other first characters, relationships with second characters, etc., of each first character, the user can have fun imagining or anticipating events that may occur depending on the first character or combination of multiple first characters set for event occurrence.

The effects of an event occurring can also be determined as desired. For example, when an event occurs, the parameters of the user's My Character may change according to the progress or outcome of the event, or the user may be given an item or the like. Alternatively, the user may simply enjoy the event that has occurred, without any effects such as parameter changes.

As described above, in this configuration, the user collects characters for generating events, and arbitrarily selects one of the collected characters to set as the first character for generating an event, so that various events can occur during the game according to the first character or a combination of multiple first characters. Thus, the user can enjoy a variety of events according to the first character or combinations of first characters set for generating an event. For example, a user who is getting bored with a game can change the first character set for generating an event, which changes the events that occur during the game, making it possible to play the game without getting bored. In other words, in this game management device, the first character or combinations of multiple first characters that the user can arbitrarily set provide a wide variety of events that occur during the game. This broadens the scope of play, and makes it possible to realize a highly entertaining game that users can play repeatedly and continuously without getting bored.

2) In the above configuration, it is preferable that the event management means (72) generates the event corresponding to the first character or a combination of multiple first characters with a predetermined probability during the game.

The probability of an event occurring may be the same for all events, or may vary, for example 10%, 30%, 50%, 70%, etc., depending on the content, type, effect, etc. of the event. In addition, the probability of an event occurring during the game may vary depending on the user's game operation, as in configuration 4) described below.

In this configuration, just because a first character is set for event occurrence, it does not necessarily mean that an event related to that first character will occur 100% of the time; whether or not an event will occur is based on probability. Therefore, it is not known when an event will occur. Therefore, after a first character is set for event occurrence, the user will play the game with a sense of tension, hoping that an event related to the first character will occur. This configuration improves the playability of the game.

3) In the configuration of 2) above, it is preferable that the game system further includes a relationship management means (73) for managing the relationship between a second character operated by a user during the game and the first character, and a probability variation means (74) for varying the probability according to the relationship.

The second character operated by the user during the game is a so-called player character, and can be, for example, the user's alter ego, My Character. The relationship between the first character and the second character can be, for example, teammates, player and coach, player and manager, senior and junior, rivals, lovers, boss and subordinate, parent and child, siblings, etc. The degree of relationship between the first character and the second character can be, for example, the degree of intimacy between the two characters, or an evaluation value by which one character evaluates the other.

The relationship level between the first character and the second character may also have a preset initial value. As an example, the first character A and the second character are set to be best friends in the game, and the relationship level between them is set to "100." On the other hand, the first character B and the second character are set to be acquaintances in the game, and the relationship level between them is set to "10." The relationship level may also change during the game depending on the actions of the second character operated by the user, as in the configuration of 5) described below.

According to this configuration, the probability of an event related to a first character occurring (or the probability of an event occurring according to a combination that includes the first character) varies depending on the relationship between the first character and the second character. For example, the higher the relationship level (the intimacy level, the evaluation value, etc.), the higher the probability of an event occurring.

As an example, when the relationship level between the first character and the second character is "39 or less", "40-79", "80-119", "120-159", "160-199", and "200 (maximum)", the probability of the event occurring varies as follows, respectively: "10%, "20%, "30%, "50%, "70%, "100%". When there is only one first character, the event occurrence probability in the above example can be applied as is. On the other hand, when there are multiple first characters set for event occurrence, various methods can be considered for determining the probability of the event occurring according to the combination of multiple first characters. An example is shown below.

When the relationship levels between all of the first characters (A, B, etc.) and the second character satisfy a predetermined standard (condition), the probability of an event occurring according to the satisfied relationship standard is applied. For example, the probability of an event occurring is 10% until all of the set first characters satisfy a predetermined relationship standard (e.g., "40 or higher"), and when that standard is satisfied, the probability of the event occurring becomes 20%. When all of the first characters satisfy an even higher relationship standard (e.g., "80 or higher"), the probability of the event occurring becomes 30%. Similarly, the probability of the event occurring increases each time all of the first characters satisfy an even higher relationship standard.

Alternatively, the probability of an event occurring according to a combination of multiple first characters may be determined by using the first character with the highest relationship level among the multiple first characters. Or, conversely, the first character with the lowest relationship level may be used, in which case the user is motivated to try to raise the level of the relationship.

Alternatively, the probability of an event occurring in response to a combination of multiple first characters may be determined by calculating the average relationship degree between the multiple first characters and based on the average relationship degree.

It is preferable that the relationship between each first character and second character is visible to the user on the screen. This allows the user to check the relationship between the first character and the second character on the screen when setting a first character for event occurrence or during game progress, and enjoy playing the game while recognizing the relationship. For example, when the user sees on the screen that the relationship with a certain first character is high, the user will have a higher sense of expectation that there is a high probability that an event related to that first character will occur.

With this configuration, the likelihood of an event occurring changes depending on the relationship between the first character and the second character set for the event occurrence, or the relationship between the first character and the second character after the first character is set. Therefore, if a user wants an event to occur quickly, the user can play the game so that the relationship between the first character they set and the second character, which is the character they control, is large, thereby making the game more enjoyable.

4) In the configuration of 3) above, it is preferable that the game further comprises a character appearance management means (75) for making the first character appear in the game, and the relationship degree management means (73) changes the relationship degree between the first character and the second character each time the second character performs a predetermined action with the first character through a user's operation.

Here, "predetermined action" refers to various in-game actions, such as the second character practicing, competing, eating, playing with the first character, or being in the same place together. In this configuration, the first character set by the user for an event occurrence appears in the game. Then, when the second character operated by the user performs a predetermined action such as practicing with the first character in the game, the relationship between the two (the intimacy level, the evaluation value, etc.) improves, and the probability of an event related to the first character (or an event corresponding to the combination when the first character is included in the combination) occurring increases.

Note that by setting the first character to generate an event, there is a certain probability that an event related to the first character will occur, as described above, even if the second character does not perform a specified action with the first character. In addition, in this configuration, the user can operate the second character to perform a specified action with the first character, thereby intentionally increasing the probability of an event occurring.

Therefore, if a user wishes to increase the probability of an event occurring related to a specific first character, the user need only perform game operations (such as operations to select an action for the second character in the game) so that the second character will perform a predetermined action with the first character. With this configuration, the user can vary the probability of an event occurring related to a specific first character through their own operations, further improving the playability of the game.

5) In the configuration of 1) above, it is preferable that the game further comprises a character management means (75) for making the first character appear in the game, and a relationship management means (73) for varying the relationship between the first character and the second character each time the second character performs a predetermined action with the first character through a user's operation, and that the event management means (72) generates the event related to the first character when the relationship between the first character and the second character reaches a predetermined standard.

In this configuration, the first character set by the user for event occurrence appears in the game. Then, when the second character operated by the user performs a predetermined action in the game with the first character (such as practicing together), the relationship between the two (the intimacy level, the evaluation value, etc.) changes. Then, after the relationship level with a certain first character reaches a predetermined standard, an event related to the first character occurs (100% occurrence). Here, the timing of the event occurrence may be such that the event occurs immediately after the relationship level reaches the predetermined standard, or may occur after a certain amount of time has passed after the relationship level reaches the predetermined standard (for example, after the timing of the event occurrence in the game is adjusted). As an example of the adjustment of the timing of the event occurrence in the game, the following case is considered. That is, in a game in which the game progresses divided into multiple turns, if the relationship level between the first character and the second character reaches a predetermined standard during the execution of a command in a certain turn, an event related to the first character is generated by waiting until the start of the next turn.

The case where the relationship level does not reach a predetermined standard can be determined arbitrarily. For example, if the relationship level between a first character and a second character does not reach a predetermined standard, an event related to the first character may occur with a probability according to the relationship level (or with a predetermined probability regardless of the relationship level). Alternatively, if the relationship level between a first character and a second character does not reach a predetermined standard, an event related to the first character may not occur.

If there is one first character set for an event to occur, then of course the event will occur when the relationship between the first character and the second character reaches a certain standard (as a trigger).

On the other hand, when there are multiple first characters set for event occurrence, various modes are possible. An event corresponding to a combination of multiple first characters (A, B...) can be set to occur when the relationship between all of the first characters (A, B...) and the second character reaches a predetermined standard. Alternatively, an event corresponding to a combination of multiple first characters (A, B...) may be set to occur when the relationship between any one of the first characters and the second character reaches a predetermined standard. Alternatively, an event corresponding to a combination of multiple first characters (A, B...) may be set to occur when the relationship between a predetermined percentage or more (e.g., 50% or more) of the first characters and the second characters reaches a predetermined standard.

In this configuration, if a user wants to ensure that an event related to a specific first character occurs, the user only needs to perform game operations (such as operations to select an action for a second character in the game) so that the relationship with the first character reaches a predetermined standard. With this configuration, the user can ensure that an event related to a specific first character occurs 100% through their own operations, further improving the playability of the game.

6) In any of the configurations 1) to 5) above, it is preferable that the device further includes a settable number management means (76) that sets an upper limit on the settable number of the first character and varies the upper limit on the settable number by satisfying a predetermined condition.

According to this configuration, an upper limit is set on the number of first characters that can be set for event occurrence. For example, at the start of the game, the upper limit of the number that can be set is "2." However, the upper limit of the number that can be set changes depending on whether certain conditions are satisfied. Here, examples of the certain conditions include the following:

(a) As in the configuration of 7) described below, the predetermined condition is that a game parameter related to the game progress satisfies a preset condition.

(b) In order to increase the upper limit of the settable number, a specified condition is that the user consumes a specified amount of in-game points, in-game currency, paid items, etc.

(c) In a game in which a user can build a specific relationship with other users, such as a companion relationship, a specific condition is that the number of companions reaches a specific number.

(d) The specified condition is when the game execution result does not reach a specified standard. For example, in a game in which a player can develop a character, if the user stops developing the character midway, the upper limit of the number that can be set is lowered.

Note that the above (a) to (d) are examples of predetermined conditions and are not limited to these, and various conditions can be set depending on the content of the game.

In this configuration, while an upper limit is set for the number of first characters that can be set, the user can increase that upper limit by satisfying certain conditions. The higher the upper limit for the number of first characters that can be set, the greater the variety of events that can occur during the game. Thus, the user is motivated to actively play the game in order to increase the upper limit for the number that can be set (or to prevent the upper limit from decreasing) and to satisfy certain conditions.

7) In the configuration of 6) above, it is preferable that the satisfaction of the predetermined condition means that a game parameter related to the progress of the game satisfies a preset condition.

Here, an example of a game parameter related to the game progress is the number of characters that have been trained in a game in which multiple characters can be trained. In this case, the specified condition is satisfied when the number of characters that have been trained reaches a specified value (e.g., 1, 5, 10, etc.). Other examples of game parameters related to the game progress include various game parameters that can be applied according to the game content, such as stage, points, level, etc. For example, reaching a specified stage, acquiring points reaching a specified value, the user's game level reaching a specified level, the user's personal character level reaching a specified level, etc., fall under "a game parameter related to the game progress satisfying a preset condition."

In this configuration, the user is motivated to actively play the game so that game parameters related to the game's progress satisfy preset conditions.

8) In any of the configurations 1) to 7) above, it is preferable to further include a notification means (80) that notifies the user of information indicating the relationship between the event and the first character or a combination of multiple first characters that causes the event to occur. Here, examples of notification by the notification means are shown below.

(A) The user is notified (presented) in advance of information indicating the relationship between the effect of an event, such as an improvement in parameters, and the first character or a combination of multiple first characters required to trigger the event. For example, if the parameters of the user's My Character change as the effect of an event, the user is notified in advance of information regarding the first character or combination of first characters required to improve the parameters. Taking a baseball game as an example, the user is notified that "in order to trigger an event that strengthens hitting power, it is sufficient to set one of the characters P, Q, R, etc. (which have high hitting power)."

(B) The user is notified in advance of information indicating the relationship between the type or content of the event and the first character or combination of multiple first characters required to generate the event. Examples of the type or content of the event include a joint practice event, a duel event, a travel event, a meal event, etc. These are just a few examples, and the type or content of the event varies depending on the game content. For example, the user is notified that "in order to generate a duel event, it is sufficient to set character X (who is a rival of the user's My Character)."

In either case (A) or (B) above, the user may be presented with detailed table information showing all relationships, or only parts of it may be presented randomly to attract the user's interest. When this information is presented, the user is motivated to try to cause a desired event (and thereby cause a desired effect) and to obtain the characters required for that purpose.

In addition, in both cases (A) and (B) above, only information relating to the characters owned by the user may be extracted and presented to the user as information indicating the relationship. In this case, users (especially novice users who do not know much about what events will occur if they set their own characters to generate events) can be motivated to actively enjoy the game.

9) In any of the above configurations 1) to 8), it is preferable that the device further comprises a parameter variation means (79) for varying the parameters of the second character according to the progress or outcome of the event occurring during the game.

This configuration has the effect of causing the parameters of the second character to vary depending on the progress or results of events that occur during the game. For example, in the case of a baseball game, the second character's specific parameters, such as batting ability, running ability, and defensive ability, improve, or acquire special ability parameters. As one example, the result of an event related to first character A improves the batting ability of the second character by a predetermined amount (or a predetermined percentage). Also, the result of an event related to first character B improves the running ability of the second character by a predetermined amount (or a predetermined percentage). Note that even if an event that has occurred is not completed to the end, or is not cleared, it is also possible to cause the parameters to vary depending on the progress of the event.

In this configuration, the parameters of the second character (such as the user's My Character) change as a result of each event. The effect of parameter change also changes depending on the event that occurs. Therefore, by devising the combination of first characters that the user sets, the user can cause various events to occur and strengthen the abilities and other parameters of the second character. This configuration can further improve the playability of the game.

10) In the configuration of 9) above, it is preferable that the content of the change in the parameter of the second character is related to the parameter of the first character.

For example, if a first character is a player with excellent hitting ability (hitting ability parameters higher than a predetermined standard), when an event related to that first character progresses or is completed, the second character will be influenced by the specific parameters of the first character (in this case, hitting ability) and will have the same improved hitting ability. With this configuration, the user can generate various events by devising combinations while taking into account the parameters of the first character set for event generation, thereby evenly improving the parameters of the second character or strengthening specific parameters. This configuration can further improve the playability of the game.

11) In the configuration of 9) or 10) above, it is preferable that a rarity is set for each of the multiple characters owned by the user, and the parameter variation means (79) varies the parameters of the second character to a greater extent in accordance with the progress or result of the event that occurs in accordance with the first character, the higher the rarity of the first character that is set for event occurrence.

According to this configuration, a rarity level is set in advance for each character. Rarity levels can be expressed in various ways, such as "1, 2...", "A, B...", "gold, silver...", "normal, rare...", etc. For example, each character is set to one of the multiple levels of rarity: "normal", "rare", or "S rare". In this example, the same character A exists in three rarity levels: normal, rare, and S rare.

The higher the rarity of the first character set to cause an event to occur, the greater the effect of the event that occurs in response to the first character. In other words, when an event occurs in response to the first character because the first character has been set to cause an event to occur, the higher the rarity of the first character, the greater the fluctuations in the parameters of the second character in response to the progress or outcome of the event. For example, the higher the rarity of the first character, the greater the ability parameters of the second character.

With this configuration, the higher the rarity of the first character set for event occurrence, the more advantageous the game can be played, enhancing gameplay. This also motivates the user to try to obtain a rarer character.

12) In any of the configurations 1) to 11) above, it is preferable that the event that occurs in response to a combination of multiple first characters is an event based on the relationship between the multiple first characters.

The relationship between multiple first characters can be, for example, rivals, best friends, parent and child, lovers, or any other relationship that is appropriate to the content of the game. For example, assume that character A and character B are rivals. When character A and character B are set for event occurrence, a showdown event occurs based on the relationship (rivalry) between the two characters as an event that corresponds to the combination of the two characters. In this case, the second character (such as the user's My Character) may participate in the event by witnessing or cheering on the showdown event.

In this manner, in this configuration, an event occurs based on the relationships between the multiple first characters that are set for event occurrence. Therefore, when a user wants to generate an event with specific content, such as a duel event, the user only needs to select multiple characters for event occurrence while considering the relationships between the characters. This configuration further improves game playability.

13) In any of the configurations 1) to 12) above, it is preferable that the device further comprises a relationship management means (77) for managing a second user associated with the user, and a permission means (78) for permitting the second user to set a specific character owned by the second user as the first character for the user's own event generation.

The game management device includes a relationship management means for managing second users such as peers associated with the user. Here, peers is a general term for virtual relationships between users that are established within the game, and includes various in-game relationships such as acquaintances, friends, classmates, buddies, relatives, family, brothers, sisters, and colleagues in a company or organization. Note that other users (second users) associated with the user do not necessarily have to be in a peer relationship. However, in the following explanation, second users will be referred to as peers for the sake of convenience.

In this configuration, a specific character owned by the user's friend (second user) can be set as the user's first character for generating an event. In other words, there is a frame for setting the friend's character as a setting frame for the character for generating an event, and the user can borrow the friend's character and set it as the character for generating an event. Here, examples of a "specific character owned by a friend" can be one of the characters set by the friend for generating an event, or a character that the friend has preselected as a character that can be lent. Alternatively, the character with the highest ability among the characters owned by the friend may be automatically selected by the game management device as the specific character.

The number of slots in which a user can set a companion character may be one or multiple. For example, the upper limit of slots in which a companion character can be set may be varied depending on the number of companions. In other words, the more companions there are, the higher the upper limit of the slots may be.

As described above, in this configuration, a user can borrow a specific character owned by a friend and set it as the user's own character for generating an event, even if the user does not own the character. In this case, the more friends a user has, the wider the range of characters they can choose from, making it possible for a variety of events to occur. With this configuration, each user is motivated to actively make many friends. And as each user's friends increase, the community between users is revitalized, which in turn revitalizes the game as a whole.

14) In any of the configurations 1) to 13) above, a rarity is set for each of the multiple characters owned by the user, and it is preferable that the higher the rarity of the first character set for event occurrence, the greater the number of events that may occur during the game.

According to this configuration, a rarity level is set in advance for each character. For example, one of the rarity levels "normal," "rare," or "S rare (highest)" is set for each character. Then, the number of events that can occur during the game differs depending on the rarity level of the first character that is set for event occurrence.

Here, an example will be explained in which there is one first character set for event occurrence. If the rarity of the first character is "normal (lowest)", the number of events that can occur is, for example, "1". If the rarity of the first character is "rare", the number of events that can occur is, for example, "2". If the rarity of the first character is "S rare (highest)", the number of events that can occur is, for example, "3". As in this example, the higher the rarity of the first character, the greater the number of events that can occur during the game.

Similarly, when multiple first characters are set to cause an event to occur, the number of events that may occur depending on the combination of some or all of the multiple first characters may be increased as the rarity of those characters increases.

With this configuration, the higher the rarity of the first character set for event occurrence, the greater the variety of events that can occur during the game, and the more engaging the game becomes. This in turn motivates the user to try to obtain characters with higher rarity.

15) In any of the configurations 1) to 14) above, it is preferable that the game is a game based on a predetermined scenario with a second character operated by a user, and the event occurs additionally within the scenario.

Here, a "predetermined scenario" in a game refers to a game story that unfolds as the game progresses, and can include various elements related to the game story, such as the roles of the characters appearing in the game, dramatic effects during the game, and choices within the game. Taking a baseball game as an example, the predetermined scenario can be a story that begins in the summer of the second year of high school and ends with the protagonist being a professional baseball player, with the second character operated by the user as the protagonist. Within such a scenario, an event occurs additionally in response to a first character or a combination of multiple first characters that are set for event occurrence. In other words, the predetermined scenario is the main scenario of the game, and the events do not change the main scenario itself, but are game elements that occur additionally within the main scenario.

16) A game system according to another aspect of the present invention includes a game server (201) and a terminal device (203) that communicates with the game server (201), and either the game server (201) or the terminal device (203) is provided with a setting means (71) that sets at least one character selected by a user from among a plurality of characters owned by the user as a first character for event generation, and an event management means (72) that generates an event related to the first character during the game in accordance with the first character or a combination of a plurality of the first characters.

17) A game management method according to another aspect of the present invention is a game management method in a computer that manages a game, and includes a setting step in which the computer sets at least one character selected by a user from a plurality of characters owned by the user as a first character for generating an event, and an event management step in which the computer varies an event that occurs during the game according to the first character or a combination of the first characters.

18) A program according to another aspect of the present invention is a program for causing a computer to operate as a game management device (3, 201, 203) described in any one of 1) to 15) above, and for causing the computer to function as each of the means provided in the game management device (3, 201, 203).

According to the present invention, the first character or combination of multiple first characters that can be set by the user can be used to increase the variety of events that occur during the game. This increases the scope of play, and allows for the realization of a highly entertaining game that users can play repeatedly and continuously without getting bored.

1 is an explanatory diagram showing an example of the configuration of a game system according to an embodiment of the present invention; FIG. 2 is a block diagram showing an example of a hardware configuration of the game device. FIG. 1 is a block diagram showing an example of the software configuration of a game server. 1 is a conceptual diagram showing the occurrence of various events from the start to the end of a scenario. FIG. 13 is an explanatory diagram showing an example of an event deck setting screen. FIG. 13 is an explanatory diagram showing an example of a character selection screen for event occurrence. A conceptual diagram showing an example of the relationship between the characters incorporated in the event deck and the events that can occur. FIG. 2 is a functional block diagram showing an example of a basic functional configuration of the game device. FIG. 4 is an explanatory diagram showing an example of user information. FIG. 2 is a functional block diagram showing an example of a main configuration of the game management device. FIG. 13 is a functional block diagram showing another example of the main configuration of the game management device. FIG. 13 is an explanatory diagram showing an example of event deck setting information. 13 is an explanatory diagram showing an example of relationship information indicating a relationship between a combination of first characters and an event. FIG. FIG. 13 is a functional block diagram showing another example of the main configuration of the game management device. 11 is an explanatory diagram showing an example of the relationship between the relationship degree between characters and the probability of an event occurring. FIG. FIG. 13 is a functional block diagram showing another example of the main configuration of the game management device. FIG. 13 is a functional block diagram showing another example of the main configuration of the game management device. FIG. 13 is an explanatory diagram showing another example of the event deck setting screen. FIG. 13 is a functional block diagram showing another example of the main configuration of the game management device. FIG. 13 is a functional block diagram showing another example of the main configuration of the game management device. 11 is an explanatory diagram showing an example of a correspondence relationship between a first character and an event. FIG. 13 is a flowchart showing an example of the operation of the game device. FIG. 13 is a block diagram showing another example configuration of the game system. FIG. 2 is a functional block diagram showing an example of the main configuration of a game server. FIG. 13 is a block diagram showing another example of the configuration of the game system.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS A game system, a game management device, a game management method, and a program according to an embodiment of the present invention will be described below with reference to the drawings.
[Game System Overview]

An example of the configuration of a game system according to one embodiment of the present invention is shown in FIG. 1. As shown in the figure, this game system is composed of a game server 1 installed on a network 4 such as the Internet, and each user's game device 3 that can be connected to the game server 1 via the network 4 so as to be able to communicate with it.

The network 4 in this embodiment is not limited to the Internet, but may be, for example, a dedicated line, a public line (telephone line, mobile communication line, etc.), a wired LAN (Local Area Network), a wireless LAN, etc., as long as it can connect the game server 1 and each user's game device 3 to each other so that they can communicate with each other, or it may be a combination of these with the Internet.

In this example of a game system, a game management device according to an embodiment of the present invention can be configured as a game device 3. Alternatively, a game management device according to an embodiment of the present invention can be configured as a game server 1, or as a game server 1 and a game device 3 that communicate with each other. Below, an example in which the game management device is configured as a game device 3 will first be described, and other configurations will be described later.

The game device 3 can be any information processing device capable of executing a game program. For example, the game device 3 can be a stationary or portable game console, a personal computer (hereinafter referred to as a "PC"), a tablet computer, a smartphone, a mobile phone terminal, a PHS (Personal Handy-phone System) terminal, a portable information terminal (PDA: Personal Digital Assistant), a multi-function television receiver with information processing capabilities (so-called smart TV), etc.

The game server 1 accepts access via the network 4 from the game device 3 of each user who receives the game service, stores and manages each user's game information in a storage device such as a database, and provides each user with the game service via the network 4. For example, the game server 1 provides a service of additionally delivering game scenario information to each user's game device 3. The game server 1 also provides users with a service of in-game interaction between users (e.g., sending messages, etc.). The game server 1 also provides services such as matching between users when each user plays a game in online mode (e.g., a network battle game, etc.).

The game device 3 is capable of running the game in either online mode or offline mode.

The game device 3 as a game management device according to an embodiment of the present invention has a function of increasing the variety of events that occur during a game. A user can collect characters for generating events and construct an event deck by selecting any of the collected characters. Then, depending on a single character or a combination of multiple characters incorporated in the event deck, an event related to the character can occur during the game. By changing the characters incorporated in the event deck, different events can occur, so that the variety of events is increased and the user can repeatedly play the game without getting bored. The following describes in detail the configuration of the game device 3 as a game management device according to this embodiment that realizes this.
[Game Device Configuration]

As mentioned above, the game device 3 operated by the user can be a variety of devices, such as a dedicated game console, a PC, a smartphone, or a mobile phone terminal, but the basic configuration required to play the game, such as displaying the game screen and performing input operations to run the game, is the same for all of them.

Figure 2 shows an example of the configuration of the game device 3. As shown in the figure, the game device 3 mainly comprises a CPU (Central Processing Unit) 31, a ROM (Read Only Memory) 32 and a RAM (Random Access Memory) 33 as main storage devices, an image processing unit 34, a display unit 35, a sound processing unit 36, an audio input unit 37, an audio output unit 38, an auxiliary storage device 39, an operation input unit 40, a communication control unit 41, a decoder 42, and a recording medium drive 43. The components 31 to 34, 36, and 39 to 42 are connected to each other via a bus line 44. Note that interface circuits are interposed between the bus line 44 and each component as necessary, but the interface circuits are not shown here.

The CPU 31 interprets and executes commands from various programs such as the game program and the web browser, and controls the entire game device 3. The ROM 32 stores programs and the like necessary for basic operational control of the game device 3. The RAM 33 stores various programs and data loaded from the ROM 32, the auxiliary storage device 39, or the recording medium drive 43, and ensures a working area for the CPU 31. Various programs such as the game program and the web browser are stored in the ROM 32 or the auxiliary storage device 39, and are loaded into the RAM 33 and executed by the CPU 31. When a screen is displayed using a web browser, various plug-in software for expanding the browser functions of the web browser may be stored in the ROM 32 or the auxiliary storage device 39 together with the web browser.

The image processing unit 34 drives the display unit 35 based on an image display command from the CPU 31, and causes the display unit 35 to display an image on its screen. The display unit 35 can be any of a variety of known display devices, such as a liquid crystal display or an organic EL (Electro-Luminescence) display. Note that the display unit 35 does not need to be integrated with the game device 3, and may be, for example, a television monitor externally connected to the game device 3.

The sound processing unit 36 converts an analog audio signal into a digital audio signal when audio is input from the audio input unit 37, and generates an analog audio signal based on a sound output instruction from the CPU 31 and outputs it to the audio output unit 38. The audio input unit 37 consists of a microphone built into or external to the game device 3. The audio output unit 38 outputs sound effects and the like during game execution, and consists of a speaker built into or external to the game device 3.

The auxiliary storage device 39 is a storage device that stores the various programs and data described above. For example, a hard disk drive, a flash memory drive, a memory card reader/writer, etc. can be used as the auxiliary storage device 39.

The operation input unit 40 accepts operation input from the user and outputs an input signal corresponding to the operation input to the CPU 31 via the bus line 44. Examples of the operation input unit 40 include physical buttons such as direction buttons, a decision button, and an alphanumeric character input button provided on the main body of the game device 3. Alternatively, the operation input unit 40 may be a controller externally connected to the main body of the game device 3. In addition, in the case of a game device 3 in which the display unit 35 is configured as a so-called touch screen by mounting a touch panel (a contact input type interface) on the screen of the display unit 35, the touch panel also serves as the operation input unit 40.

In addition, a configuration may be adopted in which the CPU 31 analyzes the voice input from the voice input unit 37 using general voice recognition technology, allowing various inputs to be made by voice.

The communication control unit 41 includes a communication interface 41a and has a communication control function for data communication during game operation, etc. Here, the communication control function for data communication includes, for example, a wireless LAN connection function, an Internet connection function via a wireless LAN or a mobile phone network, and a short-range wireless communication function using a specific frequency band (for example, a 2.4 GHz frequency band). The communication control unit 41 transmits a connection signal for connecting the game device 3 to a wireless LAN or the Internet, etc., based on an instruction from the CPU 31, and also receives information transmitted from the communication partner and supplies it to the CPU 31.

Examples of the recording medium drive 43 include a DVD-ROM drive, a CD-ROM drive, a hard disk drive, an optical disk drive, a flexible disk drive, a silicon disk drive, and a cassette medium reader. In this case, examples of the recording medium 45 include a DVD-ROM, a CD-ROM, a hard disk, an optical disk, a flexible disk, and a semiconductor memory.

The recording medium drive 43 reads image data, audio data, and program data from the recording medium 45, and supplies the read data to the decoder 42. The decoder 42 performs error correction processing using ECC (Error Correction Code) on the data reproduced from the recording medium drive 43, and supplies the error-corrected data to the RAM 33, etc.

The game device 3 may also be provided with a GPS (Global Positioning System) signal receiving circuit, an imaging device (camera) such as a CCD (Charge Coupled Device) image sensor, a three-axis acceleration sensor, and the like.
[Game server configuration]

Figure 3 shows an example of the hardware configuration of the game server 1. As shown in the figure, the game server 1 mainly comprises a CPU 11, a ROM 12 and RAM 13 as main memory devices, an auxiliary memory device 14, a communication control unit 15, and an input/output control unit 16, which are interconnected via a bus line 17 including an address bus, a data bus, a control bus, etc. Note that interface circuits are interposed between the bus line 17 and each component as necessary, but are not shown here.

The CPU 11 interprets and executes commands from system software and application software such as game programs, and controls the entire game server 1. The ROM 12 stores programs and other necessary for basic operational control of the game server 1. The RAM 13 stores various programs and data, and ensures a working area for the CPU 11.

The auxiliary storage device 14 is a storage device that stores game programs, various data, and the like. For example, a hard disk drive can be used as the auxiliary storage device 14. As described below, the game server 1 can also be used as a game management device. In this case, a program for operating the game server 1 (computer) as a game management device is stored, for example, in the auxiliary storage device 14, and the program is loaded from the auxiliary storage device 14 to the RAM 13 via the bus line 17 when the game server 1 is started, and is executed by the CPU 11.

The communication control unit 15 has a communication interface 15a that is connected to the network 4, and controls communication between each user's game device 3 via the network 4.

The input/output control unit 16 is connected to, for example, the database server 2 so as to be able to communicate with the database server 2, and performs input/output control when the CPU 11 reads and writes data (records) from and to the database server 2.

The database server 2 is equipped with a large-capacity hard disk device with a RAID (Redundant Arrays of Inexpensive Disks) configuration as a storage device having an area for storing game information of each user managed by the game server 1. This database server 2 can be constructed as a relational database, object database, object relation database, or the like that stores various game information of each user (user name, level, in-game points, owned items, etc.) in association with identification information (user ID) that uniquely identifies each user.

The game server 1 may have the function of the database server 2, and the database may be configured inside the game server 1. The functions of the game server 1 may also be distributed among multiple servers, and the game server 1 may be configured as multiple servers. For example, when a user operates the game device 3 to access the game server 1, an authentication server having an authentication function for determining whether the user is a legitimate user may be provided separately from the main server of the game server 1, and the game server 1 may be configured from the main server and the authentication server. As another configuration example, a billing management server that performs billing management when a user purchases an item for which a bill is required in the game may be provided separately from the main server of the game server 1, and the game server 1 may be configured from the main server, authentication server, and billing management server.

Furthermore, when the number of users using the game service reaches hundreds of thousands, millions, or even more, it becomes necessary to build a server system that can withstand a huge amount of access from the game devices 3 of many users, so a load-distribution type system configuration may be achieved by providing multiple game servers 1 on the network 4 for redundancy (multiplexing). In this case, it is desirable to provide a load balancer for adjusting the load among the multiple game servers 1.
[Game Overview]

Examples of games executed by the game device 3 of this embodiment as an example of a game management device include sports games based on baseball, soccer, tennis, American football, basketball, volleyball, etc., adventure games, simulation games, training games, role-playing games, and various other games regardless of game format or genre. As an example, in this embodiment, the case where the game device 3 mainly executes a baseball game will be described below.

The baseball game of this embodiment has a game mode in which the player has the main character practice and train the main character (the user's own character) while progressing through a predetermined scenario, thereby completing a unique original character. The "predetermined scenario" in the game refers to the game story that unfolds as the game progresses, and can include various elements related to the game story, such as the roles of the characters appearing in the game, dramatic effects during the game, and choices within the game.

One example of a scenario in this baseball game can be the following general game story, in which a main character operated by a user begins the summer of his second year of high school and becomes a professional baseball player. For example, the main character belongs to the baseball team of a prestigious high school, but is overwhelmed by the high level of his teammates and is unable to become a regular player at first. The main character practices with his teammates at this high school, wins a regular spot, and participates in baseball games (national tournaments, etc.). If the main character receives a certain level of evaluation from a scout from a professional baseball team who observes his practice and games, he will be scouted as a professional baseball player. The main character operated by a user is an example of a second character.

In this game, the development of the main character is completed when one scenario is completed. Once the development of the main character is complete, it can be used in another game mode as an original character. After the scenario is completed, the main character can be developed again by starting the scenario from the beginning.

Alternatively, multiple scenarios may be prepared in advance, allowing the user to select any scenario. To increase the variety of scenarios, the game device 3 may be able to download additional scenarios from the game server 1. For example, new scenarios may be provided from the game server 1 on a regular basis (such as once a month).

An example of the progression of the above-mentioned scenario is shown below. The period in the game from the start to the end of the scenario is, for example, 50 weeks (a virtual period in the game). In the game, multiple commands are provided for selecting the main character's in-game actions. Examples of commands include "practice", "rest", and "go out". By executing a practice command, the main character's ability parameters can be improved. On the other hand, by executing a practice command, the stamina parameter decreases. By executing a rest command, for example, the main character's stamina parameter increases. By executing a go out command, for example, the main character's motivation parameter can be improved. Each time the user executes any command, for example, one week of virtual time in the game passes. That is, in this example game, there are a total of 50 turns from the start to the end of the scenario, and one week of virtual time in the game passes for each turn, and the scenario progresses.

As shown in FIG. 4, various events occur between the start and end of the scenario. The timing at which an event may occur can be determined arbitrarily. For example, in each turn from the start to the end of the scenario, an opportunity for an event to occur may be provided at the time when the user selects a command, at any time during the execution of the command, when the command ends, etc. For example, at each of the aforementioned times, a lottery may be held with a predetermined probability to determine whether or not an event will occur. Alternatively, an event may be set that will always occur when the game progresses to a certain level, without relying on a lottery. For example, if the scenario progresses to 10, 20, or 30 turns, a predetermined event (such as a match event) scheduled at those times may occur 100% of the time.

However, in this game, the events that occur are not fixed, and various additional events can occur depending on the individual characters or combinations of characters that the user includes in the event deck.

Figure 5 shows an example of an event deck setting screen. This screen has an event deck setting area 101. In the screen of Figure 5, the event deck setting area 101 has three character setting frames (so-called slots) 102, and an example is shown in which the characters of player A and player B are set in two of the setting frames 102. In this example, the event deck is organized by the characters of player A and player B. The characters of player A and player B set in the event deck setting area 101 are an example of first characters for event generation. Hereinafter, the characters incorporated in the event deck will be referred to as "first characters" as necessary.

The characters that can be set in the event deck setting area 101 are basically characters owned by the user. The user can select any character from among the multiple characters that he or she owns. Here, the characters owned by the user can be displayed in various forms within the game, such as two-dimensional or three-dimensional images, or card-type images. In this embodiment, as an example, the characters owned by the user are in card format. In other words, the characters owned by the user are managed by the game device 3 as digital cards and are displayed on the game screen.

When a character is set in the event deck setting area 101 by the user, the character will then appear in the game. Characters that appear in the game may be depicted by two-dimensional or three-dimensional computer graphics during practice, matches, various events, etc. within the game. In this example game, characters that the user can own include teammate players, baseball club managers, and ordinary people (e.g., town residents). In this way, characters may be managed by dividing them into multiple categories such as "players," "managers," and "ordinary people." Furthermore, if the character owned by the user is a person, incorporating the character into the event deck will make the character a character in the game, so characters owned (or available for ownership) by the user may be referred to as "character characters," "character units," "character cards," etc.

Note that the characters that appear in the scenario (for example, one coach, one scout, one manager, and four to eight teammates) will appear in the game even if you do not set the characters in the event deck setting area 101. If you set a character in the event deck setting area 101, that character will be added as a character.

An example of the operation for setting a character in a setting frame 102 on the event deck setting screen is shown below. By selecting the setting button 103 corresponding to a setting frame 102 in which no character has been set (a so-called empty slot) (or by directly selecting the setting frame 102), a character selection screen for event generation, as shown in the example in FIG. 6, is displayed. This character selection screen displays a list of multiple characters currently owned by the user. The user selects a character they wish to include in the event deck from the list of characters.

To change a character included in the event deck, select the change button 104 (or directly select the setting frame 102 in which the character is set). This will display the character selection screen for event generation, as shown in FIG. 6, allowing you to reselect the character. To remove a character from the event deck, select the setting frame of the character you want to remove and perform the required setting cancellation operation.

Each character that can be set in the setting slot of the event deck has its own unique event. Then, depending on the single character or combination of characters that the user has included in the event deck, a unique event can occur during the game. The event that can occur here is an event related to the first character included in the event deck.

Events related to the first character that are incorporated into the event deck include, for example, events in which the character acts alone (e.g., practicing, eating, drawing fortunes, etc.). Other examples of events related to the first character include events in which the first character acts together with other characters (e.g., practicing, eating, traveling, etc.). In particular, events in which the first character acts together with the main character are preferred.

Note that an event related to a first character is not limited to an event in which the first character appears on the screen. For example, it may be an event in which a quiz related to the first character is asked. It may also be an event in which other characters related to the first character (friends, seniors, juniors, coaches, rivals, etc.) talk about the first character, or an event in which the first character's rival practices to beat the first character.

An example of the relationship between the first character built into the event deck and the events that can occur is shown in the conceptual diagram in Figure 7. In Figure 7, the left side of the "=" (equal) sign is the first character built into the event deck, and the right side is the event that can occur.

For example, if a user includes a "Player A" character in an event deck, an "Event A" related to the "Player A" character may occur. One example of Event A could be an event in which the Player A character does special training. Another example of Event A could be an event in which, in a character setting in which the main character and Player A are friendly teammates, the main character and Player A character do special training together or eat a meal together.

In addition, if a user includes a "Player B" character in an event deck, an "Event B" corresponding to "Player B" may occur. One example of Event B could be an event in which the main character faces off against the character of Player B in a character setting in which the main character and Player B are rivals.

For example, if a user incorporates both characters "Player A" and "Player B" into an event deck, an "Event C" corresponding to the combination of "Player A" and "Player B" may occur. An example of Event C is an event in which the character of Player A and the character of Player B face off against each other in a character setting in which Player A and Player B are rivals. For example, in this face-off event, the main character as the second character may participate in the event by witnessing or cheering on the face-off event. In this case, not only "Event C" but also the aforementioned "Event A" and "Event B" may occur. In other words, when both characters "Player A" and "Player B" are incorporated into an event deck, all three patterns of "Player A", "Player B", and "Player A" + "Player B" are valid, and all of "Event A", "Event B", and "Event C" may occur.

For example, if a user incorporates three characters, "Player C," "Player D," and "General E," into an event deck, an "Event D" corresponding to the combination of these three characters may occur. One example of Event C could be an event in which the characters "Player C" and "Player D" confess their feelings to the "General E" character, in a character setting in which "General E" is a potential lover for "Player C" and "Player D." For example, in this event, the main character may also participate in the event by confessing their feelings to the "General E" character.

For example, if a user incorporates three characters, "Player A," "Player B," and "Player D," into an event deck, an "Event E" corresponding to the combination of these three characters may occur. An example of Event D is an event in which the characters "Player A," "Player B," and "Player D" hold a training camp. For example, in this training camp event, the main character may also participate in the training camp.

The events mentioned above are just a few examples, and various events can occur depending on the character or combination of characters included in the event deck.

When a character is added to an event deck by a user, the event may be guaranteed to occur, or may occur with a certain probability, or may occur only when certain conditions are met.

Preferably, an event corresponding to the first character or a combination of multiple first characters incorporated into the event deck occurs with a predetermined probability during the game. In this case, whether or not an event occurs is based on probability, and the timing at which the event will occur is unknown. Therefore, after a first character is incorporated into the event deck, the user plays the game with a sense of tension, hoping for an event related to that first character to occur.

In addition, it is preferable to vary the probability of the event occurring according to the relationship between the main character, who is the second character operated by the user, and the first character incorporated in the event deck. The relationship between the main character and the first character may be, for example, the intimacy between them, or an evaluation value by which one character evaluates the other. This relationship may be predetermined, or may vary during the game depending on the actions of the main character operated by the user. Preferably, the relationship between the two is varied each time the main character performs a predetermined action with the first character through the user's operation. For example, the relationship between the two improves when the main character practices or plays together with the first character. This allows the user to increase the probability of an event occurring related to a specific first character through their own operation.

In addition, when the relationship between the main character and a certain first character incorporated in the event deck reaches a predetermined standard, an event related to that first character may occur 100%. Here, the timing of the event occurrence may be such that the event occurs immediately after the relationship reaches the predetermined standard, or the event may occur a certain amount of time after the relationship reaches the predetermined standard (for example, after the timing of the event occurrence in the game is adjusted). As one example, if the relationship between the main character and Player A's character reaches a predetermined standard during command execution in a certain turn of the scenario, an event related to Player A's character will occur at the end of that turn or the start of the next turn.

The case where the relationship level does not reach a predetermined standard can be determined arbitrarily. For example, if the relationship level between the main character and the first character does not reach a predetermined standard, an event related to the first character may occur with a probability according to the relationship level (or with a predetermined probability regardless of the relationship level). Alternatively, if the relationship level between the main character and the first character does not reach a predetermined standard, an event related to the first character may not occur 100% of the time.

It is possible to not set an upper limit on the number of first characters that can be set to organize an event deck, but it is preferable to set an upper limit. It is also preferable to vary the upper limit of the settable number by satisfying a specified condition. One example of satisfying a specified condition is when a game parameter related to the progress of the game satisfies a pre-set condition. In this game, the development of the main character is completed with the end of one scenario, so the number of characters that have completed development can be one example of the game parameter. In other words, the specified condition is satisfied when the number of characters that have completed development reaches a specified value (e.g., 1, 5, 10, etc.), and the upper limit of the settable number is increased.

In addition, the setting slots 102 on the event deck setting screen may be increased by a predetermined number (e.g., by consuming a paid item) by making a payment. Alternatively, the number of setting slots 102 may be increased by setting the predetermined condition that the user consumes a predetermined amount of in-game points, in-game currency, etc.

Alternatively, if the user stops character development midway, the upper limit of the number of settings that can be made for the first character may be lowered (the number of setting slots 102 may be reduced). Also, if the character's parameters do not reach predetermined values even after the character development is completed, the upper limit of the number that can be made may be lowered.

In addition, the upper limit of the number of first characters that can be set may be changed by satisfying various other conditions.

In addition, in this game, users can build peer relationships with other users. Here, peers is a general term for virtual relationships built between users within the game, and includes various in-game relationships such as acquaintances, friends, classmates, buddies, relatives, family, brothers, sisters, and colleagues in a company or organization. Note that other users (second users) who are associated with the user do not have to be in a peer relationship.

If the user has companions, the event deck setting screen may be configured to add a setting frame (which may be called a friend frame, helper frame, etc.) in which companion characters can be set. Details will be given later.

In addition, when an event occurs during the game, various effects can be generated depending on the progress or outcome of the event. One example of such an effect may be for the main character's parameters to change, or for the user to be given an item or the like. Alternatively, the user may simply enjoy the event that has occurred, without any effect such as parameter change occurring.

In order for a user to incorporate a character into an event deck, the user must obtain the character. There are several ways to obtain a character. For example, the user can obtain a character by lottery by executing a lottery mode. In this lottery mode, a character to be given to the user is selected by lottery from all characters in the game. In order for the user to execute the lottery mode, for example, a predetermined amount of in-game points, paid items, etc. may be required. In addition, the user can receive a character as a gift from another user (friend, etc.). In addition, the user can obtain a character as a reward for playing in the game. For example, the user can play against other users using multiple characters that he or she has trained, and compete for rankings in the game. Here, users who rank high in the rankings are given a character as a reward. In addition, a predetermined number of characters (for example, five) may be given to the user at the start of the game.

In addition, each character that the user can own is preset to a rarity level. In this game, each character is set to one of the rarity levels "normal", "rare", and "S rare". Here, "normal" is the lowest rarity level, and "S rare" is the highest rarity level. Therefore, for example, for the character of player A, there are three types of rarity levels: "normal", "rare", and "S rare". For example, the user may obtain a "normal" character in lottery mode, or a "rare" or "S rare" character. As illustrated in FIG. 6, in this embodiment, the rarity of a character is indicated by the number of stars, with "normal" being one star, "rare" being two stars, and "S rare" being three stars.

When a user acquires a character that is identical to a character that the user already owns (with the same character name and rarity), the game device 3 automatically executes a merging process to combine the two characters. When this merging process is executed, a merging effect is displayed on the screen. This merging process increases the level of the combined character from "Lv1" to "Lv2". When merging of the same character is repeated and the level of the character reaches a predetermined level (e.g. Lv100), the rarity of the character increases by one and the level is reset to "Lv1". For example, if a user who owns the character of Player A (normal, Lv99) acquires the character of Player A (normal, Lv1), the merging process results in the user owning the character of Player A (rare, Lv1).

In this game, even if the characters have the same name, if their rarity is different, the fusion process will not be performed. The above-mentioned fusion process is an example, and is not limited to this. For example, the fusion process may be performed based on an operation by the user, rather than being performed automatically. Also, it may be possible to allow characters of different rarities to be fused together. Also, it may be possible to allow different characters to be fused together.

The user can incorporate characters of any rarity, "normal," "rare," or "S rare," into the event deck. The higher the rarity of the first character incorporated into the event deck, the higher the effect of the event related to that first character is preferably made. For example, the higher the rarity of the first character, the greater the fluctuations in the main character's parameters will be depending on the progress or outcome of that event. Details will be provided later.

Furthermore, the higher the rarity of the first character incorporated into the event deck, the more events that can occur during the game (events related to that first character) should preferably be increased. Details on this will be provided later.

The timing at which a user can set or change an event deck can be determined as desired. For example, an event deck may be allowed to be set only before the start of a scenario. Alternatively, an event deck may be allowed to be set before the start of a scenario, and changed after the start of a scenario.

When the event deck is permitted to be changed after the start of the scenario, the user may be allowed to change the event deck any number of times at any timing, or the timing or number of changes may be limited. For example, the event deck is permitted to be changed only three times during the progress of the scenario (for example, the 10th turn, the 20th turn, and the 30th turn). In this case, it is preferable that the CPU 31 of the game device 3 displays a message such as "Would you like to change the event deck here?" on the screen at the timing when the event deck change is permitted, to inform the user that the event deck can be changed. In addition, when the event deck is permitted to be changed after the start of the scenario, a predetermined condition (for example, the user executes the lottery mode to obtain a new character) may be required to be satisfied.
[Functional configuration and operation of the game device]

Next, we will explain an example of the functional configuration of the game device 3 as a game management device that realizes the above game.

Figure 8 is a functional block diagram showing an example of the basic configuration of the game device 3.

The game device 3 according to this embodiment includes an input management means 51, an execution means 52, an output management means 53, a character management means 54, a user information management means 55, a communication management means 56, an exchange management means 57, etc. Each of these means is realized by the CPU 31 of the game device 3 executing a program according to this embodiment.

The input management means 51 understands input signals from the operation input unit 40 operated by the user and outputs them to the execution means 52. The execution means 52 executes calculations and data processing based on the user's operation input, etc. In this game, processing such as progression of the scenario, execution of commands, and execution of events is performed. Information on the results of processing executed by the execution means 52 is stored in a specified area of the storage device (RAM 33, auxiliary storage device 39, etc.). The output management means 53 outputs image information (still image or video) of the execution result by the execution means 52 to the display unit 35 via the image processing unit 34, and outputs audio information of the execution result to the audio output unit 38 via the sound processing unit 36.

The character management means 54 has a function of managing all characters in the game. Each character is assigned a character ID that uniquely identifies it, and each character is managed by its character ID. Ability parameters and rarity are predefined for each character. Examples of ability parameters for a batter character include hitting, power, trajectory, running ability, arm strength, and defensive ability. Examples of ability parameters for a pitcher character include pitch speed, control, stamina, curveball, and defensive ability. Information on each character (character database) is read from the auxiliary storage device 39 or recording medium 45 and stored in the RAM 33.

The user information management means 55 stores and manages information related to the user's game in a storage device (RAM 33, auxiliary storage device 39, etc.). Figure 9 shows an example of information related to the user's game managed by the user information management means 55 (in this example, information for one person with user ID = 000001). The user information management means 55 stores the user's basic information, character information, item information, point information, companion information, interaction history, etc. in the storage device.

The basic information of a user includes a user ID, password, and user name. The user ID and password are used when accessing the game server 1 in online mode.

The character information includes information on characters currently owned by the user (characters that can be incorporated into the event deck), information on main character characters being trained, and information on original characters whose training has been completed. As information on characters currently owned by the user, a character ID is stored. Character information corresponding to this character ID is managed by the character management means 54. As information on main character characters being trained, for example, parameter information such as hitting, power, trajectory, running ability, shoulder strength, defensive ability, stamina, and motivation is stored. If some or all of the main character's parameters are changed as a result of a command or event being executed during the game, the parameter information is updated to the changed information. As information on original characters whose training has been completed, a character ID and parameter information at the time of training completion are stored.

Item information and point information is information about items and points currently owned by the user.

Friend information is information about friends associated with a user, and the friend's user ID is stored in correspondence with the user ID. Furthermore, interaction history is information about the history of interactions a user has had with other users (friends, etc.) within the game. This interaction history includes information about the type of interaction, the person involved, and the time. Types of interactions include greetings, sending messages, presents, chat, etc. The user ID of the person involved is stored as information about the person involved.

The communication management means 56 has a function of managing information communication between the user's game device 3 and the game server 1, or between the user's game device 3 and another user's game device 3, via the communication control unit 41 in the online mode or online battle mode.

The interaction management means 57 realizes the interaction and communication between users within the game. The interaction management means 57 of the user's game device 3 transmits and receives interaction information with other users' game devices 3 via the game server 1 (or directly without going through the game server 1). The interaction information includes messages that the user creates for the other users, information on characters or items to be given as presents to the other users, etc.

Next, the main functional configuration of the game device 3 will be described with reference to the functional block diagram of FIG. 10 and the like. As shown in FIG. 10, the game device 3 as a game management device mainly includes a setting means 71 and an event management means 72. Each of these means is realized by the CPU 31 of the game device 3 executing a program according to this embodiment.

The setting means 71 has a function of setting at least one character selected by the user from among a plurality of characters owned by the user as the first character for event generation. In this embodiment, as described above, on the event deck setting screen exemplified in FIG. 5, the user performs an operation of selecting an arbitrary character from among a plurality of characters owned by the user and setting the character in the setting frame 102. When character selection information is input by this operation, the setting means 71 stores the character ID of the selected character in the storage device (RAM 33 or auxiliary storage device 39, etc.) as setting information for the first character for event generation. Hereinafter, this setting information is referred to as "event deck setting information".

Figure 12 shows an example of event deck setting information. In Figure 12, three setting frames 102 of the event deck are active, and two of the setting frames 102 are set with two first characters, Player A (S rare) with character ID = 2001 and Player B (rare) with character ID = 1002. Note that in Figure 12, information fields are provided for the name and rarity of the character corresponding to the character ID, but these information fields can be omitted. This is because the name and rarity of the character are specified by the character ID. Also, in Figure 12, an information field for the relationship degree is provided, but this will be described later.

The event management means 72 has a function of generating an event related to the first character during the game according to the first character or a combination of multiple first characters incorporated in the event deck. For example, as shown in FIG. 13, relationship information indicating the relationship between the combination of first characters and the event is stored in advance in a storage device (such as RAM 33). This relationship information is saved, for example, in the recording medium 45 or the auxiliary storage device 39, and is loaded during the game and stored in RAM 33. Then, the event management means 72 manages the events to be generated during the game based on the relationship information.

Each event is assigned an event ID that uniquely identifies it. When an event with a certain event ID occurs during a game, the event execution program corresponding to that event ID is executed by the CPU 31.

In the relationship information of FIG. 13, if the first character incorporated into the event deck has a character ID of 0001, the corresponding event is an event called "batting training" with an event ID of 0001. If the first character has a character ID of 0002, the corresponding event is an event called "defensive training" with an event ID of 0002. If the first character has a character ID of 0003, the corresponding event is an event called "base running training" with an event ID of 0003.

If the first characters built into the event deck have character IDs 0001 and 0002, the event corresponding to this combination is the "Confrontation" event with event ID 0101. If the first characters have character IDs 0001 and 0003, the event corresponding to this combination is the "Quiz" event with event ID 0102.

If the first character has a character ID of 0001, 0002, or 0003, the event corresponding to this combination is an event called "Batting Center" with an event ID of 0501. If the first character has a character ID of 0001, 0002, or 0004, the event corresponding to this combination is an event called "Play Together" with an event ID of 0502. In addition, various other events are available depending on the combination of a single first character or multiple first characters that make up the event deck.

As mentioned above, if the first characters set as an event deck have character IDs of 0001 and 0002, for example, three valid combinations of first characters can be made: "0001," "0002," and "0001+0002." In this case, events that may occur include "batting training" with event ID = 0001, "defensive training" with event ID = 0002, and "showdown" with event ID = 0101.

Similarly, if the first characters set as an event deck have character IDs of, for example, 0001, 0002, and 0003, the following seven combinations of first characters can be valid: "0001", "0002", "0003", "0001+0002", "0001+0003", "0002+0003", and "0001+0002+0003".

The events that the event management means 72 generates during the game are events related to the first character, as described above. For example, "Strike training" with event ID = 0001 is an event in which the character with character ID = 0001 incorporated in the event deck conducts strike training alone or together with the main character. Note that, as described above, events related to the first character are not limited to events in which the first character appears on the screen.

In addition, when a first character or multiple first characters are set for event occurrence, the event management means 72 may ensure that an event occurs, or may ensure that an event occurs with a predetermined probability, or may ensure that an event occurs when a predetermined condition is met.

In addition, the event related to the first character can be an event related to the parameters (characteristic parameters) of the first character. For example, if the first character is a character with excellent specific abilities (the parameters of the specific abilities are higher than a predetermined standard), the event related to the first character can be an event related to the specific abilities (utilizing the specific abilities). As a specific example, if the first character is a player with excellent batting abilities (the parameters of the batting abilities are higher than a predetermined standard), the event related to the first character can be an event related to batting, such as batting training or a home run contest.

The event related to the first character can be an event related to the relationship between the first character and the main character. For example, if the first character and the main character are rivals in the game, the event related to the first character can be an event in a confrontation scene between the two characters.

In particular, by combining multiple first characters, events occur according to the combination, resulting in a very wide variety of events. In other words, if a user selects and combines r characters from the n characters they own, the number of combinations is expressed as n!/{(n-r)!r!}. For example, if a user selects three characters from the 10 characters they own and sets them as first characters, there are 120 possible combinations, and by changing the combination of first characters incorporated into the event deck, the user can expect a variety of events to occur according to the combination.

In addition, when multiple first characters are combined, an event may occur according to the relationship between the multiple first characters. Alternatively, an event may occur according to the relationship between multiple characters, including the main character, among the multiple first characters. An example is shown below.

Example 1: If characters A and B are rivals in the game, then by including both characters A and B in the event deck, it is expected that a confrontation scene event will (might) occur (or the user can imagine an event that could occur).

Example 2: If characters P, Q, and R are classmates at the same school in the game, then by incorporating these three characters P, Q, and R into an event deck, it is expected that an event will (might) occur in which the three of them go on a trip together. Furthermore, if characters P, Q, and R are classmates at the same school with a second character, then by setting these three characters P, Q, and R as the first characters for event generation, it is expected that an event will (might) occur in which the four of them, including the second character, go on a trip together.

Although an event may not necessarily occur, if the user knows the parameters, characteristics, relationships with other first characters, and relationships with the main character for each first character, the user can have fun imagining or anticipating events that may occur based on the first character or combination of multiple first characters incorporated into the event deck.

The effects of an event occurring can also be determined as desired. For example, when an event occurs, the parameters of the user's My Character may change according to the progress or outcome of the event, or the user may be given an item or the like. Alternatively, the user may simply enjoy the event that has occurred, without any effects such as parameter changes.

As described above, in the configuration of this embodiment, a user collects characters for generating events, and can arbitrarily select one of the collected characters to set as a first character for generating an event, which allows various events to occur during the game according to the first character or a combination of multiple first characters. Thus, the user can enjoy a variety of events according to the first character or combinations of first characters set for generating events, while experimenting with building an event deck. For example, a user who is getting bored with a game can change the first character set for generating an event, which changes the events that occur during the game, allowing for gameplay that never gets boring.

The game of this embodiment is a game based on a predetermined scenario with a main character as a second character operated by the user. Therefore, as shown in FIG. 11, the game device 3 is equipped with a scenario progression means 70. This scenario progression means 70 has a function of progressing a predetermined scenario with the main character based on the user's operation of game progression (command selection operation in this game). The events that the event management means 72 generates according to the event deck occur additionally within the scenario. In other words, the predetermined scenario is the main scenario of the game, and the events according to the event deck do not change the main scenario itself, but are game elements that occur additionally within the main scenario (see FIG. 4).

In the main scenario of the game, pre-prepared basic events (such as match events) may occur periodically or randomly, regardless of the event deck. In this case, the basic events may occur while the scenario is progressing, even if no characters are set as an event deck. In this case, if the user sets at least one first character as an event deck, there is a possibility that an event corresponding to the event deck will additionally occur as a special event not included in the basic events.

However, the games to which the present invention can be applied are not limited to games that proceed according to a scenario. For example, in the case of a baseball game in which the user controls a player character to perform batting and defense, there is no predetermined scenario. In such a game, if the user sets at least one coach character in the event deck, additional events may occur during the game in which the coach gives tips on batting as events corresponding to the event deck.

Next, a preferred example of generating an event according to an event deck with a predetermined probability will be described. The event management means 72 of this embodiment has a function of generating the event according to the first character or a combination of multiple first characters incorporated in the event deck with a predetermined probability during the game. Here, the probability of generating an event may be the same for all events (e.g., 20%). Alternatively, the occurrence probability may be different, for example, 10%, 30%, 50%, 70%, etc., depending on the content, type, effect, etc. of the event. Alternatively, the relationship between the main character and the first character may change depending on the user's game operation, and the occurrence probability of the event may vary during the game (details will be described later).

Alternatively, the probability of an event occurring may vary depending on the progress of the scenario. For example, the probability of an event occurring may be different before the progress of the scenario reaches a specified value (50%) than thereafter. As one example, the probability of an event occurring may be 10% before the progress of the scenario reaches 50%, and 20% thereafter. This is an example in which an event that did not occur in the first half of the scenario is made more likely to occur in the second half of the scenario. Conversely, events may be made more likely to occur in the first half of the scenario and less likely to occur in the second half of the scenario.

In this configuration, just because a first character is set for event occurrence, it does not necessarily mean that an event related to that first character will occur 100% of the time; whether or not an event will occur is based on probability. Therefore, it is not known when an event will occur. Therefore, after a first character is set for event occurrence, the user will play the game with a sense of tension, hoping that an event related to the first character will occur. This configuration improves the playability of the game.

Next, a preferred configuration for varying the probability of an event occurring depending on the relationship between the main character and the first character will be described. As shown in FIG. 14, in addition to a setting means 71 and an event management means 72, the game device 3 preferably further includes a relationship management means 73 and a probability variation means 74.

The relationship management means 73 has a function of managing the relationship between the main character, which is an example of a second character operated by the user during the game, and the first character incorporated in the event deck. The relationship between the main character and the first character can be, for example, teammates, player and coach, player and manager, senior and junior, rivals, lovers, boss and subordinate, parent and child, siblings, etc. The relationship between the main character and the first character can be, for example, the intimacy between the two, or an evaluation value by which one evaluates the other.

In this embodiment, the relationship level is described as being a numerical value between 0 and 200. Note that the relationship level may be expressed as a level such as "A, B..." instead of a numerical value.

The relationship degree between the main character and the first character may be set to a preset initial value. As an example, the main character and player A (an example of a first character) are set as best friends in the game, and the relationship degree between them is set to "100." On the other hand, the main character and player B (an example of a first character) are set as acquaintances in the game, and the relationship degree between them is set to "10." In addition, the relationship degree between the main character and manager C (an example of a first character) is set to "50."

It is also preferable that the relationship degree varies during the game depending on the actions of the main character operated by the user. That is, the game device 3 further includes a character appearance management means 75 that causes the first character incorporated in the event deck to appear in the game. Then, the relationship degree management means 73 varies the relationship degree between the first character and the main character each time the main character performs a predetermined action with the first character through the user's operation. Here, "predetermined action" refers to various in-game actions, such as the main character practicing, competing, eating, playing with the first character, or being together in the same place. In this way, when the main character performs an action in the game that has a predetermined relationship with the first character, the relationship degree between the two changes.

For example, if the main character practices with a first character, such as a teammate, the relationship level increases by "10". Also, for example, if the main character eats with the first character, the relationship level increases by "5". Also, for example, if the main character competes against the first character and wins, the relationship level (evaluation value) increases by "10", whereas if the main character loses, the relationship level decreases by "5". These are just a few examples, and the correspondence between the main character's actions and the relationship levels can be determined as desired.

An example of relationship management by the relationship management means 73 is shown below. As shown in FIG. 12, an information field for relationship is provided in the event deck setting information. Then, the relationship management means 73 updates the value of the relationship information field each time the relationship between the first character and the main character set as the event deck changes, and manages the current relationship.

The probability varying means 74 has a function of varying the probability of an event related to the first character occurring (or the probability of an event occurring according to a combination that includes the first character) according to the relationship between the main character and the first character. FIG. 15 shows an example of the relationship between the relationship and the event occurrence probability. In this example, when the relationship is "39 or less", "40 to 79", "80 to 119", "120 to 159", "160 to 199", and "200 (maximum)", the event occurrence probability varies to "10%, "20%, "30%, "50%, "70%, and "100%", respectively. In this example, the higher the relationship value (or the higher the level), the more gradually the event occurrence probability is improved.

When there is one first character set as an event deck, the event occurrence probability in FIG. 15 can be applied as is. On the other hand, when there are multiple first characters set as an event deck, the occurrence probability of an event corresponding to a combination of multiple first characters can be calculated, for example, as follows. Here, an example is shown in which the characters of player A and player B are incorporated into an event deck. For example, suppose that the relationship degree between the main character and player A is "100", and the relationship degree between the main character and player B is "50". In this case, based on the relationship in FIG. 15, an event occurrence probability of 30% can be obtained from the relationship degree of player A, and 20% can be obtained from the relationship degree of player B. Therefore, the occurrence probability of an event corresponding to the combination of player A + player B can be averaged to be (30% + 20%) / 2 = 25%.

There are various other possible ways to determine the probability of an event occurring depending on a combination of multiple first characters. An example is shown below.

When the relationship levels between all of the first characters (A, B, etc.) and the second character satisfy a predetermined standard (condition), the probability of an event occurring according to the satisfied relationship standard is applied. For example, the probability of an event occurring is 10% until all of the set first characters satisfy a predetermined relationship standard (e.g., "40 or higher"), and when that standard is satisfied, the probability of the event occurring becomes 20%. When all of the first characters satisfy an even higher relationship standard (e.g., "80 or higher"), the probability of the event occurring becomes 30%. Similarly, the probability of the event occurring increases each time all of the first characters satisfy an even higher relationship standard.

Alternatively, the probability of an event occurring according to a combination of multiple first characters may be determined based on the relationship between the relationship and the event occurrence probability illustrated in FIG. 15 by adopting the first character with the highest relationship degree among the multiple first characters. Alternatively, the character with the lowest relationship degree may be adopted, in which case the user is motivated to raise the level of the relationship degree.

Alternatively, the probability of an event occurring in response to a combination of multiple first characters may be determined by applying the average value of the relationship degrees of the multiple first characters and based on the relationship between the relationship degrees and the event occurrence probability as illustrated in FIG. 15.

It is preferable that the relationship between each character and the main character be visible to the user on the screen. This allows the user to check the relationship between the first character and the main character on the screen when setting a first character for an event to occur or during the course of the game, and enjoy playing the game while recognizing the relationship. For example, if the user sees on the screen that the relationship with a certain first character is high, this increases the user's sense of expectation that there is a high probability that an event related to that first character will occur.

An example of screen display control in the game device 3 that allows the user to visually confirm the relationship level is shown below. The game is provided with a screen that displays the current game status (progression of the scenario, etc.) and parameters of the main character. A list of characters owned by the user (all owned characters including characters set as event decks) is displayed on this screen, or on another screen transitioned from this screen. The relationship level with the main character is displayed for each character included in this list so that it can be visually confirmed. For example, the relationship level is divided into six levels (see FIG. 15), and the level of the relationship level is indicated by the number of stars (1 to a maximum of 6). Alternatively, the value of the relationship level itself (a value ranging from 0 to 200 in the example of FIG. 15) may be indicated. Among the characters included in the list, characters set as event decks are given information (marks, letters, colors, shading, etc.) that can confirm this fact. Therefore, by looking at the screen, the user can confirm which characters are set as event decks and the level of the relationship between the characters and the main character.

Alternatively, the relationship between each currently set character and the main character may be displayed visibly on the event deck setting screen exemplified in FIG. 5 or FIG. 18.

With this configuration, the likelihood of an event occurring changes depending on the relationship between the first character set for event occurrence and the main character, or the relationship between the first character and the main character after it is set. Therefore, if a user wants an event to occur quickly, they can play the game so that the relationship between the first character they set and the second character, which is the character they control, is large, which can make the game more enjoyable.

Note that by setting the first character as the character for event occurrence, there is a certain probability that an event related to the first character will occur, as described above, even if the main character does not perform a specific action with the first character. In addition, in this configuration, the user can operate the main character to perform a specific action with the first character, thereby intentionally increasing the probability of an event occurring.

Therefore, if a user wishes to increase the probability of an event occurring related to a specific first character, the user need only perform game operations (such as operations to select an action for the main character in the game) so that the main character will perform a predetermined action with the first character. With this configuration, the user can vary the probability of an event occurring related to a specific first character through their own operations, further improving the playability of the game.

Furthermore, it is preferable that the event management means 72 generates an event related to the first character 100% when the relationship between the first character and the main character set as an event deck reaches a predetermined standard. For example, as shown in FIG. 15, when the relationship reaches "200", the event generation probability is set to 100%.

Here, the timing of the event occurrence may be such that the event occurs immediately after the relationship level reaches a predetermined standard (e.g., 200), or the event may occur after a certain amount of time has passed since the relationship level reached the predetermined standard (e.g., after the timing of the event occurrence in the game has been adjusted).

Note that cases where the relationship level does not reach a predetermined standard can be determined arbitrarily. For example, if the relationship level between the main character and the first character does not reach the predetermined standard of "200", an event related to the first character may occur with a probability according to the relationship level, as illustrated in FIG. 15. Alternatively, if the relationship level does not reach a predetermined standard, an event may occur with a predetermined probability regardless of the relationship level. Alternatively, if the relationship level between the main character and the first character does not reach a predetermined standard, an event related to the first character may not occur.

If there is one first character set for an event to occur, then of course, when the relationship between that first character and the main character reaches a certain standard (as a trigger), the event will occur 100%.

On the other hand, if there are multiple first characters set to cause an event to occur, various configurations are possible, as shown below.

An event corresponding to a combination of multiple first characters (A, B, etc.) can be set to occur 100% when the relationship between all first characters included in that combination and the main character reaches a predetermined standard.

Alternatively, an event corresponding to a combination of multiple first characters (A, B, etc.) may occur 100% when the relationship between any one of the first characters and the second character reaches a predetermined standard.

Alternatively, an event corresponding to a combination of multiple first characters (A, B, etc.) may occur 100% of the time if the relationship between a certain percentage or more of the first characters and second characters (e.g., 50% or more) reaches a certain standard.

In this configuration, if a user wants to ensure that an event related to a specific first character occurs, the user only needs to perform game operations (such as operations to select the actions of the main character in the game) so that the relationship level with the first character reaches a predetermined standard. With this configuration, the user can ensure that an event related to a specific first character occurs 100% through their own operations, further improving the playability of the game.

Next, a configuration for varying the upper limit of the number of first characters that can be set as an event deck depending on various conditions will be described. As shown in FIG. 16, the game device 3 of this embodiment includes a settable number management means 76 in addition to a setting means 71 and an event management means 72. This settable number management means 76 has a function of setting an upper limit on the settable number of first characters and varying the upper limit of the settable number by satisfying certain conditions.

For example, at the start of the game, the upper limit of the number of first characters that can be set is "2." However, the upper limit of the number that can be set can be changed by satisfying certain conditions. Here, examples of the certain conditions are as follows:

(a) The predetermined condition is that the game parameters related to the game progress satisfy a preset condition. Details will be described later.

(b) In order to increase the upper limit of the settable number, a specified condition is that the user consumes a specified amount of in-game points, in-game currency, paid items, etc.

(c) In games in which users can build friendships with other users, such as the game of this embodiment, a predetermined condition is that the number of friends reaches a certain number. For example, when the number of friends reaches 30, the upper limit of the settable number increases by one, then increases by another at 40, and increases by another at 50 or more.

(d) The specified condition is when the game execution result does not reach a specified standard. For example, in a game in which a player can train a character, if the user stops training the character midway, the upper limit of the settable number is lowered. In addition, if the character's parameters do not reach a specified value even after the character's training is completed, the upper limit of the settable number is lowered.

Note that the above (a) to (d) are examples of predetermined conditions and are not limited to these, and various conditions can be set depending on the content of the game.

The settable number management means 76 manages the increase or decrease in the settable number of the first character, for example, by switching a flag set in the event deck setting information shown in FIG. 12 between enabled and disabled.

In this configuration, while an upper limit is set for the number of first characters that can be set, the user can increase that upper limit by satisfying certain conditions. The higher the upper limit for the number of first characters that can be set, the greater the variety of events that can occur during the game. Thus, the user is motivated to actively play the game in order to increase the upper limit for the number that can be set (or to prevent the upper limit from decreasing) and to satisfy certain conditions.

Next, a preferred embodiment will be described in which the "predetermined condition" for varying the upper limit of the settable number of first characters is that a game parameter related to the game's progress satisfies a preset condition. Here, an example of a game parameter related to the game's progress is the number of characters that have been trained in a game in which multiple characters can be trained, such as the game of this embodiment. In this case, the predetermined condition is satisfied when the number of characters that have been trained reaches a predetermined value (e.g., 1, 5, 10, etc.).

For example, at the start of a game before a scenario has even been started, the upper limit of the number of configurable first characters is "2". In this case, there are only two setting frames 102 in the event deck setting screen in FIG. 5. Thereafter, when the number of characters that have completed development becomes "1" due to the end of the scenario, the upper limit of the number of configurable first characters is changed to "3". As a result, the setting frames 102 in the event deck setting screen in FIG. 5 become three. Thereafter, when the number of characters that have completed development becomes "2" due to the end of the scenario, the upper limit of the number of configurable first characters is changed to "4", and the setting frames 102 become four. Thereafter, the upper limit of the number of configurable first characters may be increased each time the number of characters that have completed development increases, or, once the upper limit of the number of configurable first characters reaches a predetermined value (e.g., 5), the upper limit may not be increased any more (the number of setting frames 102 may not be increased).

Other examples of game parameters related to the game progress include various game parameters that can be applied depending on the game content, such as stage, points, and level. For example, reaching a specific stage, acquiring points reaching a specific value, the user's game level reaching a specific level, the user's My Character level reaching a specific level, etc., fall under "game parameters related to the game progress satisfying a preset condition."

The configuration of this embodiment motivates users to actively play the game so that game parameters related to the game's progress satisfy pre-set conditions.

Next, a preferred configuration will be described that allows a user to incorporate a friend's character into the user's event deck if the user has a friend. As shown in FIG. 17, a game device 3 with this configuration includes a setting means 71 and an event management means 72, as well as a friend management means 77 and a permission means 78 as examples of relationship management means.

The companion management means 77 has a function of managing companions as an example of a second user associated with a user. One form for a user to build a companion relationship with another user is when one of the two users makes a companion request to the other user via the game server 1, and the user who receives the companion request approves the companionship via the game server 1, in a companion request and approval operation between the two users. As exemplified in FIG. 9, the companion management means 77 stores the user IDs of other users who have companion relationships with the user as companion information and performs companion management.

The permission means 78 has a function of permitting a specific character owned by a friend to be set as the first character for the user's own event generation. Here, an example of a "specific character owned by a friend" can be one of the characters that the friend has set as an event deck. For example, in the event deck setting screen of FIG. 5, the character that the friend has set in the setting frame 102 on the left side (the character corresponding to setting frame ID=1 in FIG. 12) can be set as the "specific character owned by the friend."

Alternatively, a character that a friend has preselected as a character that can be lent may be set as the "particular character owned by the friend." Alternatively, the game device 3 may automatically select the character with the highest ability among the characters owned by the friend, and set that character as the "particular character owned by the friend."

For example, if a user has made a predetermined number of companions (e.g., one person) or more, the permission means 78 allows the companion's character to be set as an event deck. As a result, the event deck setting screen is provided with a helper frame 105 in which a companion's character can be set.

Figure 18 shows an example of an event deck setting screen with a helper slot 105. Figure 18 shows an example in which a total of six slots are provided: five normal setting slots 102 and one helper slot 105. When setting a companion character in the helper slot 105, for example, the user can select the helper slot 105 and transition to a helper selection screen (not shown). A list of companion characters is displayed on this helper selection screen, and by selecting any character from the list, the selected character can be set in the helper slot 105.

The user may have only one helper slot 105 in which a companion character can be set as an event deck, or may have multiple helper slots 105. For example, the number of helper slots 105 may vary depending on the number of companions associated with the user. In other words, the greater the number of companions, the more helper slots 105 in which companion characters can be set.

In the configuration of this embodiment, a user can borrow a specific character owned by a friend and set it as the user's own character for generating an event, even if the user does not own the character. In this case, the more friends a user has, the wider the range of characters they can select from, making it possible for a variety of events to occur. With this configuration, each user is motivated to actively make many friends. And as each user's friends increase, the community between users is revitalized, which in turn revitalizes the game as a whole.

Next, we will explain the effects and the like when an event occurs according to the event deck. When an event occurs, the user may simply enjoy the event that has occurred, but it is preferable to have a configuration in which the parameters of the main character are changed according to the progress or result of the event that has occurred. A game device 3 that realizes this configuration includes a parameter changing means 79 in addition to a setting means 71 and an event management means 72, as shown in FIG. 19.

The events corresponding to the event deck are preferably events related to the main character, which is an example of a second character operated by the user. Here, events related to the main character include, for example, the main character practicing, competing, eating, traveling, etc. with the first character. Note that events related to the main character are not limited to events in which the main character appears on the screen. For example, they may be events in which the first character talks about, thinks about, or imagines the main character, or events in which the first character, who is a rival of the main character, practices in order to beat the main character.

The parameter variation means 79 has the function of varying the parameters of the main character according to the progress or outcome of an event that occurs during the game and corresponds to the event deck.

For example, in the case of a baseball game, certain parameters of the main character, such as batting ability, running ability, and defensive ability, improve, or special ability parameters are acquired, depending on the progress or results of the event. As one example, as illustrated in FIG. 13, when the character of player A with character ID=0001 is set as an event deck, a batting training event occurs. In this event, for example, the main character and player A conduct batting training together. As a result of this event, the main character's batting ability (meet, power) parameters improve by a predetermined amount (or a predetermined percentage).

Also, as shown in the example of FIG. 13, when the character of player B with character ID=0002 is set as an event deck, a running ability training event occurs. In this event, for example, the main character and player B conduct running ability training together. As a result of this event, the running ability parameter of the main character increases by a predetermined amount (or a predetermined percentage).

The conditions for an event that changes the main character's parameters do not necessarily have to be an event related to the main character. For example, if the first character is a player with excellent batting ability, when an event related to the first character progresses or is completed, the main character's batting ability parameters may improve even if the main character himself does not appear in the event.

However, the main character's parameters (abilities, etc.) may change according to the progress or outcome of an event only when an event related to the main character as the second character occurs.

In addition, it is preferable to set a first character with a high predetermined ability (hitting power, running power, defensive power, etc.) as an event deck so that an event that improves the main character's ability occurs. For example, by setting any of first characters P, Q, R, etc. whose hitting power parameter is higher than a predetermined standard as an event deck, an event that can strengthen the main character's hitting power occurs. In addition, by setting more first characters P, Q, R, etc. whose hitting power parameter is higher than a predetermined standard as an event deck (two rather than one, three rather than two), an event that has a greater effect of strengthening hitting power occurs (the content of each event also differs). Similarly, by setting a character whose running power parameter is higher than a predetermined standard as an event deck, an event that can strengthen the main character's running power occurs.

In this way, it is preferable that the content of the change in the main character's parameters is related to the parameters of the first character. For example, if the first character is a player with excellent hitting ability (hitting ability parameters higher than a predetermined standard), when an event related to the first character progresses or is completed, the main character is influenced by a specific parameter of the first character (hitting ability in this case), and the main character's hitting ability improves to the same extent.

Even if the user does not complete an event that has occurred or does not clear the event, it is possible to vary the parameters according to the progress of the event.

In the configuration of this embodiment, the main character's parameters fluctuate as the effect of an event according to the event deck. The effect of parameter fluctuations also changes depending on the event that occurs. Therefore, by devising combinations while taking into account the parameters of the first character set as the event deck, the user can generate various events and improve the main character's parameters evenly or strengthen specific parameters. This configuration can further improve the playability of the game.

Next, a preferred configuration for varying the effect of an event according to the rarity of the first character set as the event deck will be described. As described above, in the game of this embodiment, one of the rarity levels "normal", "rare", and "S rare" is preset for each character. Note that the rarity level is not limited to three levels. For example, the rarity level may be five levels: "normal", "normal+", "rare", "rare+", and "S rare". Furthermore, the rarity level can be expressed in various ways, such as "1, 2...", "A, B...", "gold, silver...", etc.

The parameter variation means 79 has a function of varying the parameters of the main character to a greater extent depending on the progress or outcome of an event that occurs depending on the first character, the higher the rarity of the first character set as the event deck. For example, as a result of an event that occurs depending on the first character of player A (normal), the main character's hitting power becomes "+10". Also, as a result of an event that occurs depending on the first character of player A (rare), even if they have the same name, the main character's hitting power becomes "+20". Also, as a result of an event that occurs depending on the first character of player A (S rare), the main character's hitting power becomes "+30". In this way, even if the characters of player A have the same name, if the rarity is different, events with different contents will occur (or events with the same contents may occur), and the effects of the events will differ as described above.

With the configuration of this embodiment, the higher the rarity of the first character set as the event deck, the more advantageous it becomes to progress through the game, and the more engaging the game becomes. This in turn gives the user an incentive to try to obtain characters with higher rarity.

Next, we will explain a preferred configuration in which the higher the rarity of the first character set as the event deck, the greater the number of events that can occur during the game (events related to that first character).

Here, an example will be described in which there is one first character set as an event deck. FIG. 21 shows an example of the correspondence between the first character set as an event deck and events that may occur. In the example of FIG. 21, when a character of player A (normal) is set as an event deck, there is one event that may occur, "Strike Training 01". When a character of player A (rare) is set as an event deck, there are two events that may occur, "Strike Training 02" and "Strike Training 03". When a character of player A (S rare) is set as an event deck, there are three events that may occur, "Strike Training 04", "Strike Training 05", and "Strike Training 06". Note that this is just an example, and the number of events can be determined arbitrarily as long as the relationship that the higher the rarity of the first character, the greater the number of events that may occur during the game is established.

In the example of Figure 21, if three characters, Player A (Normal), Player A (Rare), and Player A (S Rare), are added to the event deck, any of the events "Strike Training 01" to "Strike Training 06" may occur.

Similarly, when multiple first characters are set as an event deck, the higher the rarity of some or all of the multiple first characters, the greater the number of events that may occur depending on their combination.

With the configuration of this embodiment, the higher the rarity of the first character set for event occurrence, the greater the variety of events that occur during the game, and the more engaging the game becomes. This in turn motivates the user to try to obtain characters with higher rarity.

Incidentally, it is preferable that an event that occurs in response to a combination of multiple first characters is an event based on the relationship between the multiple first characters. Here, the relationship between the multiple first characters can be, for example, rivals, best friends, parent and child, lovers, or various other relationships depending on the content of the game. For example, assume that character A and character B are rivals. Then, when character A and character B are set as an event deck, a showdown event occurs based on the relationship (rivalry) between the two characters as an event in response to the combination of the two characters. In this case, the main character may participate in the event by witnessing the showdown event or cheering them on.

In this way, events occur based on the relationships between multiple first characters that are set for event occurrence, so when a user wants to generate an event with a specific content, such as a duel event, the user only needs to select multiple characters to include in the event deck while considering the relationships between the characters. This configuration further improves the playability of the game.

Next, a configuration for notifying the user in advance of information indicating the relationship between an event and a character that will cause the event to occur will be described. As shown in FIG. 20, the game device 3 includes a setting means 71, an event management means 72, and a notification means 80.

The notification means 80 has a function of notifying the user of information indicating the relationship between an event and a first character or a combination of multiple first characters that causes the event. An example of notification by the notification means 80 is shown below.

(A) Information indicating the relationship between the effect of an event, such as an improvement in parameters, and the first character or a combination of the first characters required to generate the event is notified (presented) to the user in advance. For example, if the parameters of the main character change as an effect of an event, information regarding the first character or a combination of first characters required to improve the parameters is notified to the user in advance. In the example of a baseball game, information to the effect that "to generate an event that strengthens batting power, it is sufficient to set one of the characters P, Q, R, etc. (which have high batting power)" is displayed on the screen to notify the user. The notified information may be hint information that serves as a clue to the information indicating the relationship. For example, a notification may be made to the effect that "if you set character P, you may be able to strengthen your batting power in the event."

(B) Information (including the above hint-like information) indicating the relationship between the type or content of the event and the first character or combination of the first characters required to generate the event is notified to the user in advance. Examples of the type or content of the event include a training event, a duel event, a travel event, a meal event, etc. These are merely examples, and the type or content of the event varies depending on the game content. For example, information to the effect that "to generate a duel event, it is sufficient to set character X (who is a rival of the main character)" is displayed on the screen to notify the user. After the duel event, as described above, a predetermined effect (such as the main character's parameters improving or special abilities being acquired) may occur. Furthermore, the effect may also be notified.

In either case (A) or (B) above, the user can check the above information presented by the notification means 80 on the screen at any time by performing a predetermined operation on the game device 3.

In addition, in either case (A) or (B) above, the user may be presented with detailed table information showing all relationships, or only parts of it may be presented randomly to attract the user's interest. When this information is presented, the user is motivated to try to cause a desired event (thereby causing a desired effect) and to obtain the characters required for that.

In addition, in both cases (A) and (B) above, only information relating to the characters owned by the user may be extracted and presented to the user as information indicating the relationship. In this case, users (especially novice users who do not know much about what events will occur if they set their own characters to generate events) can be motivated to actively enjoy the game.

Here, an example of the operation of the game device 3 in this embodiment will be described below with reference to the flowchart in FIG. 22.

When the user operates the operation input unit 40 of the game device 3 to select any one of the multiple scenarios, the CPU 31 of the game device 3 determines the scenario to be executed (S1). Note that if there is only one scenario, step S1 can be omitted.

Then, the game device 3 executes an event deck setting process (S2). In this step S2, the game device 3 displays an event deck setting screen, as shown in FIG. 5, on the display unit 35. On this event deck setting screen, the user can select any characters from among the characters he or she owns and organize an event deck. The game device 3 sets at least one character selected by the user as the first character for event occurrence. As a result, for example, the event deck setting information shown in FIG. 12 is stored in the storage device (RAM 33, auxiliary storage device 39, etc.).

Note that the event deck setting process in step S2 may be performed before the scenario selection in step S1.

After the event deck is set as described above, the event deck setting information may be stored in a non-volatile storage device (such as the auxiliary storage device 39), and the event deck setting information may be retained until the user changes the character composition of the event deck. In this case, the user does not need to set up the event deck from scratch every time they start a scenario, and the previous event deck settings are carried over.

The characters that can be incorporated into the event deck may be limited according to the scenario selected in step S1. For example, in the case of a scenario set in a girls' high school, the characters that can be incorporated into the event deck are limited to female characters. Also, in the case of a scenario set in a school in a foreign country, the characters that can be incorporated into the event deck are limited to foreign characters. In this case, the user is motivated to obtain a character that corresponds to the scenario before starting the scenario.

The user can also start a scenario without setting any characters in the setting frame 102 of the event deck setting screen (i.e., there are zero characters in the event deck). In that case, however, no events corresponding to the event deck will occur. However, basic events unrelated to the event deck may occur.

After the scenario starts (S3), the user selects one of the commands, for example, "practice," "rest," or "go out" (S4), and progresses through the scenario. For example, the "practice" command has a variety of selectable subcommands, such as batting practice, baserunning practice, defensive practice, and strength training. For example, if the batting practice command is selected, the user practices with player A from the event deck, and if the baserunning practice command is selected, the user practices with player B from the event deck, and so on. The person with whom the user practices varies depending on the command selected.

After the user selects a command, the game device 3 executes a lottery process for an event (S5). The probability of an event occurring related to a first character incorporated in the event deck may vary according to the degree of relationship between the main character and the first character, for example, as shown in FIG. 15. If an event is won here (YES in S6), the game device 3 causes that event to occur (S7). If at least one first character is incorporated in the event deck, there is a possibility that an event related to that first character will occur. If multiple first characters are incorporated in the event deck, there will be more variations in the combinations of multiple first characters, and the possibility of an event occurring will also increase.

The game device 3 varies the parameters of the main character according to the progress or result of the event that has occurred. For example, the game device 3 improves the parameters of the main character, such as batting ability, running ability, and defensive ability. At this time, the game device 3 updates the parameters of the character being developed, as shown in FIG. 9, to the values after the variation (S8). Then, the process proceeds to step S9.

On the other hand, if no event has been won in step S6 (NO in S6), steps S7 and S8 are not executed, and the process proceeds to step S9. In this step S9, the command selected in step S4 is executed. If the parameters of the main character change as a result of the execution of the command, the game device 3 updates the parameters to the changed values (S10). Furthermore, if the main character performs a predetermined action (such as practice) with a first character incorporated in the event deck as a result of the execution of the command, the game device 3 also updates the relationship degree between the two (S11). As a result, for example, the relationship degree value in the event deck setting information in FIG. 12 is updated.

It is then determined whether the scenario has ended (S12). If the scenario has not ended (NO in S12), the process returns to step S4, and steps S4 to S12 are repeated until the scenario ends. When the scenario ends, the development of the main character is complete.

As described above, in the game device 3 of the present embodiment, the first character or a combination of multiple first characters that can be arbitrarily set by the user increases the variety of events that occur during the game. This increases the range of play, and realizes a highly entertaining game that the user can play repeatedly and continuously without getting bored.
[Other configuration examples of the game management device]

In the above embodiment, an example was shown in which the game management device was configured as a game device 3, but below, an example will be described in which the game management device is configured as a game server 201. Also, an example will be described in which the game management device is configured from multiple computers (servers, terminal devices) that communicate with each other. Note that the same component numbers are used for components similar to those shown in the previous drawings, and descriptions thereof will be omitted as appropriate.

An example of the configuration of a game system incorporating a game management device according to one embodiment of the present invention is shown in FIG. 23. As shown in the figure, this game system is composed of a game server 201 installed on a network 4 such as the Internet, and each user's terminal device 203 that can be communicatively connected to the game server 201 via the network 4.

The hardware configuration of the game server 201 is the same as that of the game server 1 in FIG. 3. The hardware configuration of the terminal device 203 is also the same as that of the game device 3 in FIG. 2.

The game server 201 accepts access via the network 4 from the terminal device 203 of each user who wishes to receive game services, stores and manages each user's game information in a database (storage device), and provides each user with game services via the network 4.

The game server 201 may provide a game service in such a manner that a game program (application software) is implemented in the game server 201, and instead of running the game on the terminal device 203, the game server 201 runs the game in response to game operation inputs on the terminal device 203, and transmits the results of the execution to each user's terminal device 203. For example, the game server 201 provides a so-called browser game in which the game can be played using a web browser installed on each user's terminal device 203. Alternatively, the game server 201 provides a so-called cloud gaming service in which game video resulting from running the game on the game server 201 is transmitted to the terminal device 203 in, for example, streaming format.

Alternatively, a game system can be created in which part or all of the game execution program is installed on the user's terminal device 203, and game execution processing is also performed on the terminal device 203.

For example, in a service form that provides a browser game, there is no need to download or install game-specific software on the user's terminal device 203, and as long as the user is in an environment where the terminal device 203 can be connected to the network 4, the user can easily enjoy the game service provided by the game server 201 anywhere.

In this game system, the game server 201 executes calculations and data processing for game progress in response to input operations on each user's terminal device 203. The game server 201 then updates each user's game information in the database based on the results of the calculations and other processing, and transmits webpage information (game screen data) to each user's terminal device 203 for displaying the results of the processing on the screen of the user's terminal device 203.

Each user's terminal device 203 is equipped with a web browser with a website browsing function as a user agent, and is capable of displaying web page information sent from the game server 201 on the screen of the terminal device 203. As this terminal device 203, various terminals that can connect to the game server 201 via the network 4 and receive game services can be applied, such as mobile phone terminals, PHS terminals, personal digital assistants (PDAs), smartphones, PCs, tablet computers, game devices with communication functions (fixed or portable game devices), or multi-function television receivers with two-way communication functions (so-called smart TVs).

The game server 201 and the terminal device 203 can communicate with each other to send and receive various data, and are both information processing devices (computers) equipped with a CPU, ROM, RAM, auxiliary storage device, communication control unit, etc., and have the same hardware configuration. Therefore, in a game system including the game server 201 and the terminal device 203, the means 71 to 80 equipped in the game device 3 described in each of the above embodiments may be equipped in either the game server 201 or the terminal device 203. In other words, the means 71 to 80 equipped in the game device 3 can be provided in the game server 201. Alternatively, the means 71 to 80 equipped in the game device 3 can be distributed and provided in the game server 201 and the terminal device 203. These configurations also achieve the same effects as the above-mentioned embodiments.

For example, in FIG. 10, the game device 3 is provided with a setting means 71 and an event management means 72, but as illustrated in FIG. 24, the game server 201 can be provided with the functions of the setting means 71 and the event management means 72.

Alternatively, as exemplified in Fig. 25, the functions of the setting means 71 and the event management means 72 may be distributed between the game server 201 and the terminal device 203. Note that Fig. 25 shows a configuration example in which the setting means 71 is provided in the game server 201 and the event management means 72 is provided in the terminal device 203, but this is not limiting. The event management means 72 may be provided in the game server 201 and the setting means 71 may be provided in the terminal device 203.
[Other embodiments]

In the above embodiments, a baseball game has been exemplified, but the present invention can also be applied to games in which multiple characters appear, such as soccer games and competitive games. In addition, while an example has been described in which the characters that can be incorporated into the event deck are players or other people, this is not limited to this. A variety of characters can be applied depending on the content of the game, such as animals (race horses, etc.), plants, imaginary creatures (monsters, etc.), and non-living things (materials, tools, etc.).

For example, in the case of a cooking game, characters that can be incorporated into the event deck can be the ingredients for cooking, such as vegetables, fruits, and seasonings. By incorporating such characters into the event deck, an event related to that cooking method occurs, and as that event progresses or is completed, the main character can master a recipe (cooking method) and improve his or her ability parameters as a chef.

In addition, the configuration having a storage control function for storing various information in a storage device does not include the storage device itself, and so the storage device may be installed anywhere, whether inside or outside the game device, terminal device, game server, or game system. For example, the storage device may be RAM 13 or auxiliary storage device 14 of game server 1, RAM 33 or auxiliary storage device 39 of game device 3, or a file server (online storage) configured separately from game server 1 or game device 3.

Furthermore, the configurations described in each of the above embodiments can be applied in appropriate combinations.

The computer-readable program according to this embodiment is recorded on various computer-readable recording media such as a hard disk, optical disk (CD-ROM, DVD-ROM, etc.), flexible disk, and semiconductor memory, and is read from the recording media and executed by the CPU of the game device, terminal device, or game server. The means for providing the program to the server, etc. is not limited to the recording media mentioned above, and can also be provided via a communication network such as the Internet.

1 Game server 3 Game device (game management device)
31 CPU
32 ROM
33 RAM
39 Auxiliary storage device 70 Scenario progression means 71 Setting means 72 Event management means 73 Relationship management means 74 Probability variation means 75 Appearing character management means 76 Settable number management means 77 Companion management means (relationship management means)
78 Permission means 79 Parameter variation means 80 Notification means 201 Game server (game management device)
203 Terminal device (game management device)

Claims (5)

A game system for providing a game including: a first game, which is progressed based on a scenario, in which a second character is trained by changing or setting parameters of the second character; and a second game, which uses the second character trained in the first game,
A storage control means for storing in a storage device at least one of the plurality of character cards associated with one of a plurality of first characters and associated with user identification information;
a deck organizing means for organizing a deck in which a predetermined number of the character cards among the plurality of character cards associated with the user identification information are set, based on a user operation, before the scenario in the first game is started;
an event management means for causing an event related to the character card set in the deck to occur in the first game;
a parameter management means for changing or setting the parameters of the second character in response to the occurrence of the event related to the character card set in the deck;
Including,
the parameter management means changes or sets the parameters of the second character in accordance with the event occurring in the first game;
the parameters of the second character include a plurality of parameters of different types;
the parameter management means changes or sets a specific type of parameter among the plurality of parameters of the second character in response to the event;
the parameter management means, when the event related to the character card set in the deck occurs, determines an amount of variation of the parameter of the second character based on a parameter of the character card;
The events include a first event and a second event;
The character card is associated with a characteristic parameter;
the parameter management means, when the first event related to the character card set in the deck occurs, changes or sets the parameter of the second character corresponding to the characteristic parameter associated with the character card;
a basic event generating means for generating a basic event in the first game that is unrelated to the composition of the deck;
The event management means is a game system that causes the second event related to the character card set in the deck to occur in the first game by lottery based on probability. A game management device that provides a game including a first game that progresses based on a scenario, in which a second character is trained by changing or setting parameters of the second character, and a second game that uses the second character trained in the first game,
A storage control means for storing in a storage device at least one of the plurality of character cards associated with one of a plurality of first characters and associated with user identification information;
a deck organizing means for organizing a deck in which a predetermined number of the character cards among the plurality of character cards associated with the user identification information are set, based on a user operation, before the scenario in the first game is started;
an event management means for causing an event related to the character card set in the deck to occur in the first game;
a parameter management means for changing or setting the parameters of the second character in response to the occurrence of the event related to the character card set in the deck;
Including,
the parameter management means changes or sets the parameters of the second character in accordance with the event occurring in the first game;
the parameters of the second character include a plurality of parameters of different types;
the parameter management means changes or sets a specific type of parameter among the plurality of parameters of the second character in response to the event;
the parameter management means, when the event related to the character card set in the deck occurs, determines an amount of variation of the parameter of the second character based on a parameter of the character card;
The events include a first event and a second event;
The character card is associated with a characteristic parameter;
the parameter management means, when the first event related to the character card set in the deck occurs, changes or sets the parameter of the second character corresponding to the characteristic parameter associated with the character card;
a basic event generating means for generating a basic event in the first game that is unrelated to the composition of the deck;
The event management means causes the second event related to the character card set in the deck to occur in the first game by a lottery based on probability.
Game management device. A game device providing a game including a first game, which is progressed based on a scenario, in which a second character is trained by changing or setting parameters of the second character, and a second game using the second character trained in the first game,
A storage control means for storing in a storage device at least one of the plurality of character cards associated with one of a plurality of first characters and associated with user identification information;
a deck organizing means for organizing a deck in which a predetermined number of the character cards among the plurality of character cards associated with the user identification information are set, based on a user operation, before the scenario in the first game is started;
an event management means for causing an event related to the character card set in the deck to occur in the first game;
a parameter management means for changing or setting the parameters of the second character in response to the occurrence of the event related to the character card set in the deck;
Including,
the parameter management means changes or sets the parameters of the second character in accordance with the event occurring in the first game;
the parameters of the second character include a plurality of parameters of different types;
the parameter management means changes or sets a specific type of parameter among the plurality of parameters of the second character in response to the event;
the parameter management means, when the event related to the character card set in the deck occurs, determines an amount of variation of the parameter of the second character based on a parameter of the character card;
The events include a first event and a second event;
The character card is associated with a characteristic parameter;
the parameter management means, when the first event related to the character card set in the deck occurs, changes or sets the parameter of the second character corresponding to the characteristic parameter associated with the character card;
a basic event generating means for generating a basic event in the first game that is unrelated to the composition of the deck;
The event management means causes the second event related to the character card set in the deck to occur in the first game by a lottery based on probability.
Gaming device. one or more computers that execute control of a game including a first game that progresses based on a scenario, in which a second character is trained by changing or setting parameters of the second character, and a second game that uses the second character trained in the first game;
A storage control means for storing in a storage device at least one of the plurality of character cards associated with one of a plurality of first characters and associated with user identification information;
a deck organizing means for organizing a deck in which a predetermined number of the character cards among the plurality of character cards associated with the user identification information are set, based on a user operation, before the scenario in the first game is started;
an event management means for causing an event related to the character card set in the deck to occur in the first game;
a parameter management means for changing or setting the parameters of the second character in response to the occurrence of the event related to the character card set in the deck;
and make it work.
the parameter management means changes or sets the parameters of the second character in accordance with the event occurring in the first game;
the parameters of the second character include a plurality of parameters of different types;
the parameter management means changes or sets a specific type of parameter among the plurality of parameters of the second character in response to the event;
the parameter management means, when the event related to the character card set in the deck occurs, determines an amount of variation of the parameter of the second character based on a parameter of the character card;
The events include a first event and a second event;
The character card is associated with a characteristic parameter;
the parameter management means, when the first event related to the character card set in the deck occurs, changes or sets the parameter of the second character corresponding to the characteristic parameter associated with the character card;
causing said computer to further function as a basic event generating means for generating a basic event in said first game that is unrelated to the composition of said deck;
The event management means causes the second event related to the character card set in the deck to occur in the first game by a lottery based on probability.
program. A control method for controlling one or more computers that executes control of a game including a first game that progresses based on a scenario, in which a second character is trained by changing or setting parameters of the second character, and a second game that uses the second character trained in the first game, comprising:
A storage control step in which at least one of the character cards is associated with one of a plurality of first characters, and the character card is stored in a storage device in association with user identification information;
a deck organizing step of organizing a deck in which a predetermined number of the character cards among the plurality of character cards associated with the user identification information are set, based on a user operation, before the scenario in the first game is started;
an event management step of causing an event related to the character card set in the deck to occur in the first game;
a parameter management step of changing or setting the parameters of the second character in response to the occurrence of the event related to the character card set in the deck;
Including,
the parameter management step varies the content of the change or setting of the parameter of the second character depending on the event occurring in the first game;
the parameters of the second character include a plurality of parameters of different types;
the parameter management step includes changing or setting a specific type of parameter among the plurality of parameters of the second character in response to the event;
the parameter management step includes, when the event related to the character card set in the deck occurs, determining an amount of change in the parameter of the second character based on a parameter of the character card;
The events include a first event and a second event;
The character card is associated with a characteristic parameter;
the parameter management step, when the first event related to the character card set in the deck occurs, changes or sets the parameter of the second character corresponding to the characteristic parameter associated with the character card;
a basic event generating step of generating a basic event in the first game that is unrelated to the composition of the deck;
The event management step causes the second event associated with the character card set in the deck to occur in the first game by a lottery based on a probability.
Control methods.

Images