JP7146039B1 - Information processing method, information processing system and information processing program - Google Patents

Abstract

An object of the present invention is to improve the interest of a game. An information processing method performed by a computer holds information in which medium identification information given to a game medium set as a special game medium and game identification information given to a predetermined game are linked. Then, the player can select a game medium to be used in the selected predetermined game, the selected game medium is registered, the predetermined game is executed based on the registered game medium, and is set as a special game medium. A display is performed based on the effect that occurs when the game contents are registered, and the game contents set as the special game contents in the selected predetermined game are identified and displayed. [Selection drawing] Fig. 28

Description

The present invention relates to an information processing method, an information processing system, and an information processing program.

Conventionally, a game of a genre called a training game is known. In the breeding game, a plurality of types of breeding items are provided, and the player can select one of the breeding items to train a character to be trained.

For example, Patent Literature 1 discloses a game in which the parameters of a character to be trained change based on characters organized in a deck by a player. Characters raised in the raising game can be used in other games.

Japanese Patent No. 6685049

In the breeding game described above, the real thrill is that various characters with different abilities can be trained by changing the composition of the deck. However, depending on, for example, the state of possession of characters that can be organized in the deck, the progress of the breeding game may be the same every time, and the interest in the game may be reduced.

An object of the present invention is to provide an information processing method, an information processing system, and an information processing program that can improve the interest of a game.

In order to solve the above problems, the information processing method is an information processing method performed by a computer,
Among a plurality of types of game media usable in a predetermined game, medium identification information given to the game media set as special game media is associated with game identification information given to the predetermined game. a process of retaining information;
After the predetermined game is selected, a process of allowing the player to select the game media to be used in the selected predetermined game from among a plurality of types of the game media;
a process of registering the game content selected by the player;
a process of executing the predetermined game based on the registered game content;
a process of displaying, during the predetermined game, a display based on the effect that occurs when the game media set as the special game media is registered;
Based on the player's operation, the permission state permits identification display to display the special game medium in a manner different from that of the non-special game medium , or the non-permission state disables the identification display . and the process of setting the
a process of identifying and displaying the special game content in the selected predetermined game at least after the predetermined game is selected and when the permitted state is set;
including.

The predetermined game includes a plurality of turns,
A unit process is executed in the process of executing the predetermined game,
The unit process includes a process of generating an event linked to the game identification information assigned to the predetermined game being executed,
the utility includes changing the content of the event;
In the process of performing display based on utility, display corresponding to changed content of the event may be performed.

The predetermined game includes a plurality of turns,
A unit process is executed in the process of executing the predetermined game,
The unit process includes a process of generating an event linked to the game identification information assigned to the predetermined game being executed,
The utility includes changing the number or occurrence probability of the event occurring during the predetermined game,
In the processing for performing display based on the utility, display corresponding to the event determined based on the changed number of the events or the probability of occurrence may be performed.

The utility may include changing a parameter used during the predetermined game.

In order to solve the above problems, an information processing system includes one or more computers,
Among a plurality of types of game media usable in a predetermined game, medium identification information given to the game media set as special game media is associated with game identification information given to the predetermined game. a process of retaining information;
After the predetermined game is selected, a process of allowing the player to select the game media to be used in the selected predetermined game from among a plurality of types of the game media;
a process of registering the game content selected by the player;
a process of executing the predetermined game based on the registered game content;
a process of displaying, during the predetermined game, a display based on the effect that occurs when the game media set as the special game media is registered;
Based on the player's operation, the permission state permits identification display to display the special game medium in a manner different from that of the non-special game medium , or the non-permission state disables the identification display . and the process of setting the
a process of identifying and displaying the special game content in the selected predetermined game at least after the predetermined game is selected and when the permitted state is set;
carry out

In order to solve the above problems, the information processing program
Among a plurality of types of game media usable in a predetermined game, medium identification information given to the game media set as special game media is associated with game identification information given to the predetermined game. a process of retaining information;
After the predetermined game is selected, a process of allowing the player to select the game media to be used in the selected predetermined game from among a plurality of types of the game media;
a process of registering the game content selected by the player;
a process of executing the predetermined game based on the registered game content;
a process of displaying, during the predetermined game, a display based on the effect that occurs when the game media set as the special game media is registered;
Based on the player's operation, the permission state permits identification display to display the special game medium in a manner different from that of the non-special game medium , or the non-permission state disables the identification display . and the process of setting the
a process of identifying and displaying the special game content in the selected predetermined game at least after the predetermined game is selected and when the permitted state is set;
is performed by a computer.

According to the present invention, the amusement of the game can be improved.

FIG. 1 is an explanatory diagram showing a schematic configuration of an information processing system. FIG. 2A is a diagram for explaining the hardware configuration of the player terminal. FIG. 2B is a diagram for explaining the hardware configuration of the server. FIG. 3 is a diagram for explaining the general progress of the breeding game. FIG. 4A is a diagram explaining the home screen. FIG. 4B is a first diagram for explaining the main character selection screen. FIG. 4C is the first diagram for explaining the character detail screen. FIG. 4D is a second diagram illustrating the character detail screen. FIG. 5A is a diagram illustrating an ability parameter (initial value) table. FIG. 5B is a diagram illustrating an aptitude parameter (initial value) table. FIG. 5C is a diagram explaining a skill table. FIG. 5D is a diagram illustrating a dedicated event table. FIG. 6A is the first diagram for explaining the support card setting screen. FIG. 6B is a diagram explaining a support card selection screen. FIG. 6C is a second diagram for explaining the support card setting screen. FIG. 7A is a diagram explaining a support card table. FIG. 7B is a diagram explaining a support effect table. FIG. 7C is a diagram explaining a possessed skill table. FIG. 7D is a diagram explaining a support event table. FIG. 8 is the first diagram for explaining the character identification information table. FIG. 9 is a second diagram for explaining the character identification information table. FIG. 10 is a diagram explaining the selection item table. FIG. 11A is the first diagram for explaining the game screen. FIG. 11B is a second diagram for explaining the game screen. FIG. 12A is the first diagram for explaining the training screen. FIG. 12B is a second diagram illustrating the training screen. FIG. 12C is a diagram illustrating a training result notification screen. FIG. 12D is a diagram illustrating an event screen. FIG. 13A is the first diagram for explaining the skill screen. FIG. 13B is a second diagram illustrating the skill screen. FIG. 14A is the first diagram for explaining the individual race selection screen. FIG. 14B is a diagram illustrating an individual race start screen. FIG. 14C is a diagram illustrating an individual race result screen. FIG. 15A is a diagram explaining the team race selection screen. FIG. 15B is a diagram explaining the team race formation screen. FIG. 15C is a diagram explaining the team race start screen. FIG. 15D is a diagram for explaining the team race interim result screen. FIG. 16A is the first diagram for explaining the team race detailed result screen. FIG. 16B is the first diagram for explaining the team race overall result screen. FIG. 16C is a second diagram illustrating the team race detailed result screen. FIG. 16D is a second diagram for explaining the team race overall result screen. FIG. 17 is a diagram for explaining the relationships among team members, sub-members, and random members. FIG. 18 is a diagram for explaining the general flow of processing at the start of a turn. FIG. 19 is a diagram for explaining the arrangement presence/absence table. FIG. 20A is a diagram explaining a training level table. FIG. 20B is a diagram illustrating an upward fixed value (speed) table. Also, FIG. 20C is a diagram for explaining an upward fixed value table (power). FIG. 20D is a diagram explaining a bonus addition rate table. FIG. 21 is a diagram for explaining event types and event classifications. FIG. 22 is a diagram explaining the relationship between the event type and the number of turns. FIG. 23A is the third diagram for explaining the game screen. FIG. 23B is a third diagram illustrating the training screen. FIG. 24A is a diagram for explaining a special training event execution presence/absence determination table. FIG. 24B is a diagram explaining a special icon determination table. FIG. 24C is a diagram explaining a bonus icon determination table. FIG. 25A is a diagram illustrating a fixed bonus value (main character) table. FIG. 25B is a diagram illustrating a bonus additional value (main character) table. FIG. 26A is a diagram illustrating a fixed increase value (for special training) table. FIG. 26B is a diagram illustrating a bonus increase value (special training target) table. FIG. 27A is the fourth diagram for explaining the game screen. FIG. 27B is a second diagram illustrating the individual race selection screen. FIG. 28A is a diagram explaining the scenario top screen. FIG. 28B is the first diagram for explaining the specific character explanation dialog. FIG. 28C is a second diagram for explaining the specific character explanation dialog. FIG. 28D is a second diagram illustrating the main character selection screen. FIG. 29 is a diagram for explaining specific character information. FIG. 30 is a diagram for explaining the configuration of a memory in a player terminal and functions as a computer. FIG. 31 is a diagram for explaining the configuration of a memory in a server and functions as a computer. FIG. 32 is a sequence diagram illustrating basic processing of the player terminal and server. FIG. 33 is a first flowchart for explaining scenario selection processing in the player terminal. FIG. 34 is a second flowchart for explaining scenario selection processing in the player terminal. FIG. 35 is a flowchart for explaining preparatory stage processing in the player terminal. FIG. 36 is a flowchart for explaining training stage processing in the player terminal. FIG. 37 is a flowchart for explaining turn start processing in the player terminal. FIG. 38 is a flowchart for explaining placement processing in the player terminal. FIG. 39 is a flowchart for explaining guest character determination processing in the player terminal. FIG. 40 is a flowchart for explaining numerical value determination processing in the player terminal. FIG. 41 is a flowchart for explaining event determination processing in the player terminal. FIG. 42 is a flowchart for explaining in-turn processing in the player terminal. FIG. 43 is a flowchart for explaining character identification information update processing in the player terminal. FIG. 44 is a flowchart for explaining training execution processing in the player terminal.

One aspect of an embodiment of the present invention will be described in detail below with reference to the accompanying drawings. Numerical values and the like shown in these embodiments are merely examples for facilitating understanding, and do not limit the present invention unless otherwise specified. In the present specification and drawings, elements having substantially the same function and configuration are given the same reference numerals to omit redundant description, and elements that are not directly related to the present invention are omitted from the drawings. do.

(Overall Configuration of Information Processing System S)
FIG. 1 is an explanatory diagram showing a schematic configuration of an information processing system S. As shown in FIG. The information processing system S is a so-called client-server system including a player terminal 1 functioning as a client, that is, a game terminal, a server 1000, and a communication network N having communication base stations Na.

In the information processing system S of this embodiment, the player terminal 1 and the server 1000 function as a game device G. FIG. The player terminal 1 and the server 1000 are each assigned a role to control the progress of the game, and cooperation between the player terminal 1 and the server 1000 enables the game to progress.

The player terminal 1 can establish communication with the server 1000 via the communication network N. FIG. The player terminal 1 includes a wide range of electronic devices that can be connected to the server 1000 for wireless or wired communication. Examples of the player terminal 1 include smart phones, mobile phones, tablet devices, personal computers, game machines, and the like. In this embodiment, a case where a smart phone is used as the player terminal 1 will be described.

A server 1000 is connected for communication with a plurality of player terminals 1 . The server 1000 accumulates various types of information for each player who plays the game. In addition, the server 1000 mainly performs processing such as updating accumulated information and downloading images and various information to the player terminal 1 based on operations input from the player terminal 1 .

The communication base station Na is connected to the communication network N, and transmits/receives information to/from the player terminal 1 by radio. The communication network N is composed of a mobile phone network, the Internet network, a LAN (Local Area Network), a dedicated line, etc., and realizes wireless or wired communication connection between the player terminal 1 and the server 1000 .

(Hardware configuration of player terminal 1 and server 1000)
FIG. 2A is a diagram for explaining the hardware configuration of the player terminal 1. As shown in FIG. FIG. 2B is a diagram for explaining the hardware configuration of the server 1000. As shown in FIG. As shown in FIG. 2A, the player terminal 1 includes a CPU (Central Processing Unit) 10, a memory 12, a bus 14, an input/output interface 16, a storage section 18, a communication section 20, an input section 22, and an output section 24. be done.

2B, the server 1000 includes a CPU 1010, a memory 1012, a bus 1014, an input/output interface 1016, a storage unit 1018, a communication unit 1020, an input unit 1022, and an output unit 1024.

The configurations and functions of the CPU 1010, the memory 1012, the bus 1014, the input/output interface 1016, the storage unit 1018, the communication unit 1020, the input unit 1022, and the output unit 1024 of the server 1000 are the same as those of the CPU 10, the memory 12, and the They are substantially the same as the bus 14 , input/output interface 16 , storage section 18 , communication section 20 , input section 22 and output section 24 . Therefore, the hardware configuration of the player terminal 1 will be described below, and the description of the server 1000 will be omitted.

The CPU 10 operates programs stored in the memory 12 to control the progress of the game. The memory 12 is composed of a ROM (Read Only Memory) or a RAM (Random Access Memory), and stores programs and various data necessary for controlling the progress of the game. Memory 12 is connected to CPU 10 via bus 14 .

An input/output interface 16 is connected to the bus 14 . A storage unit 18 , a communication unit 20 , an input unit 22 and an output unit 24 are connected to the input/output interface 16 .

The storage unit 18 is composed of a semiconductor memory such as a DRAM (Dynamic Random Access Memory), and stores various programs and data. In the player terminal 1, the programs and data stored in the storage unit 18 are loaded by the CPU 10 into the memory 12 (RAM).

The communication unit 20 is wirelessly connected to the communication base station Na, and transmits/receives information such as various data and programs to/from the server 1000 via the communication network N. In the player terminal 1 , the program or the like received from the server 1000 is stored in the memory 12 or the storage section 18 .

The input unit 22 includes, for example, a touch panel through which player's operations are input (accepts operations), buttons, a keyboard, a mouse, a cross key, an analog controller, and the like. Also, the input unit 22 may be a dedicated controller provided in the player terminal 1 or connected (externally attached) to the player terminal 1 . Furthermore, the input unit 22 may be configured with an acceleration sensor that detects the tilt or movement of the player terminal 1, or a microphone that detects the voice of the player. That is, the input unit 22 broadly includes a device capable of inputting the player's intention in an identifiable manner.

The output unit 24 includes a display device and a speaker. Note that the output unit 24 may be a device connected (externally attached) to the player terminal 1 . In this embodiment, the player terminal 1 includes a display 26 as the output unit 24 and a touch panel provided as an input unit 22 so as to overlap the display 26 .

(game content)
Next, a game provided by the information processing system S and the game device G of this embodiment will be described. A player can own a character obtained by a lottery called gacha, or a character distributed by the management side. In addition, the player can possess a support card obtained by a lottery called gacha, or a support card distributed by the management side.

Although the details will be described later, in the present embodiment, in a breeding game including a plurality of (for example, 60) turns, the character possessed by the player is trained. Further, the breeding game in the present embodiment is an anthropomorphic racehorse as a character, and has game characteristics in which the character is trained and the character is trained to aim for the first place in a race simulating a horse race.

FIG. 3 is a diagram for explaining the general flow of the breeding game. The breeding game is roughly divided into a setting game and a breeding main game. Although the details will be described later, the breeding main game is a game in which one main character selected from the characters possessed by the player is trained. Also, the setting game corresponds to the preparatory stage of the breeding main game, and is a game in which main characters and support cards are registered. Hereinafter, the processing performed in the setting game will be referred to as preparatory stage processing, and the processing performed in the training main game will be referred to as training stage processing. For ease of understanding, the general flow of the preparatory stage processing and the growing stage processing will be described first.

<Preparation stage processing>
In the preparatory stage processing, main character registration, support card registration, specific character registration, and setting of initial character identification information are mainly performed. Note that the support card is for assisting the training of the main character. Each support card is always associated with one character, and the character associated with the support card registered in the preparatory stage assists the development of the main character. Below, the character tied to the support card is called a support character.

<Register main character>
FIG. 4A is a diagram illustrating the home screen 27. FIG. In this embodiment, when the game application is started on the player terminal 1, the home screen 27 is displayed on the display 26. FIG. At the bottom of the home screen 27, a menu bar 28 and a scenario operation section 29 labeled "scenario" are displayed.

The menu bar 28 is provided with a plurality of operation units that can be operated (tapped) by the player. The menu bar 28 is provided with a home screen selection operation section 28a labeled "home", a race screen selection operation section 28b labeled "race", and a gacha screen selection operation section 28c labeled "gacha". ing. In addition, in the menu bar 28, the operation section corresponding to each screen is highlighted so that the screen being displayed on the display 26 can be identified.

When the player taps the gacha screen selection operation section 28 c on the home screen 27 , a gacha screen (not shown) is displayed on the display 26 . Although detailed description is omitted, on the gacha screen, a so-called gacha lottery can be performed in which characters and support cards can be obtained by lottery. A player can draw a gacha lottery by consuming in-game currency.

Further, when the player taps the scenario operation section 29 on the home screen 27, a scenario selection screen (not shown) is displayed. In this embodiment, a plurality of training main game scenarios are provided. Each scenario of the breeding main game is set with a final goal, a goal during the game, etc., and the player needs to clear the set goals in order. Each target and the period until the target is achieved are different for each scenario. A player can select one of a plurality of scenarios on the scenario selection screen.

Here, a first scenario and a second scenario are provided, and the following description assumes that the first scenario is selected. When the first scenario is selected on the scenario selection screen, a scenario top screen, which will be described later, is displayed. When a predetermined operation is performed on the scenario top screen, the main character selection screen 30 shown in FIG. 4B is displayed on the display 26 . As a result, the setting game is started, and preparation stage processing is executed. The content of the setting game is common to all scenarios. However, the content of the setting game may differ for each scenario.

FIG. 4B is a first diagram for explaining the main character selection screen 30. FIG. A plurality of character icons 31 are displayed in the center of the main character selection screen 30, and a list of characters possessed by the player is displayed. Also, a parameter display section 32 is displayed at the top of the main character selection screen 30 . At the bottom of the main character selection screen 30, a return operation section 33 labeled "Return" and a next operation section 34 labeled "NEXT" are displayed.

In this embodiment, an initial value of the ability parameter is set for each character, and the initial value of the ability parameter of the character corresponding to the character icon 31 selected by the player is displayed in the parameter display section 32 as a numerical value. In this embodiment, the higher the numerical value of the ability parameter, the higher the ability.

FIG. 5A is a diagram illustrating an ability parameter (initial value) table. In this embodiment, as shown in FIG. 5A, an ability parameter (initial value) table stores initial values of ability parameters for each character. Then, the initial values of the ability parameters are displayed on the parameter display section 32 based on the initial values of the ability parameters stored in the ability parameter (initial value) table.

In this embodiment, initial values of ability parameters are set for each of a plurality of types of abilities for each character. Specifically, as the ability parameters, the speed ability parameter indicated as "Speed" in the parameter display section 32, the stamina ability parameter indicated as "Stamina" in the parameter display section 32, and the parameter display section 32 as "Power , a guts ability parameter marked with "Spirit" in the parameter display section 32, and a wisdom ability parameter marked with "Wisdom" in the parameter display section 32 are provided.

Note that the initial value of the ability parameter for each character may be increased by the player's operation or the like. For example, a character may have five levels, and the player can raise the level of the character by consuming in-game currency or predetermined items. In this case, it is preferable that the initial value of the ability parameter increases as the character's level increases. Note that the player can increase the value of the ability parameter in the training main game. In other words, the purpose of the training main game is to train characters with higher ability parameter values.

Further, in this embodiment, aptitude parameters (initial values) are set for each character. FIG. 5B is a diagram illustrating an aptitude parameter (initial value) table. In this embodiment, as shown in FIG. 5B, the initial value of the aptitude parameter for each character is stored in the aptitude parameter (initial value) table. The initial value of the aptitude parameter is set to one of seven levels from A to G in the alphabet. The aptitude parameter indicates that A has the highest aptitude and G has the lowest aptitude. The initial values of the aptitude parameters may be displayed in the parameter display section 32 based on the initial values of the aptitude parameters stored in the aptitude parameter (initial value) table.

In this embodiment, initial values of aptitude parameters are set for each of a plurality of types of aptitudes for each character. Specifically, as the aptitude parameters, the aptitude parameters for grass and dirt field aptitudes, the distance aptitude parameters for short distance, mile, medium distance, and long distance, escape, lead, lead, An aptitude parameter relating to leg quality aptitude for each of the following is provided.

It should be noted that the initial value of the aptitude parameter for each character may be raised by consuming in-game currency. Also, the value of the aptitude parameter may change in the training main game. In the training main game, the aptitude parameter may be set to S, which is higher in aptitude than A.

FIG. 4C is a first diagram for explaining the character detail screen 40. As shown in FIG. FIG. 4D is a second diagram for explaining the character detail screen 40. As shown in FIG. When the character icon 31 on the main character selection screen 30 is long pressed, a character detail screen 40 is displayed on the display 26 . The character detail screen 40 displays the details of the ability of the character corresponding to the character icon 31 long-pressed on the main character selection screen 30 .

A skill operation section 41 and an event operation section 42 are displayed in the center of the character detail screen 40 . As shown in FIG. 4C, when the character detail screen 40 is first displayed, the skill operation section 41 is highlighted, and the skills provided for each character are displayed. A skill is an ability that may be activated when a predetermined condition is met during individual races and team races, which will be described later. Each character's race development becomes advantageous by activating skills.

FIG. 5C is a diagram explaining a skill table. As shown in FIG. 5C, the skill table stores skills for each character possessed by the player. Based on the skills stored in the skill table, the skills are displayed on the character detail screen 40 as shown in FIG. 4C. Skills cannot be activated just by possessing them, and can only be activated by acquiring them. A skill that can be activated by a character is hereinafter referred to as an acquired skill.

One acquired skill 41a is set for the character from the beginning of the breeding main game. In addition to the acquired skills 41a, the character has a plurality of possessed skills 41b. Possessed skill 41b is a skill that can be acquired by consuming skill points, which will be described later, after starting the training main game. That is, the possessed skill 41b can become the acquired skill 41a in exchange for skill points.

In this embodiment, the skill corresponding to "⊚" in the skill table shown in FIG. 5C is displayed as the acquired skill 41a on the character detail screen 40 in FIG. 4C. Also, the skill corresponding to "o" in the skill table shown in FIG. 5C is displayed as possessed skill 41b on the character detail screen 40 in FIG. 4C. In this embodiment, as shown in the character detail screen 40 of FIG. 4C, the acquired skill 41a is highlighted so that the acquired skill 41a and the possessed skill 41b can be easily distinguished.

In the present embodiment, FIG. 4C shows a case where one acquired skill 41a and seven possessed skills 41b are displayed as skills provided for each character, but the present invention is not limited to this. not something. For example, the number of acquired skills 41a and possessed skills 41b may differ for each character. Further, for example, the number of acquired skills 41a or possessed skills 41b of each character may increase due to an increase in character level, consumption of in-game currency or items, or the like.

Also, when the player taps the event operation section 42 of the character detail screen 40, the contents of the character detail screen 40 are switched, and a dedicated event 42a provided for each character is displayed as shown in FIG. 4D. In this case, the event operation section 42 is highlighted as shown in FIG. 4D. The dedicated event 42a is generated when a predetermined condition is satisfied in the breeding main game, and displays a story related to a character appearing in the breeding game, or changes the value of an ability parameter.

FIG. 5D is a diagram illustrating a dedicated event table. As shown in FIG. 5D, the dedicated event table stores a dedicated event 42a for each character possessed by the player. Based on the dedicated event 42a stored in the dedicated event table, the dedicated event 42a is displayed on the character detail screen 40 as shown in FIG. 4D. Note that the dedicated event 42a may include a hint event that makes it possible to possess or acquire a skill, an ability event that increases or decreases the numerical value of a character's ability parameter, and the like.

The dedicated event 42a displayed on the character detail screen 40 shown in FIG. 4D may be entirely executed during execution of the training main game, or at least part of it may be executed during execution of the training main game. Alternatively, if a predetermined condition is not met, none of the training main games may be executed during execution of the breeding main game. Further, for example, the number of dedicated events 42a provided for each character may increase due to an increase in character level, consumption of in-game currency or items, or the like. Also, when a predetermined condition is satisfied, a dedicated event 42a not displayed as a dedicated event 42a may be executed during the breeding main game.

Further, as shown in FIGS. 4C and 4D , a close operation section 43 labeled “close” is displayed at the bottom of the character detail screen 40 . When the close operation portion 43 of the character detail screen 40 is tapped, the display of the character detail screen 40 ends and the main character selection screen 30 is displayed on the display 26 .

Further, when the return operation unit 33 is tapped on the main character selection screen 30 shown in FIG. 4B, the home screen 27 shown in FIG. 4A is displayed on the display 26. As shown in FIG.

Further, when the next operation section 34 is tapped on the main character selection screen 30 shown in FIG. 4B , the character being selected is set as the main character, and the support card setting screen 50 is displayed on the display 26 .

<Register Support Card>
FIG. 6A is a first diagram for explaining the support card setting screen 50. FIG. A support card display area 51 is provided in the center of the support card setting screen 50 . The support card display area 51 includes a plurality of support card setting operation sections 52 . In addition, at the bottom of the support card setting screen 50, a return operation section 53 labeled "Return" and a start operation section 54 labeled "START" are displayed.

In the support card display area 51, a plurality of (here, six) support card setting operation sections 52 are displayed. The support card setting operation section 52 displays the same number of support cards that can be set by the player. Note that when the support card setting screen 50 is initially displayed, the support card setting operation section 52 is displayed as a blank space.

In this embodiment, six types of support cards can be set from the support cards possessed by the player. Of the 6 types that can be set, some (for example, 5 types) can be selected from the support cards possessed by the player, and the rest (for example, 1 type) can be selected from the support cards that the player does not possess. It may be possible to select from among

FIG. 6B is a diagram for explaining the support card selection screen 60. As shown in FIG. When the support card setting operation section 52 of the support card setting screen 50 of FIG. 6A is operated, the support card selection screen 60 shown in FIG. 6B is displayed on the display 26. FIG. The support card selection screen 60 displays a list of icons 61 corresponding to the support cards possessed by the player. By tapping an icon 61 displayed on the support card selection screen 60, the player can select a support card.

FIG. 7A is a diagram explaining a support card table. As shown in FIG. 7A, the support card table stores the support character type (that is, character ID), rarity, level, and specialty training for each support card type (that is, support card ID) possessed by the player. It is Support characters correspond one-to-one with support card types. That is, the support card ID is always associated with one character ID. In other words, one support card is always associated with one support character.

In this embodiment, a rarity is set for each support card. There are three levels of rarity: R (rare), SR (super rare), and SSR (super special rare). Note that R has the lowest rarity and SSR has the highest rarity. In the present embodiment, support cards with higher rarity tend to have higher support effects, which will be described later. Further, in the present embodiment, the higher the rarity of the support card, the greater the number of possessed skills and the number of support events, which will be described later.

There are 50 levels from level 1 to level 50 for support card levels. The level of the support card can be raised by the player, and the level raised by the player is stored for each support card. The level of support cards can be raised by using in-game currency or items. Note that the level of the support card has an upper limit depending on its rarity.

For example, R rarity support cards have an upper limit of level 20, SR rarity support cards have an upper limit of level 25, and SSR rarity support cards have an upper limit of level 30. is defined as

Note that the upper limit of the level can be increased step by step when a predetermined condition is satisfied. For example, a support card with a rarity of R can raise the upper limit to a maximum level of 40, and a support card of a rarity of SR can raise the upper limit to a maximum level of 45. The SSR support card may be able to raise the upper limit up to level 50.

FIG. 7B is a diagram explaining a support effect table. As shown in FIG. 7B, the support effect table stores support effects for each type of support card possessed by the player.

The support effect increases various statuses in the training main game. A support card has multiple targets for support effects. Examples of targets for the support effect include physical strength, speed, stamina, power, guts, wisdom, and the like.

FIG. 7C is a diagram explaining a possessed skill table. As shown in FIG. 7C, possessed skills are set in the possessed skill table for each support card possessed by the player.

In this embodiment, possessed skills are set for each support card so that the character set as the main character by the player possesses possessed skills. Possessed skills set for each support card can be acquired by a main character selected by the player or another character promoted to a team member, which will be described later, when a hint event occurs during the training main game.

FIG. 7D is a diagram explaining a support event table. As shown in FIG. 7D, the support event table stores support events that can occur for each support card possessed by the player. A support event is an event that may occur during execution of the training main game. When a support event occurs, the values of various statuses in the training main game may increase or decrease.

For example, the support event to occur may be determined according to the number of turns, or the support event to occur may be determined by a predetermined lottery. Also, multiple support events may be selected in one turn. In any case, the support event to occur may be determined according to a predetermined determination method that has been set in advance.

FIG. 6C is a second diagram for explaining the support card setting screen 50. FIG. In this embodiment, when all six support cards are selected, the start operation unit 54 becomes operable as shown in FIG. 6C. On the other hand, when all the six support cards are not selected, the start operation section 54 cannot be operated as shown in FIG. 6A.

When the return operation section 53 of the support card setting screen 50 is operated, the main character selection screen 30 shown in FIG. 4B is displayed on the display 26. FIG. Further, as shown in FIG. 6C, when the start operation section 54 is tapped on the support card setting screen 50, the selected support card is registered and the game screen 70 (FIG. 11A) is displayed on the display 26. FIG.

<Registration of specific characters>
As described above, after the main characters and support cards are registered, the specific characters are then registered. In this embodiment, four types of characters are set in advance as specific characters for the first scenario.

FIG. 8 is the first diagram for explaining the character identification information table. FIG. 9 is a second diagram for explaining the character identification information table. In FIG. 8, "Character C" is registered as a main character, and "Character E", "Character I", "Character L", "Character M", "Character Q", and "Character T" are registered as support characters. Indicates the case of registration. In FIG. 9, "Character F" is registered as a main character, and "Character E", "Character J", "Character L", "Character M", "Character Q", and "Character T" are registered as support characters. ” is registered.

In this embodiment, when registering the support card, the character type set as the main character and the character type set as the support character are restricted so as not to overlap.

In this embodiment, as shown in FIG. 8, "character F", "character J", "character N", and "character R" are set as the specific characters of the first scenario. Then, when the player selects a main character from a plurality of characters, the selected character is registered as the main character in the character identification information table.

Also, when a support card is selected by the player's operation, the character identification information table is updated, and the character corresponding to the selected support card is registered as the support character.

Further, in the character identification information table, when the information regarding the main character and the support card is registered, the information regarding the specific character is registered. At this time, in the first scenario, as shown in FIGS. 8 and 9, "character F", "character J", "character N", "character N", and " Character R" is registered as a specific character.

<Setting initial character identification information>
As described above, when the main character, support characters, and specific characters are registered, team members and sub-members are registered. Although the details will be described later, in the breeding game, it is necessary to play a battle game using characters registered as team members. Also, when a character registered as a sub-member satisfies a certain condition, the character is registered as a team member.

In this embodiment, characters registered as main characters, support characters, and specific characters are registered as team members in the character identification information table. That is, in the case of FIG. 8, "character C", "character E", "character F", "character I", "character J", "character L", "character M", "character N", "character Q", "Character R", and "Character T" are registered as team members. In the case of FIG. 9, "character E", "character F", "character J", "character L", "character M", "character N", "character Q", "character R", "character T" is registered as a team member.

In the character identification information table, characters or support cards (support characters) possessed by the player that are not registered as team members are registered as sub-members. Of the predetermined characters, all of the remaining characters not registered as team members, or some characters selected by lottery may be registered as sub-members.

In this way, when the information (initial character identification information) relating to the team members and sub-members is stored in the character identification information table, the preparatory stage processing is completed.

<Upbringing stage processing>
After the preparatory stage processing is finished, the growing stage processing is started. In the training stage process, it is possible to train characters registered as main characters and team members. To facilitate understanding, the basic flow of the breeding main game will be described first, and then the features of the breeding main game will be described in detail.

FIG. 10 is a diagram explaining the selection item table. A selection item table may be provided according to the type of the main character, or a common selection item table may be provided regardless of the type of the main character. As shown in FIG. 10, the breeding game consists of the 1st turn to the 60th turn, and has a game characteristic that various parameters are updated according to the player's selection result in each turn.

FIG. 11A is a first diagram for explaining the game screen 70. FIG. FIG. 11B is a second diagram illustrating the game screen 70. FIG. When shifting to the training stage process, the game screen 70 shown in FIGS. 11A and 11B is displayed on the display 26 . A physical strength display portion 71 and a condition display portion 72 are displayed in the upper portion of the game screen 70 . The main character is provided with a "physical strength" parameter. The "physical strength" parameter is mainly used to calculate a failure rate, which is the probability of failure in training, which will be described later. The physical strength display section 71 is displayed so that the remaining amount of the current "physical strength" of the main character can be visually grasped with respect to the upper limit value of the "physical strength".

In addition, the main character is provided with a "tone" parameter. The condition display section 72 displays the current "condition" of the main character so that it can be visually grasped in a plurality of stages (five levels of bad condition, bad condition, normal, good condition, and excellent condition). The higher the "tone" parameter, the more advantageous the main character's race progresses, and the greater the increase in the ability parameter due to training.

In addition, as shown in FIGS. 11A and 11B, an image of the main character, a status display portion 73, and a skill point display portion 74 are displayed in the central portion of the game screen 70. FIG. In the status display section 73, the current status of the main character is indicated by a numerical value and multiple ranks (G ⁺ , F, F ⁺ , E, E ⁺ , D, D ⁺ , C, C ⁺ , B, B ⁺ , 16 stages of A, A ⁺ , S, SS, SS ⁺ ). Specifically, in the present embodiment, each ability parameter of "Speed" (speed), "Stamina" (stamina), "Power" (power), "Spirit" (guts), "Wisdom" (wisdom) Numerical values and ranks are displayed. Also, in the skill point display section 74, the remaining amount of skill points possessed by the main character in the breeding game is displayed numerically.

Further, as shown in FIGS. 11A and 11B, at the bottom of the game screen 70, there is a rest operation section 75 labeled "Rest", a training operation section 76 labeled "Training", and a training operation section 76 labeled "Skill". A skill operation section 77, an outing operation section 78 labeled "Going Out", an individual race operation section 79a labeled "Race", and a team race operation section 79b labeled "Team Race" are displayed. .

11A, the individual race operation section 79a and the team race operation section 79b, as shown in FIG. 11B, share a common area displayed on the game screen . Also, the current number of turns is displayed at the top of the game screen 70 .

In each turn, the player presses "Rest" (rest operation section 75), "Training" (training operation section 76), "Going Out" (outing operation section 78), "Race" (individual race operation section 79a), Any item of "Team Race" (team race operation section 79b) can be selected. At this time, as shown in FIG. 10, selectable items are preset for each turn.

In this embodiment, the item of "Team Race" (team race operation section 79b) is set as shown in FIG. When selectable, each of "Rest" (rest operation unit 75), "Training" (training operation unit 76), "Going Out" (outing operation unit 78), and "Race" (individual race operation unit 79a) The item is set to be unselectable. In addition, each item of "Rest" (rest operation unit 75), "Training" (training operation unit 76), "Going Out" (going out operation unit 78), and "Race" (individual race operation unit 79a) can be selected. In this case, the item "Team Race" (team race operation section 79b) is set to be unselectable.

On the other hand, the skill operation section 77 is set to be always selectable in all turns. In addition, although the details will be described later, even if the skill is acquired, the turn will not end.

FIG. 12A is a first diagram illustrating the training screen 80. FIG. FIG. 12B is a second diagram illustrating the training screen 80. FIG. When the training operation section 76 of the game screen 70 is operated, a training screen 80 is displayed on the display 26 .

As shown in FIG. 12A, training items are displayed at the bottom of the training screen 80 . Here, a speed operation unit 81 labeled "Speed", a stamina operation unit 82 labeled "Stamina", a power operation unit 83 labeled "Power", and a guts operation unit 84 labeled "Spirit" , the wisdom operation section 85 marked with "Wisdom" is displayed.

When the player taps one of the operation units 81 to 85 once, the training item corresponding to the tapped operation unit 81 to 85 is provisionally selected, and the operation units 81 to 85 corresponding to the provisionally selected training item are selected. is highlighted. FIG. 12A shows a state in which the power operation section 83 is provisionally selected. Also, FIG. 12B shows a state in which the stamina operation section 82 is provisionally selected.

In addition, the training level for each training item is also displayed on each of the operation sections 81 to 85. FIG. As will be described later in detail, the training level is a parameter that increases as the team ranking increases, and the higher the training level, the greater the increase in the ability parameter when training is performed. The training level is initially set at level 1 and increases up to level 5.

Further, a failure rate display section 86 marked with "Failure" is displayed in the operation sections 81 to 85 that are currently being provisionally selected. The failure rate numerically displayed on the failure rate display section 86 is set to increase in inverse proportion to the remaining physical strength displayed on the physical strength display section 71 .

Further, the status display section 73 displays the value by which the ability parameter increases when the training corresponding to the temporarily selected operation section 81 to 85 is executed and the training is successful. For example, in the example shown in FIG. 12A, the power operation section 83 is provisionally selected, and the status display section 73 displays "+8" for "Stamina" and "+10" for "Power". In the example shown in FIG. 12B, the stamina operation section 82 is provisionally selected, and the status display section 73 displays "+15" for "Stamina" and "+5" for "Spirit".

In addition, an event notification display 87 is displayed on the operation units 81 to 85 corresponding to the training item in which a predetermined event occurs when the training is executed successfully. It should be noted that the event notification display 87 can have different display modes depending on the type of event.

In addition, in the upper right portion of the training screen 80, an icon 88 of a character arranged in training is displayed for each item of the operation units 81 to 85 that are temporarily selected. If the training is successful and a predetermined event occurs corresponding to the character displayed on the icon 88 , an event notification display 87 is displayed on the corresponding icon 88 . In addition, hereinafter, training in which characters are arranged is referred to as joint training.

FIG. 12C is a diagram illustrating the training result notification screen 80a. When one of the temporarily selected operation units 81 to 85 is tapped again, training corresponding to the tapped operation unit 81 to 85 is performed. When the training is executed, a training result notification screen 80a is displayed on the display 26 to notify success or failure of the training. Here, the characters "success" are displayed to inform the player of the success of the training.

Also, at this time, the ability parameter of the status display section 73 is updated and displayed based on the success of the training. That is, the ability parameter (ability information) of the main character corresponding to the training item (training item) selected by the player is updated.

Here, the value of the ability parameter that increases when the training displayed in the status display section 73 in FIG. 12A or 12B is successful is added. Also, the display of the physical fitness display section 71 is updated according to the training item that has been executed. Train speed, stamina, power, or guts, and if you succeed, your health will decrease. On the other hand, if you train your wisdom and succeed, your strength will be restored.

Also, if the training fails, a predetermined penalty is given. Specifically, the content of the penalty includes a decrease in physical strength, a decrease in numerical values of ability parameters, a decrease in condition, and the like. For example, penalties given when the failure rate is high are more disadvantageous than penalties given when the failure rate is low. (large, step of decreasing tone is large).

Also, the content of the penalty may be determined according to the training item. For example, if speed training fails, the value of the speed ability parameter may decrease, and if power training fails, the value of the power ability parameter may decrease. Also, for some training items (for example, wisdom), even if the training fails, no penalty may be given.

FIG. 12D is a diagram illustrating the event screen 80b. When the display of the training result notification screen 80a ends, the display 26 may display an event screen 80b. Various events are executed on the event screen 80b. Multiple events may occur during one turn.

For example, when a hint event occurs, a skill hint is obtained. Once the skill hint is obtained, the player can acquire the skill by consuming skill points. There are multiple types of skills, and each skill may trigger a specific ability. Activation conditions and effects are defined for each skill, and the predetermined effects are activated when each activation condition is satisfied. Skills may be activated during individual races and team races, which will be described later.

Events include skill acquisition events, physical strength recovery events, physical strength reduction events, ability parameter increase events, ability parameter decrease events, condition increase events, condition decrease events, etc. is Although the details will be described later, the event includes an event that is predetermined for each turn and an event that occurs when a player wins a predetermined lottery. Also, when all the events that have occurred are finished, the game screen 70 for the next turn is displayed.

FIG. 13A is a first diagram illustrating the skill screen 90. FIG. FIG. 13B is a second diagram illustrating the skill screen 90. FIG. When the skill operation section 77 of the game screen 70 is operated, the skill screen 90 shown in FIG. 13A is displayed on the display 26. FIG.

The skill screen 90 displays acquired skills, possessed skills set in advance for the main character, possessed skills due to the occurrence of various events, and the like. Also, when a hint event occurs for a possessed skill, the skill points consumed to acquire this possessed skill are discounted. Here, for the possessed skills for which hints have been acquired, the skill points required to acquire them are discounted and displayed. At this time, the discount rate is also displayed.

The skills displayed on the skill screen 90 also display activation conditions for each skill and effects when activated.

A physical strength display portion 71 , a condition display portion 72 , and a skill point display portion 74 are displayed in the upper portion of the skill screen 90 . Also, the current number of turns is displayed at the top of the skill screen 90 .

When the possessed skill is acquired by consuming skill points based on the player's operation, as shown in FIG. The consumed skill points are subtracted from the skill points displayed in the skill point display section 74, and the display is updated.

FIG. 14A is a first diagram illustrating the individual race selection screen 100. FIG. When the individual race operation section 79a of the game screen 70 is operated, the individual race selection screen 100 shown in FIG. 14A is displayed. The individual race has a game feature in which the main character races with a so-called non-player character (hereinafter referred to as NPC).

At the top of the individual race selection screen 100, a physical fitness display section 71 and a condition display section 72 are displayed. In the center of the individual race selection screen 100, an individual race selection operation section 101 is displayed for selecting the type of individual race in which the main character will run. Also, at the bottom of the individual race selection screen 100, a start operation section 102 labeled "Start" is displayed. Note that the races that can be selected by the individual race selection operation section 101 of the individual race selection screen 100 are set in advance for each turn. Further, conditions for entering each race may be set in advance, and when the conditions are met, the race may be entered.

FIG. 14B is a diagram illustrating the individual race start screen 110. FIG. When the start operation unit 102 is operated in a state where the type of individual race to enter is selected in the individual race selection operation unit 101, the individual race start screen 110 shown in FIG. 14B is displayed. A strategy display section 111 is displayed in the center of the individual race start screen 110 . In addition, in the strategy display section 111, the currently selected strategy (run-in, push, advance, escape) is highlighted and a change operation section 112 labeled "Change" is displayed. When the change operation unit 112 is operated, a strategy change screen (not shown) is displayed on the display 26 . The player can change the strategy in the individual race to any strategy by operating the strategy change screen.

In addition, at the bottom of the individual race start screen 110, a result operation section 113 marked with "Result" and a race operation section 114 marked with "Race" are displayed.

When the race operation unit 114 is operated, a race screen (not shown) is displayed on the display 26 . The display 26 displays a moving image of the development of the race (hereinafter also referred to as a racing moving image).

FIG. 14C is a diagram illustrating an individual race result screen 120. FIG. When the reproduction of the race moving image ends and when the result operation unit 113 is operated, the individual race result screen 120 is displayed on the display 26 . The order of finish in the individual race is displayed on the individual race result screen 120 .

FIG. 15A is a diagram illustrating the team race selection screen 130. FIG. When the team race operation section 79b of the game screen 70 is operated, the team race selection screen 130 shown in FIG. 15A is displayed. At the center of the team race selection screen 130, an opponent team selection operation section 131 is displayed for selecting an opponent for the team race to participate in. Note that the opponent can be an NPC. Also, opponents are not limited to NPCs, and may be teams of other players. In this case, a communication competition is held against a team of other players.

It should be noted that the characters to participate in the team race need only be selectable by the team members, and do not necessarily include the main character. Also, one team member may be allowed to participate in multiple races in the team race.

FIG. 15B is a diagram illustrating the team formation screen 140. As shown in FIG. When the opponent team selection operation section 131 is operated, a team formation screen 140 is displayed on the display 26 . A team formation operation section 141 is displayed on the team formation screen 140 . By operating the team formation operation unit 141, the player can use characters registered as team members to form characters for the team race. In this embodiment, the team race includes five races: "short distance", "mile", "middle distance", "long distance", and "dirt race". The overall victory or defeat of the team race is decided based on the victory or defeat of each race.

Specifically, when the number of races won by the player's team out of the five races is greater than the number of races won by the opponent's team, the player wins the team race overall. On the other hand, if the number of races won by the player's team out of the five races is less than or equal to the number of races won by the opponent's team, the overall team race is defeated.

In addition, the player can organize up to three types of characters from the team members for each race. Also, here, characters of the same type cannot be organized into multiple races. Also, at the bottom of the team formation screen 140, a start operation section 142 labeled "Start" is displayed.

FIG. 15C is a diagram illustrating the team race start screen 150. FIG. When the start operation section 142 of the team formation screen 140 is operated, the team race start screen 150 shown in FIG. 15C is displayed. In this embodiment, five races are run in the team race, and the order in which they are run may be a predetermined order or may be randomly determined.

As shown in FIG. 15C, in the central part of the team race start screen 150, the characters of the team organized by the players and the characters of the opponent's team for the race to be executed are displayed. Here, a case is shown in which the player organizes two characters for the "middle distance" race, and two opponent characters are organized.

In addition, as shown in FIG. 15C, at the bottom of the team race start screen 150, a result operation section 151 labeled "Result" and a race operation section 152 labeled "Race" are displayed. When the race operation unit 152 is operated, a race moving image (not shown) is displayed.

FIG. 15D is a diagram illustrating the team race interim result screen 160. FIG. When the reproduction of the race moving image ends and when the result operation section 151 of the team race start screen 150 is operated, the team race interim result screen 160 is displayed on the display 26 . The team race interim result screen 160 displays the results of the race (here, the “middle distance” race). In addition, the method of determining the win/loss of each of the five races in the team race is not particularly limited. For example, the team to which the first-place character belongs may win. Alternatively, points may be given for each order of arrival, and the team with the highest number of points may win.

Then, when the display of the team race interim result screen 160 of FIG. 15D ends, the team race start screen 150 relating to the next race (for example, the "short distance" race) is displayed. The team race start screen 150 and the team race interim result screen 160 are sequentially displayed until the races of all three types are completed.

FIG. 16A is a first diagram illustrating the team race detailed result screen 170. FIG. After the team race start screen 150 and the team race interim result screen 160 for all five types of races are displayed as described above, the team race detailed result screen 170 is displayed on the display 26 . A win/loss result display portion 171 is displayed in the center of the team race detailed result screen 170 . The winning/losing result display section 171 notifies the player of the winning/losing result of each race. Here, as shown in FIG. 16A, there are 3 wins and 2 losses in each race.

FIG. 16B is a first diagram illustrating the team race overall result screen 180. FIG. When the display of the winning/losing result display section 171 ends, the team race overall result screen 180 is displayed on the display 26 . On the team race overall result screen 180, the player is notified of the overall win/loss result of the team race. As shown in FIG. 16A, when there are 3 wins and 2 losses in each race, the team race overall result screen 180 reports that the team race has been won.

Team rankings are also displayed on the team race overall result screen 180 . In this embodiment, the team ranking fluctuates based on the results of team race wins and losses. For example, when a team race is won, the team ranking goes up.

Also, on the team race overall result screen 180 informing that the team race has been won, a next operation section 181 marked with "NEXT" is displayed. When the next operation section 181 of the team race comprehensive result screen 180 is operated, the game screen 70 for the next turn is displayed.

FIG. 16C is a second diagram illustrating the team race detailed result screen 170. FIG. Here, as shown in FIG. 16C, the case is shown in which there are 2 wins and 3 losses in each race. FIG. 16D is a second diagram illustrating the team race overall result screen 180. FIG. As shown in FIG. 16C, when each race has 2 wins and 3 losses, the team race overall result screen 180 reports that the team has lost the race.

Also, on the team race overall result screen 180 that reports that the team has lost the team race, a continue operation section 182 labeled "Continue" and a finish operation section 183 labeled "Finish" are displayed.

When the continue operation unit 182 is operated, the result of the team race is discarded and five team races are restarted from the beginning. It should be noted that the number of continuations may be set within a predetermined maximum number of continuations.

Also, when the finish operation unit 183 is operated, the game is over and the breeding game ends. However, the next operation section 181 may be displayed without displaying the continue operation section 182 and the finish operation section 183 on the team race comprehensive result screen 180 informing that the team has lost the team race. That is, even if the team race is defeated, the training game may continue without game over.

FIG. 17 is a diagram explaining the relationship between team members and sub-members. Hereinafter, a character registered as a team member and a character registered as a sub-member may be simply referred to as a team member and a sub-member, respectively. In this embodiment, a sub member may be promoted to a team member as the training game progresses.

Specifically, when a player runs an individual race or a team race, sub-members may run as guest characters. In an individual race or a team race, if the main character or team member entered by the player is ranked higher than a predetermined rank, the guest character is promoted to a team member.

In other words, here, the team members are notified that the sub-member will run as a guest character in an individual race or a team race, and that the main character or the team member will finish in a predetermined order or higher in the race in which the guest character has run. promotion, that is, it is set as a registration condition for team members. The predetermined ranking, which is a registration condition, can be, for example, third place. However, the predetermined order may differ for each individual race or team race, and the predetermined order may be determined by lottery.

It should be noted that the registration conditions for promoting a sub-member to a team member are merely an example. For example, the registration condition may be set such that the player's team wins in a team race in which sub-members run as guest characters. Also, for example, a parameter for promotion to a team member may be provided for each sub-member, and the registration condition may be set such that this parameter is equal to or greater than a threshold. In this case, the conditions for increasing the parameter are not particularly limited. For example, sub-members may be assigned to various types of training, and the parameters may be raised by performing joint training with the sub-members.

As described above, in the breeding main game, the number of team members can be gradually increased as the game progresses. At this time, the game feature of the present embodiment is to promote a character with a higher ability parameter to a team member, and advance the team competition advantageously.

FIG. 18 is a diagram for explaining the general flow of processing at the start of a turn. The breeding stage processing includes turn start processing that is executed at the start of each turn of the breeding game. The details of the turn start processing will be described later, but here, the general flow of the turn start processing will be described.

In the turn start processing, as shown in FIG. 18, "processing for determining presence/absence of placement of team members", "processing for determining training items to be deployed", "processing for determining increase value of ability parameters", "processing for appearance A process for determining an event" and a "process for determining a guest character" are executed. These processes will be described in order below.

<Processing to determine whether or not to assign team members>
FIG. 19 is a diagram for explaining the arrangement presence/absence table. As shown in FIG. 19, in the placement presence/absence table, a selection ratio of placement presence/absence (“place” or “not place”) is set for each character identification information of a character. In this embodiment, based on the arrangement presence/absence table shown in FIG. 19, the character identification information table shown in FIG. 8 or 9 is referenced to determine the arrangement presence/absence for all team members.

Specifically, as shown in FIG. 19, in the present embodiment, team members registered as "support character" and "specific character" as the character identification information have an 80% probability of being "arranged". selected. For a team member registered as a "specific character" as character identification information and not registered as a "support character", "arrange" is selected with a probability of 60%.

Also, for a team member registered as a "support character" as character identification information and not registered as a "specific character", "arrange" is selected with a probability of 40%. Also, for a team member for which neither "support character" nor "specific character" is registered as character identification information, "arrange" is selected with a probability of 10%.

Thus, team members registered as support characters are more likely to be placed in training than team members not registered as support characters. A team member registered as a specific character is more likely to be placed in training than a team member not registered as a specific character.

<Processing to determine training items to be placed>
Next, for the team members determined to be arranged as described above, "Speed" (speed), "Stamina" (stamina), "Power" (power), "Spirit" (guts), "Wisdom" It is determined which training item (wisdom) to place.

The method of determining the training items to be arranged is not particularly limited, but for example, a lottery may be performed so that each training item is won with an equal probability. Alternatively, the character may be arranged in a preset training item for each character without performing a lottery. Also, for example, a lottery may be conducted to make it easier for the character to be placed in the character's specialty training (see FIG. 7A). When performing a lottery, a lottery table in which selection ratios in the lottery are determined may be stored in advance, or a lottery table may be created each time a lottery is held.

<Processing to determine the increase value of the ability parameter>
FIG. 20A is a diagram explaining a training level table. As shown in FIG. 20A, the training level is set to increase as the team ranking increases. Specifically, if the team ranking is 100th or lower, "Speed" (speed), "Stamina" (stamina), "Power" (power), "Spirit" (guts), "Wisdom" (wisdom) ) is set to "Level 1" and the team ranking is 99th or higher and 60th or lower, each training level is set to "Level 2" and the team ranking is 59th or higher. And if it is 30th or lower, each training level is set to "level 3", and if the team ranking is 29th or higher and 10th or lower, each training level is set to "level 4", When the team ranking is ninth or higher, each training level is set to "level 5".

In this embodiment, the training level is set to increase as the team ranking increases, but the training level is not limited to this. For example, a team member's favorite training may be counted for each training item, and the training level may be increased according to the counted value (count value). Here, it is assumed that all training items have the same training level for the team ranking, but the same team ranking may have different training levels for each training item.

In this embodiment, when the training selected by the player is executed successfully, the executed training item raises the value of the predetermined ability parameter.

Specifically, in this embodiment, "Speed" training is performed, and if successful, the values of the "Speed" and "Power" ability parameters increase.

In addition, "Stamina" training is executed, and if successful, the values of the "Stamina" and "Spirit" ability parameters increase.

Also, "Power" training is performed, and if successful, the values of the "Stamina" and "Power" ability parameters increase.

In addition, "Spirit" (guts) training is performed, and if it succeeds, the values of the ability parameters of "Speed" (speed), "Power" (power), and "Spirit" (guts) will increase. do.

Also, "Wisdom" training is performed, and if successful, the values of the "Speed" and "Wisdom" ability parameters increase.

In this embodiment, the value of the ability parameter that increases when training is successful is a value obtained by multiplying a fixed increase value determined corresponding to the training item and training level performed by a bonus addition rate described later. Calculated by adding to a fixed value.

FIG. 20B is a diagram illustrating an upward fixed value (speed) table. Also, FIG. 20C is a diagram for explaining an upward fixed value table (power). That is, FIG. 20B shows the rising fixed value when the training item is "Speed". Also, FIG. 20C shows the rising fixed value when the training item is "Power".

As shown in FIGS. 20B and 20C, the fixed rise value table stores the fixed rise value determined corresponding to the exercise item and training level performed. In addition, in this embodiment, as shown in FIGS. 20B and 20C, the higher the training level, the greater the increase in the ability parameter.

Here, although description is omitted, rising fixed value tables are also provided when "Stamina" (stamina), "Spirit" (guts), and "Wisdom" (wisdom) are selected as training items. ing.

Also, in addition to the fixed increase value described above, the bonus addition rate is determined based on the character arranged for each training item and the character identification information table shown in FIG. 8 or 9 described above.

FIG. 20D is a diagram explaining a bonus addition rate table. In this embodiment, the bonus addition rate is determined based on the character identification information of the character whose placement is determined for each training.

Specifically, as shown in FIG. 20D, in the bonus addition rate table, the presence or absence of the bonus addition rate and the selection ratio of the addition rate (10% increase or 20% increase) are set for each character identification information of the character. ing.

When "support character" and "specific character" are registered as character identification information, "none" is selected with a probability of 50%, and "up by 20%" is selected with a probability of 50%.

Further, when only "support character" is registered as the character identification information, "none" is selected with a probability of 50%, and "up by 10%" is selected with a probability of 50%.

Further, when only "specific character" is registered as the character identification information, "none" is selected with a probability of 50%, and "up by 10%" is selected with a probability of 50%.

Also, when neither "support character" nor "specific character" is registered as character identification information, "None" is selected with a probability of 80%, and "10% up" is selected with a probability of 20%. be done.

Then, a value obtained by multiplying the fixed increase value determined by the fixed increase value table by the bonus addition rate is derived as the added bonus value. The value obtained by adding the bonus additional value to the fixed increase value is determined as the amount of increase in the value of the ability parameter when the training is successful. For training in which a plurality of characters are arranged, the additional bonus value of each of the arranged characters is added to the fixed increase value. In this way, the amount of increase in the ability parameter of the main character when the training is successful is determined for all training types.

<Processing to determine occurrence event>
FIG. 21 is a diagram for explaining event types and event classifications. During the breeding main game, a process of determining whether or not to cause an event to appear is performed in each turn. Events are broadly classified into four types: scenario events, the above-mentioned dedicated events 42a provided for each main character, support events, and team member events. In each scenario, a scenario event, a dedicated event 42a, a support event, and a team member event that may appear during the training main game are predetermined.

A scenario event is an event set for each scenario of the training main game. As described above, in this embodiment, multiple scenarios are provided, and the player can select a scenario. A scenario event appears for each scenario selected by the player. In other words, the scenario event that appears in the training main game is determined based on the scenario selected by the player.

Scenario events may include scenario-specific events and scenario-common events. A scenario-specific event is an event linked to only one scenario. For example, a scenario-specific event linked to a first scenario appears only when the first scenario is selected, and does not appear when another scenario is selected.

A common scenario event is an event that appears in common in a plurality of scenarios. Therefore, the scenario common event appears both when the first scenario is selected and when the second scenario is selected.

Here, scenario-specific events and scenario-common events are provided as scenario events. However, only one of the scenario-specific event and the scenario-common event may be provided.

The dedicated event 42a is an event preset for each character, as described above. In the breeding main game, a special event 42a for a character registered by the player as a main character in the setting game, ie, the preparation stage process, appears.

A support event is an event preset for each support card, as described above. In the training main game, a support event appears that is tied to the support card registered by the player in the setting game. Also, apart from the support event linked to the registered support card, for example, a support event linked to the team member may appear. However, the probability that the support event associated with the support card registered by the player in the setting game is determined is set higher than the probability that other support events are determined.

A team member event is an event that appears mainly when a team member is assigned training, that is, joint training is performed. Team member events may also appear when certain conditions are met, regardless of training.

In this way, whether or not a scenario event appears is determined based on the scenario. Also, whether or not the special event 42a, the support event, and the team member event appear is determined based on the main character, the support card, and the team member, respectively. In other words, the event types are classified according to information referred to when determining whether or not an event appears.

In contrast, in this embodiment, each event is classified into one of five event classifications depending on the content brought about by the occurrence of the event. Here, each event is classified into one of the event classifications of hint event, ability event, aptitude event, story event, and special training event.

As described above, a hint event is an event that makes it possible to possess or acquire a skill. Also, the ability event is an event that increases or decreases the ability parameter of the main character. An aptitude event is an event that increases or decreases the aptitude parameter of the main character. A story event is an event that displays a story related to a character appearing in the breeding game. Note that some story events change ability parameters and aptitude parameters in addition to the display of the story. A special training event is an event that raises a team member's ability parameters.

Scenario events include hint events, ability events, aptitude events, and story events. The dedicated events 42a and support events also include hint events and ability events. Team member events include story events and special training events. Note that the relationship between event types and event classifications shown in FIG. 21 is merely an example. Therefore, for example, the dedicated events 42a may include story events and special training events.

FIG. 22 is a diagram explaining the relationship between the event type and the number of turns. FIG. 22 shows an example of a case where a predetermined character is registered as a main character when the training main game of the first scenario is executed. Whether an event appears or not is determined based on an event determination table provided for each scenario.

Here, the event determination table includes an event appearance determination table and an event content determination table. In the event occurrence determination table, information indicating whether or not an event will appear, information indicating the probability of an event appearing, and the like are associated with each turn. Here, it is assumed that information indicating whether or not an event appears and information indicating the probability of an event appearing are defined for each type of event for all turns.

In the event content determination table, events to appear or events that can appear are set in advance for each turn and for each type of event.

At the start of a turn, the event occurrence determination table is referenced, and first, whether or not to cause an event to appear is determined for each event type. At this time, depending on the number of turns and the type of event, the "appearance" of the event may always be determined. Also, depending on the number of turns and the type of event, for example, it may be specified that the event appears with a probability of 50%. In this case, a lottery is conducted in which the "appearance" of the event is determined with a probability of 50%.

Then, for the type of event for which "appearance" has been determined, the content of the event to appear is determined by referring to the event content determination table. For example, according to the event appearance determination table for the first scenario, it is set that the scenario event must appear in the first turn. An event ID is assigned to each event. In the event content determination table for the first scenario, the scenario event with event ID=0001 is associated with the first turn as an event that can appear. Therefore, when the breeding main game of the first scenario is played, the scenario event with the event ID=0001 always appears in the first turn.

Similarly, according to the event determination table (event occurrence determination table and event content determination table) of the first scenario, at turns 4, 5, 6, 7 and 10, event It is decided to make scenario events with ID=0002, 0003, 0004, 0005, 0006 appear.

Here, each event is roughly classified into a fixed event and a random event. A fixed event is an event whose appearance turn is fixed, in other words, an event that can appear in a predetermined turn and will not appear in any turn other than the predetermined turn. Here, scenario events with event IDs=0001, 0002, 0003, 0004, 0005, and 0006 are all fixed events and scenario-specific events.

On the other hand, a random event is an event that appears when it is determined to appear and is determined as an event to appear. In FIG. 22, it is determined by lottery whether or not the event will appear in the turn labeled "lottery", and if "appearance" is determined, the event won by lottery will appear from among the random events. indicates that

In the event content determination table, an event ID to be selected by lottery is set for a turn in which an event won by lottery appears. For example, assume that random events with event IDs=0010, 0011, and 0012 are provided as scenario events in the first scenario. It is also assumed that the scenario event with event ID=0010 is associated with the 12th turn in the event content determination table.

In this case, at the start of the 12th turn, a lottery is held to determine whether or not the scenario event will appear. Then, if the lottery is won, the scenario event with the event ID=0010 appears, and if the lottery is not won, the scenario event does not appear.

Also, for example, assume that scenario events with event IDs=0010, 0011, and 0012 are associated with the fifteenth turn in the event content determination table. When the event is won by lottery as to whether or not to make the event appear, the scenario event to appear is determined by lottery from the events of event ID=0010, 0011, 0012, and the scenario event won by lottery appears.

Here, the case where fixed events and random events are exclusively provided has been described. However, when the scenario event to appear is determined by lottery, a fixed event may be set as the object of the lottery in addition to or instead of the random event.

Here, in this embodiment, the fourth to seventh turns are set as branch turns. A branch turn means a turn in which the contents of an event are changed when a predetermined condition is satisfied. Here, as a predetermined condition, it is set that a predetermined number of specific characters are included in the team members, in other words, that a predetermined number of specific characters are included in the main characters or support characters.

Specifically, in the fourth turn, it is determined whether four specific characters are included in the team members as the predetermined number. Then, when four specific characters are included in the team members, the scenario event is replaced with the team member event. The team member event includes a specific character event provided for each specific character. Here, if the team member includes a specific character, the scenario event is replaced with the specific character event in the branch turn.

Similarly, in the 5th, 6th and 7th turns, it is determined whether the team members include a predetermined number of 3, 2 and 1 specific characters, respectively. Then, when each team member includes a predetermined number of specific characters, the scenario event is replaced with the specific character event.

Specifically, scenario events with event IDs=0002, 0003, 0004, and 0005 are story events. In these story events, a story is reproduced in which a team member thinks of a team name, but ends without a team name being proposed. Therefore, if the specific character is not included in the team members, the team name will not be proposed for four consecutive turns.

On the other hand, when specific characters are included in the team members, scenario events are replaced with specific character events by the number of specific characters. A specific character event is a story event. In the specific character event, a story in which a specific character proposes a team name is reproduced. Four specific characters are provided, and a different team name is proposed for each specific character. Therefore, when the specific character is included in the team members, the same number of team names as the specific character will be proposed from the 4th turn to the 7th turn.

Also, the scenario event with event ID=0006 that appears in the tenth turn is a story event. In this story event, a story is reproduced that prompts the player to select a team name. Here, a total of five types of team names are provided by adding a preset default team name to the four team names proposed by the four specific characters.

If the team members do not include a specific character and no team name is proposed from the 4th turn to the 7th turn, the team name that can be selected by the player in the 10th turn is the default team. name only. In this case the player must choose the default team name. Also, for example, when two team names are proposed from the fourth turn to the seventh turn, the player chooses one of three team names, the two proposed team names and the default team name. Any one can be selected from.

The team name selected by the player in the tenth turn is registered as the official team name, and is used in various situations until the training main game ends. Note that a privilege corresponding to the registered team name may be given to the player at a predetermined timing until the training main game ends. Benefits given to the player include, for example, acquisition of skills corresponding to the registered team name, increases in ability parameters and aptitude parameters, acquisition of in-game currency, and the like.

Thus, the scenario events with event IDs=0002, 0003, 0004, 0005, and 0006 and the specific character events that are replaced from the 4th turn to the 7th turn are all scenario-specific events. A scenario ID is managed in association with an event ID that can appear. Therefore, the scenario events and specific character events appearing in the 4th to 7th turns and the 10th turn are linked only to one scenario ID.

Further, according to the event determination table of the first scenario, dedicated events 42a with event IDs=1001 and 1002 appear in the second turn and the eighth turn, respectively. Further, according to the event determination table of the first scenario, in turns 3 to 7, 9, 11, and 12, the presence or absence of the dedicated event 42a and the appearance of the dedicated event 42a are determined. It is decided by lottery.

Here, the dedicated event 42a differs for each character. Also, the relationship between the number of turns and the appearing dedicated event 42a is set for each character. Therefore, the turn in which the dedicated event 42a appears and the dedicated event 42a that appears in each turn differ depending on the character registered as the main character.

Also, as shown in FIG. 22, in the event determination table of the first scenario, it is set that whether or not a support event will appear and the content of the support event to appear will be determined by lottery in a given turn. . As for the support event, the event ID that can be won by lottery may be different for each turn, or may be common for all turns.

In the lottery for determining whether or not a support event will appear, the probability of "appearance" being determined is not affected by the registered support cards. In other words, in each turn, the probability of determining that a support event will appear is common regardless of which support card is registered. On the other hand, when the "appearance" of the support event is determined, the content of the support event is determined, but at this time, the probability that the content of the support event is determined changes depending on the registered support card. .

Specifically, when the "appearance" of a support event is determined, the event IDs of support events that can appear in the turn are extracted based on the event content determination table. Then, a lottery table is generated based on the extracted event IDs, and one event ID is determined based on the generated lottery table.

The extracted event IDs include the event ID of the support event linked to the registered support card and the event ID of the support event not linked to the registered support card. There is In this case, in the lottery table, the winning probability of the event ID of the support event linked to the registered support card is higher than the winning probability of the event ID of the support event not linked to the registered support card. is also set higher. As a result, the support event linked to the registered support card has a higher appearance probability than other support events.

Thus, in each turn, the support event appearance probability is not affected by the registered support cards, but the content of the support event that appears is affected by the registered support cards.

However, the probability of a support event appearing itself or the content (type) of a support event appearing itself may vary depending on the registered support card. In other words, the number or occurrence probability of events occurring during the breeding main game may differ depending on the registered support card.

Also, in each turn, whether a team member event will appear or not is determined by a lottery. Lottery-determined team member events are limited to intensive training events. Below is a detailed description of the special training event.

FIG. 23A is a third diagram illustrating the game screen 70. FIG. FIG. 23A shows a case where a special training event appears in the turn. In this case, an event notification display 87 is displayed on the training operation section 76 of the game screen 70 as shown in FIG. 23A.

FIG. 23B is a third diagram illustrating the training screen 80. FIG. When the training operation section 76 of the game screen 70 is operated, a training screen 80 is displayed on the display 26 . When a special training event occurs corresponding to the character displayed on the icon 88 of the training screen 80, an event notification display 87 is displayed on the icon 88 of the corresponding character.

Also, as shown in FIG. 23B, a bond gauge 88a and a special icon 88b are displayed for each character icon 88 placed in training. The bond gauge 88a indicates a parameter (hereinafter referred to as a bond parameter) that increases according to the number of joint trainings performed with the character of the corresponding team member. This bond parameter is initially set to 0 and increases up to 100. The bond gauge 88a visually indicates the value of the bond parameter.

Also, the special icon 88b indicates the number of executions of the special training event for the character of the corresponding team member. Although the details will be described later, the special icon 88b is displayed in a display mode according to the number of completed special training events for the character of the icon 88 on which the special icon 88b is displayed.

FIG. 24A is a diagram for explaining a special training event execution presence/absence determination table. When it is decided that a team member will be assigned to each training item, whether or not a special training event will be performed for each team member assigned to each training item is determined by lottery based on the special training event execution/non-execution decision table shown in FIG. 24A. It is determined. Hereinafter, the team member for whom execution of the special training event has been decided is also referred to as a special training target team member.

Specifically, as shown in FIG. 24A, the selection probability of execution/non-execution of the special training event is set based on the value of the bond parameter of the team member for special training. Here, the selection probability is set such that the larger the value of the bond parameter, the more likely the execution of the special training event is selected. In addition, the same number of special training events as the number of team members who won the lottery can appear. However, for one training item, a limit may be set for the number of team members who are subject to special training that can appear at the same time.

FIG. 24B is a diagram explaining a special icon determination table. The special training event includes a “successful” execution pattern and a “great success” execution pattern. For each special training target team member, when the special training event is executed for the fifth time, the special training event is always executed with the execution pattern of "great success". On the other hand, when a special training event other than the fifth special training event is executed for each special training target team member, the special training event is always executed with a "successful" execution pattern. That is, a special training event can be executed only once with the execution pattern of "great success" for one special training target team member. It should be noted that the event notification display 87 varies depending on the content of the special training event to be executed ("success" execution pattern or "great success" execution pattern) and the number of team members for whom execution of the special training event has been decided. may be displayed as

As shown in FIG. 24B, when the execution count of the special training event related to the character of each team member for special training is 0 to 4 times, that is, when the special training event has not yet been executed with the execution pattern of "great success". , the special icon 88b is displayed in a larger size as the number of executions of the special training event increases.

It should be noted that it is also possible to determine by lottery whether the execution pattern of the special training event should be "successful" or "successful". In this case, the lottery probability may be set such that the greater the number of executions of the special training event related to the team member subject to special training, the more likely the execution pattern of "great success" will be selected. In this case, the larger the size of the special icon 88b, the more likely it is that the "great success" execution pattern will be selected. Become.

In addition, after the special training event is executed in the execution pattern of "great success", that is, when the special training event related to the special training team member is executed 5 times or more, the special training event related to the special training team member The special icon 88b is displayed in a larger size than when the number of executions is 0 to 4, and as shown in FIG. Suggestion display a is displayed.

Also, when a special training event appears and the special training event has a "successful" execution pattern, the ability parameter of the team member subject to special training and the ability parameter of the main character rise within a predetermined range. Further, when the special training event has a "great success" execution pattern, the ability parameter of the team member to be specially trained and the ability parameter of the main character increase significantly beyond the predetermined range.

Further, as shown in FIG. 23B, when execution of the special training event is decided, the status display portion 73 of the training screen 80 displays a bonus icon 88c indicating a value by which the ability parameter of the main character is increased by the special training event. .

FIG. 24C is a diagram explaining a bonus icon determination table. The bonus icon 88c is displayed in different sizes according to the value by which the main character's ability parameter increases due to the special training event. Here, the bonus icon 88c is displayed in a larger size when the ability parameter of the main character is increased by the special training event when it is 20-39 than when it is 0-19. Also, the bonus icon 88c is displayed in a larger size when the ability parameter of the main character is raised by a special training event of 40 or more than when it is 20-39.

FIG. 25A is a diagram illustrating a fixed bonus value (main character) table. When the above-described special training event is executed, a value (bonus fixed value) by which the ability parameter of the main character is increased by the special training event is determined according to the number of team members for whom execution of the special training event is decided. Here, as shown in FIG. 25A, the value (fixed bonus value) by which the ability parameter of the main character is raised by the special training event is set to increase as the number of team members determined to execute the special training event increases. ing.

FIG. 25B is a diagram illustrating a bonus additional value (main character) table. When a special training event is executed with a "great success" execution pattern, in addition to the above fixed bonus value, the special training event with a "great success" execution pattern increases the ability parameter of the main character (bonus addition value) is determined. Here, as shown in FIG. 25B, a value (bonus addition value) is set to increase the ability parameter of the main character according to the special training of the team member whose special training event is executed in the execution pattern of "great success". ing. That is, the value by which the ability parameter of the main character increases due to the special training event is the sum of the fixed bonus value and the added bonus value.

FIG. 26A is a diagram illustrating a fixed increase value (for special training) table. When the special training event described above is executed, the value (fixed increase value) by which the ability parameter of the team member subject to special training is increased by the special training event is determined. Here, as shown in FIG. 26A, a range of values (fixed increase values) for increasing the ability parameter of the team member subject to special training is set according to the type of training performed. Here, a value (fixed increase value) within the range set in FIG. 26A is determined by lottery.

FIG. 26B is a diagram illustrating a bonus increase value (special training target) table. When a special training event is executed with the execution pattern of "great success", in addition to the above-described fixed increase value, a value (bonus increase value) by which the ability parameter of the team member subject to special training is increased by the special training event is determined. Here, as shown in FIG. 26B, a value (bonus rising value) is set.

In addition, if a special training event is executed with the execution pattern of "great success", depending on the number of special training events (number of times) with the execution pattern of "great success" that is executed at the same time, the number of team members who are subject to special training will be increased. An increase event may be executed in which the ability parameter or the main character's ability parameter increases. For example, the higher the number of special training events (number of times) in the execution pattern of "great success" that is executed at the same time, the larger the value that increases the ability parameters of the team members who are subject to special training and the ability parameters of the main character. can be

As described above, when a special training event appears, the ability parameters of the main character and the team member subject to special training increase. If the main character or the team member for special training is a specific character, the fixed increase value or the bonus increase value may be multiplied by a predetermined addition rate. In other words, when the main character or the team member for special training is the specific character, the ability parameter increases more than when the character is not the specific character.

<Processing to determine the guest character>
In the process of determining a guest character, a first lottery is performed to determine whether or not to set a guest character. If the first lottery is unsuccessful, the guest character is not set in that turn.

On the other hand, when the first lottery is won, and when the first lottery is not won in the last two consecutive turns (the previous turn and the turn before last), the guest character is set. However, the total number of characters registered as team members must be 21 or more even if the first lottery is won, and even if the first lottery is not won in the two most recent consecutive turns. In this case, guest characters are not set.

When the guest character is set, first, among the current team members, the aptitude type with the smallest number of A aptitudes is extracted and determined. If there are a plurality of aptitude types with the smallest number of A aptitudes, the aptitude types are extracted and determined based on preset priorities. Here, the order of priority is "short distance">"mile">"medium distance">"long distance">"dirt".

Then, sub-members whose aptitude type is "A" are extracted, and a first lottery table is generated based on the extracted sub-members. Next, a second lottery table is generated by excluding the sub-members included in the first lottery table from among the sub-members. Which of the first lottery table and the second lottery table generated as described above is used is determined by lottery, and the guest character is selected using the determined lottery table (first lottery table or second lottery table). decide.

In addition, the selection ratio of the first lottery table and the second lottery table is not particularly limited. For example, the first lottery table may be set to be more easily selected than the second lottery table, or the second lottery table may be set to be more easily selected than the first lottery table. .

Then, using the selected lottery table, guest characters to be set for the individual race or team race are determined and registered. Here, guest characters are set for both individual races and team races. However, guest characters may be set only for team races, or may be set only for individual races.

FIG. 27A is a fourth diagram illustrating the game screen 70. FIG. After transitioning to the training stage process, the game screen 70 shown in FIG. 27A is displayed on the display 26 . When a guest character is set for an individual race as described above, a guest icon 70a indicating the guest character and a guest notification display 70b are displayed on the game screen 70 so as to be superimposed on the individual race operation section 79a of the game screen 70. . When a guest character is selected for the team race, a guest icon 70a indicating the guest character and a guest notification display 70b are displayed on the game screen 70 in a superimposed manner on the team race operation section 79b.

FIG. 27B is a second diagram illustrating the individual race selection screen 100. FIG. When the individual race operation section 79a of the game screen 70 is operated, the individual race selection screen 100 shown in FIG. 27B is displayed.

On the individual race selection screen 100, a guest icon 70a and a guest notification display 70b are displayed so as to be superimposed on the individual race selection operation section 101 corresponding to the individual race in which the guest character is set.

Here, as shown in FIG. 27B, the case where a guest character is set in one individual race selection operation section 101 is shown. However, a guest character may be set for each of a plurality of individual races in one turn. Also, guest characters may be set for all individual races selectable by the player. When a guest character is set for a plurality of individual races, a different guest character may be set for each individual race, or the same guest character may be set for a plurality of individual races.

Also, a guest character may be set for each of a plurality of team races in one turn. Also, guest characters may be set for all team races selectable by the player. When guest characters are set for a plurality of team races, different guest characters may be set for each team race, or the same guest character may be set for a plurality of team races.

As described above, in the training main game, the player can increase the number of team members as turns progress. Also, the player can increase the ability parameters of the main character and team members as turns progress. Ability parameters increase due to successful training or the appearance of various events. As described above, in training, if a specific character is placed in a training item, a bonus additional value is added.

Further, although detailed explanation is omitted, if the main character or support character is a specific character, a predetermined bonus addition value is added when the ability event appears. Therefore, by registering a specific character as a main character or a support character, the player can advantageously proceed with the training main game.

Also, if the team member includes a specific character, a specific character event will occur in the branch turn. Therefore, by registering a specific character as a main character or a support character, the player can expand the options in the game and improve the interest in the game.

Thus, the specific character plays an important role in the training main game. Therefore, in the present embodiment, a specific character is identifiably displayed in the setting game so that the main character and support cards can be appropriately selected.

FIG. 28A is a diagram illustrating the scenario top screen 190. FIG. As described above, when the first scenario is selected on the scenario selection screen, the scenario top screen 190 of the first scenario shown in FIG. 28A is displayed. The scenario top screen 190 displays a character image set as a specific character in the first scenario. A detailed icon 191 is also displayed on the scenario top screen 190 . When the detail icon 191 is tapped, a specific character explanation dialog 192 is displayed.

FIG. 28B is a first diagram for explaining the specific character explanation dialog 192. FIG. FIG. 28C is a second diagram for explaining the specific character explanation dialog 192. As shown in FIG. As shown in FIG. 28B, in the specific character explanation dialog 192, the utility brought by the specific character during the training main game is described for each specific character. In this embodiment, it is stipulated that the utility brought about by the specific character is that the content of the event is changed (predetermined event appears) and that a predetermined parameter is changed. Therefore, in the specific character explanation dialog 192, a display is made for each specific character to the effect that the contents of the event and the predetermined parameters will be changed. This specific character explanation dialogue 192 provides information for the player to make a decision when selecting a training main character or a support card.

Further, the specific character explanation dialogue 192 is provided with a check box 192a. The check box 192a is used to switch between a permitted state in which the character set as the specific character can be identified and displayed, and a non-permitted state in which the character set as the specific character is not identified. belongs to.

Specifically, when the disallowed state is set, as shown in FIG. 28B, the check box 192a is not marked with a check mark. In this state, when the player taps the check box 192a, the permission state is set, and a check mark is displayed in the check box 192a as shown in FIG. 28C. It should be noted that a check box 192a is provided in the specific character explanation dialog 192 here. However, the check box 192a may be provided on a setting screen on which the player can make various settings.

Further, the specific character explanation dialogue 192 is provided with a close operation section 192b. When the close operation portion 192b is tapped, the specific character explanation dialog 192 is closed and the scenario top screen 190 shown in FIG. 28A is displayed. Note that the scenario top screen 190 is provided with a return operation section 193 and a determination operation section 194 . When the return operation unit 193 is tapped, a scenario selection screen (not shown) is displayed. Also, when the determination operation section 194 is tapped, the main character selection screen 30 is displayed.

FIG. 28D is a second diagram for explaining the main character selection screen 30. FIG. As described above, the main character selection screen 30 is a screen for selecting a main character, and displays character icons 31 corresponding to characters possessed by the player. At this time, if the permission state is set, a specific mark 31a is superimposed on the character icon 31 corresponding to the specific character. Thus, the character set as the specific character is identified and displayed by the specific mark 31a.

Since the character set as the specific character is identifiably displayed, the player can easily select the specific character as the main character, thereby improving convenience. Note that when the non-permission state is set, the specific mark 31a is not displayed as shown in FIG. 4B.

Depending on the player, there are cases where the character that the player wants to train has been decided. In such a case, if the specific mark 31a is displayed, the player may feel a sense of loss and lose motivation to play the game. In this embodiment, since the player can select whether or not to display the identification of the specific character, an appropriate display is provided for each player or for each purpose of the player playing the game.

Although illustration is omitted, the specific mark 31a is also displayed on the support card selection screen 60 when the permission state is set. As described above, each support card is always associated with one character. In the support card selection screen 60, a specific mark 31a is superimposed on the icon 61 of the support card associated with the character set as the specific character.

Here, when the permitted state is set, the identification display of the specific character is performed in the setting game, but the identification display of the specific character may also be performed, for example, during the breeding main game. Further, for example, the specific character may not be identified and displayed during the setting game, and the specific character may be identified and displayed only during the training main game. In this case, for example, the player can understand that the amount of increase in the ability parameter is high depending on the specific character, which can be used as a reference when selecting the main character or support card from the next time onward.

Further, for example, when a specific character is set as a guest character in an individual race, the identification display of the specific character provides information for determining whether or not to run the individual race.

Note that the character set as the specific character in the selected scenario may be identified and displayed at least after the scenario is selected, and the timing and display mode are not particularly limited. Note that the initial state may be a permitted state or a non-permitted state.

FIG. 29 is a diagram for explaining specific character information. The specific character information includes the character ID given to the character set as the specific character among the multiple types of characters that can be used as the main character and the support character in the training main game of each scenario, and the character ID given to the scenario. This information is associated with the scenario ID. As shown in FIG. 29, in the specific character information, the character ID of the character set as the specific character is associated with each scenario ID.

The specific character information is stored in the server 1000 by the administrator. Also, the player terminal 1 downloads the specific character information stored in the server 1000 at a predetermined timing. The player terminal 1 saves the specific character information downloaded from the server 1000 in the storage section 18 . Further, at the start of the breeding game, the specific character information is read out from the storage section 18 and held in the memory 12 . During the breeding game, processing is performed based on the specific character information held in the memory 12 .

Next, functional configurations of the player terminal 1 and the server 1000 for executing the above game will be described. It should be noted that the functional configuration related to the progress of the game will be mainly described here, and the description of other configurations will be omitted.

(Functional Configuration of Player Terminal 1)
FIG. 30 is a diagram for explaining the configuration of the memory 12 in the player terminal 1 and its function as a computer. The memory 12 is provided with a program storage area 12a and a data storage area 12b. When the game is started, the CPU 10 stores a terminal-side game control program (module) in the program storage area 12a.

The terminal-side game control program includes a transmission/reception program 200, a character lottery program 202, a player information update program 204, a necessary information registration program 206, a scenario selection program 208, a state information registration program 210, a preparatory stage processing program 212, and registration information storage. A program 214, a developmental stage processing program 216, and an event determination program 218 are included. Note that the programs listed in FIG. 30 are only examples, and many other programs are provided in the terminal-side game control program.

The data storage area 12b is provided with a player information storage unit 300, a specific character information storage unit 302, a state information storage unit 304, a registration information storage unit 306, and a breeding game information storage unit 308 as storage units for storing data. there is In addition, the data storage area 12b is provided with a large number of other storage units.

The CPU 10 operates each program stored in the program storage area 12a and updates the data in each storage section of the data storage area 12b. Then, the CPU 10 causes the player terminal 1 (computer) to function as the terminal-side game control section 1A by operating each program stored in the program storage area 12a. The terminal-side game control unit 1A includes a transmission/reception unit 200a, a character lottery unit 202a, a player information update unit 204a, a necessary information registration unit 206a, a scenario selection unit 208a, a state information registration unit 210a, a preparation stage processing unit 212a, and a registration information storage unit. 214a, a growing stage processor 216a, and an event determiner 218a.

Specifically, the CPU 10 operates the transmission/reception program 200 to cause the computer to function as the transmission/reception unit 200a. Similarly, the CPU 10 includes a character lottery program 202, a player information update program 204, a necessary information registration program 206, a scenario selection program 208, a status information registration program 210, a preparatory stage processing program 212, a registered information storage program 214, and a training stage processing program. 216, the event determination program 218 is operated, and the character lottery section 202a, the player information update section 204a, the necessary information registration section 206a, the scenario selection section 208a, the state information registration section 210a, the preparation stage processing section 212a, and the registration information storage section 214a. , a training stage processing unit 216a, and an event determination unit 218a.

The transmitting/receiving unit 200 a communicates between the player terminal 1 and the server 1000 and transmits various information from the player terminal 1 to the server 1000 . Also, the transmission/reception unit 200 a downloads various information from the server 1000 .

The character lottery unit 202a executes processing for requesting the server 1000 to draw a character or a support card based on the player's operation.

The player information update unit 204 a updates player information stored in the player information storage unit 300 in the player terminal 1 .

The necessary information registration unit 206a stores necessary information such as various tables required for the breeding game in the data storage area 12b.

The scenario selection unit 208a executes processing when the player selects a scenario for a breeding game.

The state information registration unit 210a stores permission information indicating the permission state or normal permission information indicating the non-permission state in the state information storage unit 304 based on the operation of the check box 192a by the player.

The preparatory stage processing unit 212a executes preparatory stage processing.

The registration information storage unit 214a stores the character identification information of the main character, support card, specific character, team members, and sub-members registered by the player in the preparatory stage processing in the registration information storage unit 306. FIG.

The training stage processing unit 216a executes training stage processing.

The event determination unit 218a determines an event to appear.

(Functional Configuration of Server 1000)
FIG. 31 is a diagram for explaining the configuration of memory 1012 in server 1000 and its function as a computer. The memory 1012 is provided with a program storage area 1012a and a data storage area 1012b. When the game is started, CPU 1010 stores a server-side game control program (module) in program storage area 1012a.

The server-side game control program includes a transmission/reception program 1200, a character lottery program 1202, a player information update program 1204, and a game execution control program 1206. FIG. Note that the programs listed in FIG. 31 are only examples, and many other programs are provided in the server-side game control program.

The data storage area 1012b is provided with a player information storage section 1300 and a specific character information storage section 1302 as storage sections for storing data. Note that each of the above storage units is an example, and the data storage area 1012b is provided with a large number of other storage units.

CPU 1010 operates each program stored in program storage area 1012a and updates data in each storage unit in data storage area 1012b. CPU 1010 causes server 1000 to function as server-side game control unit 1000A by operating each program stored in program storage area 1012a. The server-side game control unit 1000A includes a transmission/reception unit 1200a, a character lottery unit 1202a, a player information update unit 1204a, and a game execution control unit 1206a.

Specifically, CPU 1010 operates transmission/reception program 1200 to cause the computer to function as transmission/reception unit 1200a. Similarly, the CPU 1010 operates a character lottery program 1202, a player information update program 1204, and a game execution control program 1206 to function as a character lottery unit 1202a, a player information update unit 1204a, and a game execution control unit 1206a, respectively.

The transmission/reception unit 1200 a receives various information from the player terminal 1 . In addition, the player terminal 1 can download various information.

The character lottery section 1202a receives a request from the player terminal 1 and draws a character or support card.

The player information update unit 1204 a updates player information stored in the player information storage unit 1300 .

The game execution control unit 1206 a executes processing corresponding to the preparation stage processing and the training stage processing in the player terminal 1 .

Processing performed by each functional unit in the player terminal 1 and the server 1000 will be described below using flowcharts.

(Communication processing between player terminal 1 and server 1000)
FIG. 32 is a sequence diagram explaining basic processing of the player terminal 1 and the server 1000. As shown in FIG. In the following description, processing in the player terminal 1 will be indicated as Pn (n is an arbitrary integer). Also, processing in the server 1000 is represented by Sn (n is an arbitrary integer).

When the player performs a lottery request operation on a gacha screen (not shown), the character lottery unit 202a of the player terminal 1 executes lottery request information transmission processing (P1) for transmitting lottery request information to the server 1000. FIG. When the transmitting/receiving unit 200a of the server 1000 receives the lottery request information, the character lottery unit 1202a of the server 1000 executes lottery processing (S1), enabling the player terminal 1 to receive lottery result information indicating the lottery result. .

Although detailed explanation is omitted, the player can select and execute a character lottery or a support card lottery. In the character lottery, one of the characters is determined as the winning character. The winning character is registered as a possessed character, and thereafter the player can use it as a character to be trained, that is, as a main character in the breeding game.

Also, in the support card lottery, one of the support cards is determined as the winning card. The winning card is registered as a possessed card, and thereafter the player can use it in the breeding game.

The player information update unit 1204a of the server 1000 updates the player information stored in the player information storage unit 1300 based on the lottery result information (S2). Here, the possession information of the character or the possession information of the support card is updated.

When the transmitting/receiving unit 200a of the player terminal 1 receives the lottery result information, the character lottery unit 202a displays the lottery result shown in the lottery result information on the display 26 (P2). Also, the player information update unit 204a of the player terminal 1 updates the player information stored in the player information storage unit 300 based on the lottery result information (P3). Here, the possession information of the character or the possession information of the support card is updated.

Further, when the player operates the scenario operation section 29 of the home screen 27 (operation to start the breeding game), the transmission/reception section 200a of the player terminal 1 executes start information transmission processing (P4) for transmitting start information to the server 1000. do. When the transmission/reception unit 200a of the server 1000 receives the start information, the server-side game control unit 1000A of the server 1000 executes necessary information output processing (S3). The necessary information output process enables the player terminal 1 to receive necessary information. The necessary information includes information on various tables required for execution of the breeding game, specific character information, and the like.

The necessary information is stored in the data storage area 1012b of the server 1000 by the administrator or the like. Also, the specific character information is stored in the specific character information storage unit 1302 by the administrator or the like. When the server 1000 receives predetermined information from the player terminal 1, the server 1000 causes the player terminal 1 to download new information. For example, after the necessary information is newly stored in the server 1000 , the newly stored information is downloaded by the player terminal 1 when communication is performed with the player terminal 1 for the first time.

Therefore, the necessary information is also downloaded when the player terminal 1 logs in, for example. Further, the server 1000 may cause the player terminal 1 to download only the necessary information that is not saved in the player terminal 1 when the start information is received.

When the transmission/reception unit 200a of the player terminal 1 receives the necessary information, the scenario selection unit 208a executes scenario selection processing (P5).

FIG. 33 is a first flow chart for explaining scenario selection processing (P5) in the player terminal 1. FIG. Also, FIG. 34 is a second flowchart for explaining the scenario selection process (P5) in the player terminal 1. As shown in FIG. When the player terminal 1 receives the necessary information (YES in P5-1), the necessary information registration section 206a of the player terminal 1 stores the necessary information in the data storage area 12b (P5-2). Note that the necessary information stored here includes an event determination table in which the event ID of the event to be generated is linked to the number of turns. Further, the necessary information registration unit 206a stores the specific character information in the specific character information storage unit 302 here. Then, the scenario selection unit 208a displays a scenario selection screen on the display 26 (P5-3).

Further, when a scenario determination operation for determining one of the scenarios is input on the scenario selection screen (YES in P5-4), the scenario selection unit 208a displays the scenario top screen 190 corresponding to the determined scenario on the display 26. (P5-5).

Also, when an operation to the detailed icon 191 is input on the scenario top screen 190 (YES in P5-6), the scenario selection unit 208a superimposes a specific character explanation dialog 192 on the scenario top screen 190 on the display 26. Display (P5-7).

Further, when an operation is input to the close operation section 192b in the specific character explanation dialog 192 (YES in P5-8), the scenario selection section 208a hides the specific character explanation dialog 192 (P5-9). .

In addition, in the specific character explanation dialogue 192, when the check box 192a is operated (YES in P5-10), the state information registration unit 210a changes the state information stored in the state information storage unit 304. (P5-11). Specifically, the state information storage unit 304 holds either permission information indicating the permission state or non-permission information indicating the non-permission state. State information registration unit 210a changes the permission information to non-permission information when state information storage unit 304 stores permission information, and changes the permission information to non-permission information when state information storage unit 304 stores non-permission information. changes disallowed information to authorized information.

When an operation is input to the return operation unit 193 on the scenario top screen 190 (YES in P5-12), the scenario selection unit 208a hides the scenario top screen 190 and displays the scenario selection screen ( P5-13).

Further, when an operation is input to the determination operation unit 194 on the scenario top screen 190 (YES in P5-14), the preparatory stage processing unit 212a stores the character possession information stored in the player information storage unit 300. Load (P5-20). Further, the preparatory stage processing unit 212a generates the main character selection screen 30 based on the character possession information (P5-21).

Further, the preparatory stage processing section 212a loads the possession information of the support card stored in the player information storage section 300 (P5-22). Further, the preparatory stage processing unit 212a generates the support card selection screen 60 based on the support card possession information (P5-23).

In addition, if the state information storage unit 304 stores the state information indicating the permitted state (YES in P5-24), the preparatory stage processing unit 212a stores the specific character information stored in the specific character information storage unit 302. Load (P5-25). Then, the preparation stage processing section 212a superimposes the specific mark 31a on the main character selection screen 30 and the support card selection screen 60 based on the specific character information (P5-26).

Specifically, the preparatory stage processing unit 212a superimposes the specific mark 31a on the character icon 31 of the character set as the specific character on the main character selection screen 30 . In the support card selection screen 60, the preparatory stage processing unit 212a superimposes the specific mark 31a on the support card icon 61 associated with the character ID of the character set as the specific character.

Then, the preparation stage processing section 212a displays the main character selection screen 30 on the display 26 (P5-27).

Returning to FIG. 32, when the scenario selection process (P5) ends, the player terminal 1 executes the preparation stage process (P6).

FIG. 35 is a flow chart for explaining the preparatory stage process (P6) in the player terminal 1. FIG. The preparation stage processing section 212a of the player terminal 1 determines whether or not the main character selection screen 30 is being displayed on the display 26 (P6-1). As a result, if the main character selection screen 30 is being displayed, the process proceeds to P6-2, and if the main character selection screen 30 is not being displayed, that is, the support card setting screen 50 and the support card selection screen 60 are displayed. is being displayed, the process proceeds to P6-7.

Long press of character icon 31 on main character selection screen 30, operation of skill operation section 41 or event operation section 42 on character detail screen 40, menu bar 28 on main character selection screen 30 or character detail screen 40, return operation section 33 or the next operation unit 34 (YES in P6-2), the preparation stage processing unit 212a switches the display screen of the display 26 (P6-15).

Further, when an operation (selection operation) for the character icon 31 is input on the main character selection screen 30 (YES in P6-3), the preparatory stage processing unit 212a responds to the character icon 31 for which the selection operation has been input. The character to be played is temporarily stored in the breeding game information storage unit 308 (P6-4).

Further, when the operation (determination operation) of the next operation unit 34 is input on the main character selection screen 30 (YES in P6-5), the registration information storage unit 214a selects the character temporarily stored in P6-4. The main character is registered in the registration information storage unit 306 (P6-6).

Further, when a display switching operation that is an operation of the support card setting operation section 52, the menu bar 28, or the return operation section 53 of the support card setting screen 50 is input (YES in P6-7), the preparatory stage processing section 212a The display screen of the display 26 is switched (P6-15).

In addition, when a selection operation that is an operation of the icon 61 of the support card is input on the support card selection screen 60 (YES in P6-8), the preparatory stage processing unit 212a supports the icon 61 for which the selection operation has been performed. The card is temporarily stored in the breeding game information storage unit 308 (P6-9).

Further, when a decision operation, which is an operation of the start operation unit 54 of the support card setting screen 50, is input (YES in P6-10), the registration information storage unit 214a stores the support card provisionally stored in P6-9 above. Register in the registration information storage unit 306 (P6-11).

Further, the registration information storage unit 214a registers the character ID of the character set as the specific character based on the specific character information (P6-12).

Also, the preparatory stage processing unit 212a sets initial character identification information (P6-13).

Further, the preparatory stage processing section 212a displays the game screen 70 on the display 26 (P6-14).

Returning to FIG. 32, when the preparatory stage process (P6) ends, the raising stage process (P7) is performed.

FIG. 36 is a flow chart for explaining the training stage process in the player terminal 1. FIG. The training stage processing unit 216a of the player terminal 1 executes turn start processing (P10) if it is the start of the turn (YES in P7-1), and executes mid-turn processing (P20) if it is not the start of the turn. Run.

FIG. 37 is a flowchart for explaining turn start processing in the player terminal 1 . The breeding stage processing unit 216a updates the current number of turns stored in the breeding game information storage unit 308 (P10-1). Further, the training stage processing unit 216a refers to the selection item table (FIG. 10) stored in the data storage area 12b, and determines whether the current turn is a turn in which the item "Team Race" (team race operation unit 79b) can be selected. It is determined whether it is a (team race limited turn) (P10-2). As a result, if the turn is limited to team races (YES in P10-2), the process proceeds to P10-5, and if the turn is not limited to team races, placement processing (P11) and numerical value determination processing (P12). , the event determination process (P13) is performed in order.

Here, it is assumed that the placement process (P11), the numerical value determination process (P12), and the event determination process (P13) are executed only on the player terminal 1. FIG. However, a part or all of the arrangement processing (P11), the numerical value determination processing (P12), and the event determination processing (P13) may be executed in the server 1000. In addition, the server 1000 may execute part of the later-described processing of the arrangement processing (P11), the numerical value determination processing (P12), and the event determination processing (P13).

FIG. 38 is a flowchart for explaining placement processing in the player terminal 1. FIG. The training stage processing unit 216a refers to the character identification information table and extracts all characters registered as team members (P11-1). Then, the training stage processing unit 216a selects a character for which the processes of P11-3 to P11-7, which will be described later, have not been executed, from among the team members extracted in P11-1, as a target character to execute the process. (P11-2).

Further, the training stage processing section 216a refers to the character identification information table to confirm the character identification information of the target character selected in P11-2 (P11-3). Further, the breeding stage processing unit 216a sets the arrangement presence/absence table (FIG. 19) based on the character identification information confirmed in P11-3 (P11-4). Further, the breeding stage processing unit 216a determines "arrange" or "not arrange" by lottery based on the arrangement presence/absence table set in P11-4 (P11-5).

Then, when "arrange" is determined (YES in P11-6), the training stage processing section 216a determines and stores training items for arranging the target character (P11-7). If processing has not been completed for all of the team members extracted in P11-1 above (NO in P11-8), the training stage processing unit 216a continues processing from P11-2 until processing is completed for all team members. repeat. On the other hand, when the processing for all team members is completed (YES in P11-8), the training stage processing section 216a executes guest character determination processing (P100).

FIG. 39 is a flowchart for explaining guest character determination processing in the player terminal 1. FIG.

The training stage processing unit 216a determines whether or not the counter value of the non-winning counter indicating the number of consecutive turns in which the guest character has not been determined is 2 or more (P100-1). If the counter value of the non-winning counter is not equal to or greater than 2 (NO in P100-1), the training stage processing section 216a executes a first lottery to determine whether or not to set a guest character (P100-2). If the first lottery is not won (NO in P100-3), the training stage processing section 216a increments the counter value of the non-winning counter (P100-4).

Further, if the counter value of the non-winning counter is 2 or more (YES in P100-1), or if the first lottery is won (YES in P100-3), the training stage processing unit 216a Clear the value (P100-5). The training stage processing unit 216a also refers to the character identification information table to derive the total number of characters registered as team members (hereinafter also referred to as the number of team members) (P100-6).

If the number of team members is less than 20 (YES in P100-7), the training stage processing section 216a derives the A aptitude number for characters registered as team members (P100-8). Further, the training stage processing unit 216a extracts and determines the aptitude type with the smallest A aptitude number based on the derived A aptitude number (P100-9).

Further, the training stage processing unit 216a extracts sub-members whose aptitude type determined in P100-9 is "A" from among the sub-members (P100-10). Further, the training stage processing unit 216a generates a first lottery table based on the sub-members extracted in P100-10 (P100-11).

Further, the training stage processing unit 216a excludes the sub-members included in the first lottery table generated in P100-11 from among the sub-members (P100-12), and generates the second lottery table (P100-13). Further, the training stage processing unit 216a determines by lottery which of the first lottery table generated at P100-11 and the second lottery table generated at P100-13 is to be used (P100-14).

Further, the training stage processing unit 216a determines and registers a guest character by lottery using the first lottery table or the second lottery table determined in P100-14 (P100-15). Further, the training stage processing section 216a determines by lottery an individual race or a team race in which the guest character determined and registered in P100-15 is placed, and registers it (P100-16).

FIG. 40 is a flowchart for explaining numerical value determination processing in the player terminal 1. FIG. The training stage processing unit 216a selects training items such as "Speed", "Stamina", "Power", "Spirit", and "Wisdom", which will be described later. The items to be processed for which the processes of P12-2 to P12-9 have not been executed are set (P12-1).

Based on the current physical strength of the main character, the training stage processing unit 216a also determines and stores the failure rate when training is performed for the processing target items set in P12-1 (P12-2). Further, the training stage processing unit 216a determines and stores the reduction value of physical strength when training is executed for the processing target item set in P12-1 (P12-3).

Further, the training stage processing unit 216a confirms the current team ranking (P12-4), and determines the training level by referring to the training level table (FIG. 20A) based on the team ranking (P12-5). .

In addition, the training stage processing unit 216a refers to the rising fixed value table (FIGS. 20B and 20C) corresponding to the processing target item set in P12-1, and based on the training level determined in P12-5, the rising fixed value is determined and set (P12-6). In addition, the training stage processing unit 216a confirms the information (placement information) of the character whose placement was determined in P11 for training of the processing target item (P12-7).

Then, the training stage processing unit 216a refers to the bonus addition rate table (FIG. 20D) and calculates the bonus addition rate (P12-8) based on the placement information confirmed in P12-7. Further, the training stage processing unit 216a updates the increase value for the processing target item training based on the bonus addition rate calculated in P12-8 (P12-9).

Further, if the processing of P12-2 to P12-9 has not been completed for all training items (NO in P12-10), the training stage processing unit 216a repeats the processing from P12-1.

FIG. 41 is a flowchart for explaining event determination processing in the player terminal 1. FIG. The event determination unit 218a loads the number of turns in the breeding game information storage unit 308 (P13-1). Further, the event determination unit 218a refers to the event occurrence determination table stored in the data storage area 12b, and determines whether or not to cause the scenario event to appear (P13-2). If it is determined that the scenario event will appear, that is, if it is the scenario event appearance turn (YES in P13-2), the content of the scenario event (event ID) is determined based on the event content determination table, Store (P13-3).

Specifically, the event determination unit 218a generates a lottery table by event IDs of possible scenario events based on the event content determination table. Then, the event determination unit 218a uses the generated lottery table to determine the content of the scenario event, that is, the event ID by lottery. If the determined scenario event is an event that changes parameters, such as an ability event, the change value is determined.

The event determination unit 218a also refers to the event occurrence determination table and determines whether or not to cause the dedicated event 42a to appear (P13-4). Then, if it is decided to make the special event 42a appear, that is, if it is the special event appearance turn (YES in P13-4), the content (event ID) of the special event 42a is determined based on the event content determination table. and store (P13-5).

Specifically, the event determination unit 218a generates a lottery table by the event IDs of the exclusive events 42a that can appear based on the event content determination table. Then, the event determination unit 218a uses the generated lottery table to determine the content of the dedicated event 42a, that is, the event ID by lottery. If the determined dedicated event 42a is an event that changes parameters, such as an ability event, the change value is determined.

Further, when the main character is the specific character, the event determination unit 218a executes parameter change processing (P13-6) for changing the change value of the parameter changed by the special event 42a. For example, in the parameter change process, a predetermined fixed value is added or subtracted from the change value determined in P13-5, or a predetermined magnification is multiplied. Here, the change value changes so as to be advantageous to the player. As a result, when the main character is the specific character, the parameters are more advantageously changed by the special event 42a.

Further, the event determining unit 218a refers to the event occurrence determination table and determines whether or not to cause the support event to appear (P13-7). Then, if it is decided to make the support event appear, that is, if it is the support event appearance turn (YES in P13-7), the content of the support event (event ID) is determined based on the event content determination table, Store (P13-8).

Specifically, the event determining unit 218a generates a lottery table by event IDs of support events that can appear based on the event content determination table. At this time, the winning probability of the support event associated with the registered support card is set higher than the winning probability of other support events. Then, the event determination unit 218a uses the generated lottery table to determine the content of the support event, that is, the event ID by lottery. If the determined support event is an event that changes parameters, such as an ability event, the change value is determined.

Further, when the main character or the support character linked to the support event is the specific character, the event determination unit 218a performs parameter change processing (P13-9) for changing the change value of the parameter that changes depending on the support event. Run.

The event determination unit 218a also refers to the event occurrence determination table and determines whether or not to cause the team member event to appear (P13-10). Then, if it is determined that the team member event will appear, that is, if it is the team member event appearance turn (YES in P13-10), the event determination unit 218a determines whether the current turn is a branch turn. (P13-11).

If it is not a branch turn (NO in P13-11), the event determination unit 218a determines and stores the special training event corresponding to the current number of turns as an event to appear based on the event content determination table (P13-11). 12). Here, various increments associated with training events are determined.

Further, when the main character or the special training target character is a specific character, the event determination unit 218a executes parameter change processing (P13-13) for changing the change value of the parameter that changes according to the special training event.

Also, if the current turn is a branch turn (YES in P13-11), the event determination unit 218a determines whether a predetermined condition is satisfied (P13-14). Here, as described above, it is determined whether or not the number of specific characters included in the team members is the predetermined number defined for each number of turns. Then, if the predetermined condition is satisfied (YES in P13-14), the event determining section 218a replaces the scenario event stored in P13-3 with the specific character event (P13-15). Here, the specific character event to be replaced may be decided by lottery, or a specific character event preset for each turn may be decided.

The event determination unit 218a also performs hint event determination processing related to hint events for each character placed in training (P13-16). Here, it is decided by lottery whether or not to cause a hint event to appear for each character placed in the training. Also, when a hint event is to appear, it is determined which hint event is to appear.

Returning to FIG. 37, the breeding stage processing unit 216a updates the screen displayed on the display 26 (P10-3). If a story event is to be generated at the start of the turn, the story event is generated among the events determined in P13 (P10-4).

If it is a team race limited turn (YES in P10-2), the training stage processing unit 216a executes team race start processing (P10-5). Here, for example, a process of determining opponents in a team race is performed. In addition, in a team race, when competing against another player's team, a process related to matching with another player who will be the opponent may be executed. Further, the training stage processing unit 216a executes the above-described guest character determination processing (P100).

Here, it is assumed that the event does not appear in the team race only turn, but the event may appear in the team race only turn. In this case, the event determination process (P13) may be executed after the guest character determination process (P100).

Returning to FIG. 36, if it is not the time to start the turn (NO in P7-1), the training stage processing unit 216a executes the in-turn process (P20).

FIG. 42 is a flowchart for explaining the in-turn processing in the player terminal 1. FIG. The training stage processing unit 216a determines whether the result operation unit 113 or the race operation unit 114 of the individual race start screen 110 is operated to start the individual race (P20-1). When the individual race is started (YES in P20-1), the breeding stage processing section 216a derives the result of the individual race and stores it in the breeding game information storage section 308 (P20-2).

Specifically, for example, a calculation formula that weights the ability parameters and acquired skills of each NPC and main character is set in advance, and the results of this calculation determine the ranking in the individual race. Note that the above formula may be set differently for each race. Also, for example, a plurality of patterns of NPC ability parameters may be provided for each race, and which ability parameter to use may be determined by lottery. In other words, even if the main character's ability parameters, acquired skills, and the race to run are completely the same, the race result will not always be the same. Further, a plurality of patterns of calculation formulas such as weighting may be provided for each race, and the result may differ depending on the selected calculation formula.

Here, it is assumed that the individual race result is derived in the player terminal 1. FIG. However, individual race results may be derived at server 1000 . In this case, the player terminal 1 transmits to the server 1000 information requesting the derivation of the individual race results and information necessary for deriving the individual race results. Then, the player terminal 1 may receive the individual race results derived by the server 1000 .

Further, the training stage processing unit 216a executes race result display processing for displaying the individual race result screen 120 or the race video on the display 26 based on the individual race results derived in P20-2 (P20-3).

In addition, the training stage processing unit 216a executes character identification information update processing (P200).

FIG. 43 is a flowchart for explaining character identification information update processing in the player terminal 1. FIG. The training stage processing unit 216a refers to the result of the individual race or team race stored in the training game information storage unit 308, and determines whether the order of finish in the individual race or team race is a predetermined rank or higher (P200- 1). If the order of arrival is equal to or higher than the predetermined order (YES in P200-1) and the guest character is registered (YES in P200-2), the training stage processing unit 216a transfers the character identification information of the guest character from the sub members to the team. Change to a member (P200-3). At this time, for the ability parameters of the sub-members promoted to team members, preset initial values may be registered, or the ability parameters of the main character or correction values corrected according to the team level may be registered. It may be registered.

Returning to FIG. 42, the training stage processing section 216a determines whether the result operation section 151 or the race operation section 152 of the team race start screen 150 is operated to start the team race (P20-4). As a result, if the team race has started, the process moves to P20-5, and if the team race has not started, the process moves to P20-8.

The breeding stage processing section 216a derives the team race result and stores it in the breeding game information storage section 308 (P20-5). Specifically, for example, a calculation formula that weights the ability parameters of each NPC, main character, and other team members, and acquired skills is set in advance, and the results of this calculation determine the ranking in the team race. . Note that the above formula may be set differently for each race. Also, for example, a plurality of patterns of NPC ability parameters may be provided for each race, and which ability parameter to use may be determined by lottery. In other words, even if the ability parameters and acquired skills of the main character and other team members are exactly the same as the race they enter, the race results will not always be the same. Further, a plurality of patterns of calculation formulas such as weighting may be provided for each race, and the result may differ depending on the selected calculation formula.

It should be noted that here, the team race result is derived in the player terminal 1. FIG. However, team race results may be derived at server 1000 . In this case, the player terminal 1 transmits to the server 1000 information requesting derivation of the team race result and information necessary for deriving the team race result. Then, the player terminal 1 may receive the team race result derived by the server 1000 .

The training stage processing unit 216a performs a race to display the team race interim result screen 160, the team race detailed result screen 170, and the team race overall result screen 180 on the display 26 based on the team race results derived in P20-5 above. A result display process is executed (P20-6).

Further, the training stage processing section 216a executes a parameter updating process for updating the information related to the team ranking based on the team race results derived in P20-5 (P20-7).

Further, if any training item is selected (YES in P20-8), the training stage processing unit 216a executes training execution processing (P21). If no training item is selected (NO in P20-8), other processing such as acquiring skills by consuming skill points is executed (P20-9).

FIG. 44 is a flowchart for explaining training execution processing in the player terminal 1. FIG. The training stage processing unit 216a updates the physical strength of the main character for the selected training item based on the physical strength reduction value determined in P12-3 (P21-1).

Further, the training stage processing unit 216a executes a success judgment process for judging whether or not the training is successful for the selected training item based on the failure rate determined in P12-2 (P21-2). If the training fails (NO in P21-3), the training stage processing section 216a subtracts the ability parameter such as a decrease in condition based on the training failure (P21-4).

On the other hand, if the training is successful (YES in P21-3), the training stage processing section 216a adds the increased value derived in P12-9 to the ability parameter of the main character (P21-5). In addition, the training stage processing unit 216a adds an increase value to the bond parameter values determined in P13-12 and P13-13 (P21-6). Also, the training stage processing unit 216a confirms the hint event information stored in the hint event determination process (P21-7).

If hint event information is stored for the selected training item (YES in P21-8), the training stage processing unit 216a causes the hint event to appear based on the hint event information related to the selected training item. (P21-9). If a plurality of hint event information are stored for the selected training item, any one hint event appears. Further, the breeding stage processing unit 216a updates the skill information related to the main character stored in the breeding game information storage unit 308 based on the hint event information that appeared in P21-9 (P21-10).

Further, if special training event information is stored for the selected training item (YES in P21-11), the training stage processing unit 216a stores the special training event based on the special training event information related to the selected training item. A team member to be executed is set (P21-12).

Further, the training stage processing unit 216a adds "1" to the number of training events for the team member to be executed set in P21-12 (P21-13). Also, the training stage processing unit 216a updates the ability parameters of the special training target (P21-14). When the processing of P21-13 to P21-14 is completed for all team members targeted for execution of the special training event (YES in P21-15), the training stage processing unit 216a processes the selected training item and the special training event information. Based on this, the additional bonus value is added to the ability parameter of the main character (P21-16).

By the above processing, the breeding game described above is realized. Note that the processing in the player terminal 1 described above is merely an example. Further, each of the processes described above may be executed only by the player terminal 1 or may be executed only by the server 1000 . For example, the server 1000 may execute a process of determining whether an event will appear and the content of the event, and the player terminal 1 may perform display based on the information determined by the server 1000 .

Although one aspect of the embodiment has been described above with reference to the accompanying drawings, it goes without saying that the present invention is not limited to the above embodiment. It is obvious that a person skilled in the art can conceive various modifications or modifications within the scope of the claims, and it is understood that these also belong to the technical scope.

In the above-described embodiment, a case where characters and support cards are used as game media in a breeding game has been described, but the above-described game genre and game nature are merely examples.

In the above embodiment, the predetermined game (scenario training main game) includes a plurality of turns. includes processing to generate an event linked to game identification information (scenario ID) assigned to a predetermined game being executed, and utility includes changing an event that occurs in a specific turn (branch turn). In the process of performing display based on utility, it was decided to perform display corresponding to the changed event. However, the predetermined game is not limited to one consisting of multiple turns.

In the above embodiment, the event appearing in the branch turn is the scenario-specific event. However, the event that appears in the branch turn may be a scenario common event.

In the above embodiment, when a character set as a specific character is registered as a main character or a support character, a specific character event appears and parameters used during the training main game are changed. . However, the utility of these specific characters is only an example.

In any case, multiple types of game media (characters, support cards) that can be used in a given game (scenario) are provided, and medium identification information given to game media set as special game media (specific characters). (character ID) and game identification information (scenario ID) assigned to a predetermined game are linked (specific character information); allowing the player to select the game media to be used in the game from among a plurality of types of game media; registering the game media selected by the player; executing a predetermined game based on the registered game media; To display, during a predetermined game, a display based on the utility that occurs when a game medium set as a special game medium is registered; It is only necessary to identify and display the game content set as the special game content in the predetermined game.

Further, in the above-described embodiment, based on the player's operation, the permission state in which the identification display of the game medium (character) set as the special game medium (specific character) can be executed, or the state in which the game medium (character) set as the special game medium A game medium set as a special game medium is identified and displayed when it is set to a permitted state. However, switching between the permitted state and the disallowed state is not essential, and an identification display may always be made.

Further, when a specific character is registered as a main character or a support character, the number of events occurring during the breeding main game or the occurrence probability may be changed. For example, when a character set as a specific character is registered as a main character, the appearance probability of the main character's dedicated event 42a may be changed to be higher.

Also, for example, if a character set as a specific character is registered as a support character, it may be changed so that the probability of appearance of the support event increases, or the contents (types) of support events that appear will increase. may be changed to In this case, for example, the probability or content (kind) of the support event of the support card linked to the specific character may be changed, or the probability or content (type) of the support event unrelated to the specific character is decided. The content (type) may be changed.

In other words, the utility brought about by a specific character includes changing the number of events or the probability of occurrence during the training main game, and corresponds to the event determined based on the changed number of events or the probability of occurrence. may be displayed. For example, when a character set as a specific character is registered, the lottery table for determining whether or not an event will appear or the ratio of the lottery table for determining the content of the event is changed. can be realized by

The information processing program for executing the processes in the above embodiments and various modifications may be stored in a computer-readable non-temporary storage medium and provided as the storage medium. Furthermore, a game terminal device including this storage medium may be provided. Further, the above-described embodiment and various modifications may be an information processing method that implements each function and the steps shown in the flowchart.

1 player terminal 1000 server S information processing system

Claims (6)

An information processing method performed by a computer,
Among a plurality of types of game media usable in a predetermined game, medium identification information given to the game media set as special game media is associated with game identification information given to the predetermined game. a process of retaining information;
After the predetermined game is selected, a process of allowing the player to select the game media to be used in the selected predetermined game from among a plurality of types of the game media;
a process of registering the game content selected by the player;
a process of executing the predetermined game based on the registered game content;
a process of displaying, during the predetermined game, a display based on the effect that occurs when the game media set as the special game media is registered;
Based on the player's operation, the permission state permits identification display to display the special game medium in a manner different from that of the non-special game medium , or the non-permission state disables the identification display . and the process of setting the
a process of identifying and displaying the special game content in the selected predetermined game at least after the predetermined game is selected and when the permitted state is set;
Information processing method including. The predetermined game includes a plurality of turns,
A unit process is executed in the process of executing the predetermined game,
The unit process includes a process of generating an event linked to the game identification information assigned to the predetermined game being executed,
the utility includes changing the content of the event;
In the utility-based display processing, display corresponding to the changed content of the event is performed;
The information processing method according to claim 1 . The predetermined game includes a plurality of turns,
A unit process is executed in the process of executing the predetermined game,
The unit process includes a process of generating an event linked to the game identification information assigned to the predetermined game being executed,
The utility includes changing the number or occurrence probability of the event occurring during the predetermined game,
In the utility-based display processing, display corresponding to the event determined based on the changed number or occurrence probability of the event is performed;
The information processing method according to claim 1 . the utility includes changing a parameter used during the predetermined game;
The information processing method according to any one of claims 1 to 3. one or more computers
Among a plurality of types of game media usable in a predetermined game, medium identification information given to the game media set as special game media is associated with game identification information given to the predetermined game. a process of retaining information;
After the predetermined game is selected, a process of allowing the player to select the game media to be used in the selected predetermined game from among a plurality of types of the game media;
a process of registering the game content selected by the player;
a process of executing the predetermined game based on the registered game content;
a process of displaying, during the predetermined game, a display based on the effect that occurs when the game media set as the special game media is registered;
Based on the player's operation, the permission state permits identification display to display the special game medium in a manner different from that of the non-special game medium , or the non-permission state disables the identification display . and the process of setting the
a process of identifying and displaying the special game content in the selected predetermined game at least after the predetermined game is selected and when the permitted state is set;
Information processing system that carries out Among a plurality of types of game media usable in a predetermined game, medium identification information given to the game media set as special game media is associated with game identification information given to the predetermined game. a process of retaining information;
After the predetermined game is selected, a process of allowing the player to select the game media to be used in the selected predetermined game from among a plurality of types of the game media;
a process of registering the game content selected by the player;
a process of executing the predetermined game based on the registered game content;
a process of displaying, during the predetermined game, a display based on the effect that occurs when the game media set as the special game media is registered;
Based on the player's operation, the permission state permits identification display to display the special game medium in a manner different from that of the non-special game medium , or the non-permission state disables the identification display . and the process of setting the
a process of identifying and displaying the special game content in the selected predetermined game at least after the predetermined game is selected and when the permitted state is set;
An information processing program that causes a computer to carry out

Images