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

Description

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

Conventionally, as shown in Patent Document 1, for example, a genre of games known as "training games" has been known. In training games, multiple types of training events are provided, and a player can select one of the training events to train a character to be trained. A plurality of parameters indicating abilities are set for the character to be trained. Furthermore, each training event is associated with a parameter that can be improved. Therefore, a player can selectively improve the desired abilities of the character to be trained. By increasing the parameters of the character to be trained, the player can progress advantageously in a fighting game, etc.

For example, Patent Document 2 discloses a game in which players can scout players and organize teams. This game allows players to compete against each other in competitive games using teams they organize.

Japanese Patent Application Laid-Open No. 2019-154564 Patent No. 6732178

In character development games, the player's training method is largely determined by the abilities of the character. Furthermore, when playing a competitive game using characters that have been developed, the abilities of the characters that should be possessed are also largely determined. As a result, conventional character development games require little strategy from the player, which can reduce the enjoyment of the game.

The present invention aims to provide an information processing program, information processing method, and information processing system that can increase the enjoyment of games.

In order to solve the above problem, an information processing program
a process of setting a game medium selected by a player from a plurality of game media including game media set as specific game media in a development scenario and game media not set as the specific game medium , as a deck to be used in a development game that progresses in accordance with the development scenario ;
a process of placing at least one of a plurality of game media, including the game media set in the specific game media and the game media set in the deck, in one of a plurality of selection items selectable by a player in the training game;
a process of displaying a selection screen that allows identification of the plurality of selection items and the game contents arranged in the selection items;
a process for allowing a player to input a selection operation for selecting one of the plurality of selection items displayed on the selection screen;
a process of executing a first update process of updating a training parameter linked to the training target game medium when the selection operation is input;
a process of executing a second update process, when the selection operation is input, of updating a specific parameter associated with the game content arranged in the selection item for which the selection operation is input;
a process of granting an advantageous effect that is advantageous to the player under at least one of the conditions that the game medium set for the specific game medium is set in the deck, and that the game medium set for the specific game medium and set in the deck is placed in the selection item for which the selection operation was input;
The computer executes the following .
The process of imparting the advantageous effect includes:
When the selection item to which the selection operation is input is set to the specific game medium and the game medium set in the deck is placed, the update amount of the specific parameter in the second update process is increased .

The process of imparting the advantageous effect includes:
When the game medium set for the specific game medium is set for the deck, the initial value of the specific parameter linked to the game medium may be increased.
The process of imparting the advantageous effect includes:
The probability that the game medium that is set to the specific game medium and set to the deck will be placed in the selection item may be increased to be higher than the probability that the game medium that is not set to the specific game medium and set to the deck will be placed in the selection item.

In order to solve the above problem, an information processing method includes:
1. An information processing method performed by one or more computers, comprising:
The computer
a process of setting a game medium selected by a player from a plurality of game media including game media set as specific game media in a development scenario and game media not set as the specific game medium , as a deck to be used in a development game that progresses in accordance with the development scenario ;
a process of placing at least one of a plurality of game media, including the game media set in the specific game media and the game media set in the deck, in one of a plurality of selection items selectable by a player in the training game;
a process of displaying a selection screen that allows identification of the plurality of selection items and the game contents arranged in the selection items;
a process for allowing a player to input a selection operation for selecting one of the plurality of selection items displayed on the selection screen;
a process of executing a first update process of updating a training parameter linked to the training target game medium when the selection operation is input;
a process of executing a second update process, when the selection operation is input, of updating a specific parameter associated with the game content arranged in the selection item for which the selection operation is input;
a process of granting an advantageous effect that is advantageous to the player under at least one of the conditions that the game medium set for the specific game medium is set in the deck, and that the game medium set for the specific game medium and set in the deck is placed in the selection item for which the selection operation was input;
and
The process of imparting the advantageous effect includes:
When the selection item to which the selection operation is input is set to the specific game medium and the game medium set in the deck is placed, the update amount of the specific parameter in the second update process is increased .

In order to solve the above problem, the information processing system includes:
An information processing system comprising one or more computers,
The computer
a process of setting a game medium selected by a player from a plurality of game media including game media set as specific game media in a development scenario and game media not set as the specific game medium , as a deck to be used in a development game that progresses in accordance with the development scenario ;
a process of placing at least one of a plurality of game media, including the game media set in the specific game media and the game media set in the deck, in one of a plurality of selection items selectable by a player in the training game;
a process of displaying a selection screen that allows identification of the plurality of selection items and the game contents arranged in the selection items;
a process for allowing a player to input a selection operation for selecting one of the plurality of selection items displayed on the selection screen;
a process of executing a first update process of updating a training parameter linked to the training target game medium when the selection operation is input;
a process of executing a second update process, when the selection operation is input, of updating a specific parameter associated with the game content arranged in the selection item for which the selection operation is input;
a process of granting an advantageous effect that is advantageous to the player under at least one of the conditions that the game medium set for the specific game medium is set in the deck, and that the game medium set for the specific game medium and set in the deck is placed in the selection item for which the selection operation was input;
and
The process of imparting the advantageous effect includes:
When the selection item to which the selection operation is input is set to the specific game medium and the game medium set in the deck is placed, the update amount of the specific parameter in the second update process is increased .

This invention can increase the enjoyment of the game.

FIG. 1 is an explanatory diagram showing a schematic configuration of an information processing system. Fig. 2A is a diagram illustrating the hardware configuration of a player terminal, and Fig. 2B is a diagram illustrating the hardware configuration of a server. FIG. 3 is a diagram for explaining the general flow of the training game. Fig. 4A is a diagram illustrating a home screen. Fig. 4B is a diagram illustrating a main character selection screen. Fig. 4C is a first diagram illustrating a character detail screen. Fig. 4D is a second diagram illustrating a character detail screen. Fig. 5A is a diagram illustrating a capability parameter (initial value) table, Fig. 5B is a diagram illustrating an aptitude parameter (initial value) table, Fig. 5C is a diagram illustrating a skill table, and Fig. 5D is a diagram illustrating a dedicated event table. Fig. 6A is a first diagram illustrating a support card setting screen, Fig. 6B is a diagram illustrating a support card selection screen, and Fig. 6C is a second diagram illustrating a support card setting screen. Fig. 7A is a diagram illustrating a support card table, Fig. 7B is a diagram illustrating a support effect table, Fig. 7C is a diagram illustrating a possessed skill table, and Fig. 7D is a diagram illustrating a support event table. FIG. 8 is a first diagram illustrating the character identification information table. FIG. 9 is a second diagram illustrating the character identification information table. FIG. 10 is a diagram illustrating the selection item table. Fig. 11A is a first diagram illustrating a game screen, and Fig. 11B is a second diagram illustrating a game screen. Fig. 12A is a first diagram illustrating a training screen. Fig. 12B is a second diagram illustrating a 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 a first diagram illustrating the skill screen, and Fig. 13B is a second diagram illustrating the skill screen. 14A is a diagram illustrating an individual race selection screen, FIG. 14B is a diagram illustrating an individual race start screen, and FIG. 14C is a diagram illustrating an individual race result screen. Fig. 15A is a diagram illustrating a team race selection screen, Fig. 15B is a diagram illustrating a team race organization screen, Fig. 15C is a diagram illustrating a team race start screen, and Fig. 15D is a diagram illustrating a team race interim result screen. Fig. 16A is a first diagram illustrating a team race detailed results screen. Fig. 16B is a first diagram illustrating a team race overall results screen. Fig. 16C is a second diagram illustrating a team race detailed results screen. Fig. 16D is a second diagram illustrating a team race overall results screen. FIG. 17 is a diagram for explaining the relationship between team members, sub-members, and random members. FIG. 18 is a diagram illustrating the registered parameter table. FIG. 19 is a diagram illustrating the general flow of the turn start processing. Fig. 20A is a diagram illustrating a random member arrangement number table, and Fig. 20B is a diagram illustrating a suitability number table. FIG. 21 is a diagram illustrating the arrangement presence/absence table. Fig. 22A is a diagram illustrating a training level table. Fig. 22B is a diagram illustrating a fixed increase value (speed) table. Fig. 22C is a diagram illustrating a fixed increase value table (power). Fig. 22D is a diagram illustrating a bonus addition rate table. FIG. 23 is a diagram illustrating the utility table. Fig. 24A is a first diagram illustrating the event determination process, Fig. 24B is a second diagram illustrating the event determination process, and Fig. 24C is a third diagram illustrating the event determination process. Fig. 25A is a diagram illustrating a successful pattern lottery table, and Fig. 25B is a diagram illustrating an event table eligible for addition. FIG. 26 is a diagram illustrating the memory configuration and computer functions of the player terminal. FIG. 27 is a diagram illustrating the memory configuration and computer functions of the server. FIG. 28 is a sequence diagram illustrating basic processing of the player terminal and the server. FIG. 29 is a flowchart illustrating the preparation stage processing in the player terminal. FIG. 30 is a flowchart illustrating the development stage processing at the player terminal. FIG. 31 is a flowchart illustrating the turn start processing at the player terminal. FIG. 32 is a flowchart illustrating the placement process in the player terminal. FIG. 33 is a flowchart illustrating the numerical value determination process at the player terminal. FIG. 34 is a flowchart illustrating the event determination process in the player terminal. FIG. 35 is a flowchart illustrating the process during a turn at the player terminal. FIG. 36 is a flowchart illustrating the training execution process in the player terminal. FIG. 37 is a flowchart illustrating the character identification information update process at the player terminal when the game is successful. FIG. 38 is a flowchart illustrating the character identification information update process at the player terminal when a game fails. FIG. 39 is a diagram illustrating a character identification information table according to a modified example. FIG. 40 is a diagram illustrating the general flow of the turn start process according to the modified example. 41A and 41B are diagrams illustrating a game screen and a training screen according to a modified example. Fig. 42A is a diagram illustrating a training event execution determination table according to a modified example, Fig. 42B is a diagram illustrating a special icon determination table according to a modified example, and Fig. 42C is a diagram illustrating a bonus icon determination table according to a modified example. 43A and 43B are diagrams illustrating a fixed bonus value (main character) table and an additional bonus value (main character) table, respectively, according to a modified example. 44A and 44B are diagrams illustrating a fixed increase value (special training target) table according to a modified example. 45A and 45B are diagrams illustrating a game screen according to a modified example, and an individual race selection screen according to a modified example. FIG. 46 is a flowchart illustrating turn start processing in a player terminal according to a modified example. FIG. 47 is a flowchart illustrating placement processing in a player terminal according to a modified example. FIG. 48 is a flowchart illustrating guest character determination processing in a player terminal according to a modified example. FIG. 49 is a flowchart illustrating an event determination process in a player terminal according to a modified example. FIG. 50 is a flowchart illustrating a process during a turn at a player terminal according to a modified example. FIG. 51 is a flowchart illustrating a character identification information update process in a player terminal according to a modified example. FIG. 52 is a flowchart illustrating the training execution process in a player terminal according to a modified example.

One embodiment of the present invention will be described in detail below with reference to the accompanying drawings. The numerical values and other information shown in the embodiment are merely examples to facilitate understanding and, unless otherwise specified, do not limit the present invention. Note that in this specification and drawings, elements that have substantially the same function and configuration are designated by the same reference numerals to avoid redundant explanation, and elements that are not directly related to the present invention are not shown.

(Overall configuration of information processing system S)
1 is an explanatory diagram showing a schematic configuration of an information processing system S. The information processing system S is a so-called client-server system that includes player terminals 1 that function as clients, i.e., game terminals, a server 1000, and a communication network N that has a communication base station Na.

In the information processing system S of this embodiment, the player terminal 1 and the server 1000 function as the game device G. The player terminal 1 and the server 1000 are each assigned a role in controlling the progress of the game, and the game can progress through cooperation between the player terminal 1 and the server 1000.

The player terminal 1 can establish communication with the server 1000 via the communication network N. The player terminal 1 broadly includes electronic devices that can establish a wireless or wired communication connection with the server 1000. Examples of the player terminal 1 include smartphones, mobile phones, tablet devices, personal computers, game consoles, etc. In this embodiment, a case will be described in which a smartphone is used as the player terminal 1.

The server 1000 is connected to multiple player terminals 1 for communication. The server 1000 accumulates various information for each player playing the game. The server 1000 also performs processes such as updating the accumulated information and downloading images and various information to the player terminals 1, mainly based on operations input from the player terminals 1.

The communication base station Na is connected to the communication network N and transmits and receives information wirelessly to and from the player terminal 1. 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 a 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 illustrating the hardware configuration of the player terminal 1. Fig. 2B is a diagram illustrating the hardware configuration of the server 1000. As shown in Fig. 2A, the player terminal 1 is configured to include a CPU (Central Processing Unit) 10, a memory 12, a bus 14, an input/output interface 16, a storage unit 18, a communication unit 20, an input unit 22, and an output unit 24.

Also, as shown in FIG. 2B, the server 1000 is configured to include a CPU 1010, memory 1012, bus 1014, input/output interface 1016, storage unit 1018, communication unit 1020, input unit 1022, and output unit 1024.

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

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

An input/output interface 16 is connected to the bus 14. A memory 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 semiconductor memory such as 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 into the memory 12 (RAM) by the CPU 10.

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

The input unit 22 is composed of, for example, a touch panel, buttons, keyboard, mouse, cross key, analog controller, etc., which inputs (accepts) player operations. The input unit 22 may also be a dedicated controller provided on the player terminal 1 or connected (externally) to the player terminal 1. Furthermore, the input unit 22 may be composed of an acceleration sensor that detects the tilt or movement of the player terminal 1, or a microphone that detects the player's voice. In other words, the input unit 22 broadly includes devices that can input the player's intentions in a discernible manner.

The output unit 24 includes a display device and a speaker. The output unit 24 may also be an external device connected 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 superimposed on the display 26 as the input unit 22.

(Game content)
Next, a game provided by the information processing system S and game device G of this embodiment will be described. A player can own characters acquired through a lottery known as gacha or characters distributed by the operator. Furthermore, a player can own support cards (support characters) acquired through a lottery known as gacha or support cards (support characters) distributed by the operator. As will be described in detail later, this embodiment has a gameplay in which a player trains a character owned by the player in a training game consisting of 60 turns. Furthermore, the training game in this embodiment anthropomorphizes racehorses as characters, and has a gameplay in which the player trains the character and aims to win first place in races that mimic horse racing.

Figure 3 is a diagram explaining the general flow of the training game. The training game is broadly divided into preparatory stage processing and training stage processing. Details of the preparatory stage processing will be described in detail in Figure 29, which will be described later. Details of the training stage processing will be described in detail in Figures 30, 31, 32, 33, 34, 35, 36, and 37, which will be described later. Here, to make it easier to understand, the general flow of the preparatory stage processing and training stage processing will be explained first.

<Preparatory processing>
The preparation stage processing mainly involves registering the main character, registering support cards (support characters), registering specific characters, and setting initial character identification information.

<Registering the main character>
4A is a diagram illustrating the home screen 27. In this embodiment, when a game application is launched on the player terminal 1, the home screen 27 is displayed on the display 26. 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 has multiple operation units that can be operated (tapped) by the player. The menu bar 28 has a home screen selection operation unit 28a marked "home" and a race screen selection operation unit 28b marked "race" and a gacha screen selection operation unit 28c marked "gacha." Note that the operation units corresponding to each screen are highlighted on the menu bar 28 so that the screen currently being displayed on the display 26 can be identified.

When the player taps the gacha screen selection operation unit 28c on the home screen 27, a gacha screen (not shown) is displayed on the display 26. Although detailed explanation will be omitted, the gacha screen allows a so-called gacha lottery to be held, in which characters and support cards (support characters) can be acquired by lottery. The player can enter the gacha lottery by spending in-game currency.

Furthermore, when the player taps the scenario operation section 29 on the home screen 27, the main character selection screen 30 shown in Figure 4B is displayed on the display 26.

Figure 4B is a diagram illustrating the main character selection screen 30. In the center of the main character selection screen 30, multiple character icons 31 are displayed, listing the characters owned by the player. In addition, a parameter display section 32 is displayed at the top of the main character selection screen 30. In addition, a return operation section 33 marked "Return" and a next operation section 34 marked "NEXT" are displayed at the bottom of the main character selection screen 30.

In this embodiment, initial ability parameter values are set for each character, and the parameter display section 32 displays the initial ability parameter values of the character corresponding to the character icon 31 selected by the player as numerical values. In this embodiment, the larger the numerical value of the ability parameter, the higher the ability.

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

In this embodiment, initial ability parameter values are set for each character for multiple types of abilities. Specifically, the ability parameters include a speed ability parameter marked "Speed" in the parameter display section 32, a stamina ability parameter marked "Stamina" in the parameter display section 32, a power ability parameter marked "Power" in the parameter display section 32, a tenacity ability parameter marked "Spirit" in the parameter display section 32, and an intelligence ability parameter marked "Wisdom" in the parameter display section 32.

The initial values of each character's ability parameters may be increased by spending in-game currency. Furthermore, the values of the ability parameters change when certain conditions are met after the start of the training game. Therefore, players aim to increase the numerical values of their characters' ability parameters in the training game.

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

In this embodiment, initial values for aptitude parameters are set for each character for multiple types of aptitude. Specifically, the aptitude parameters include aptitude parameters related to course suitability for turf and dirt, aptitude parameters related to distance suitability for short, mile, middle, and long distance races, and aptitude parameters related to running style suitability for breakaway, leading, overtaking, and closing in.

The initial value of each character's aptitude parameter may be increased by spending in-game currency. The value of the aptitude parameter may also change when a predetermined condition is met after the start of the training game. When a predetermined condition is met after the start of the training game, the aptitude parameter may be set to S, which is a higher aptitude than A.

Figure 4C is a first diagram illustrating the character details screen 40. Figure 4D is a second diagram illustrating the character details screen 40. When a character icon 31 on the main character selection screen 30 is pressed and held, the character details screen 40 is displayed on the display 26. The character details screen 40 displays details of the abilities of the character corresponding to the character icon 31 that was pressed and held 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 details screen 40. As shown in Figure 4C, when the main character selection screen 30 is initially displayed, the skill operation section 41 is highlighted, and the skills provided for each character are displayed. Skills are abilities that may be activated when certain conditions are met during the individual races and team races described below. Activating skills gives each character an advantage in the race.

Figure 5C is a diagram illustrating the skill table. As shown in Figure 5C, the skill table stores skills for each character possessed by the player. Based on the skills stored in the skill table, skills are displayed on the character detail screen 40, as shown in Figure 4C. Note that skills cannot be activated simply by possessing them; they can only be activated by acquiring them. Hereinafter, skills that a character can activate are referred to as acquired skills.

From the start of the training game, each character is assigned one acquired skill 41a. In addition to the acquired skills 41a, each character is also assigned multiple possessed skills 41b. Possessed skills 41b are skills that can be acquired after the training game begins by consuming skill points, which are described below. In other words, possessed skills 41b can become acquired skills 41a in exchange for skill points.

In this embodiment, skills corresponding to "◎" in the skill table shown in Figure 5C are displayed as acquired skills 41a on the character details screen 40 of Figure 4C. Furthermore, skills corresponding to "◯" in the skill table shown in Figure 5C are displayed as possessed skills 41b on the character details screen 40 of Figure 4C. In this embodiment, as shown on the character details screen 40 of Figure 4C, acquired skills 41a are highlighted to make it easier to distinguish between acquired skills 41a and possessed skills 41b.

In this embodiment, Figure 4C shows one acquired skill 41a and seven possessed skills 41b displayed as skills provided for each character, but this is not limited to this. For example, the number of acquired skills 41a and possessed skills 41b may differ for each character. Also, for example, the number of acquired skills 41a and possessed skills 41b for each character may be increased by consuming in-game currency.

Furthermore, when the player taps the event operation section 42 on the character details screen 40, the content of the character details screen 40 changes, as shown in FIG. 4D, and a dedicated event 42a for each character is displayed. In this case, the event operation section 42 is highlighted, as shown in FIG. 4D. A dedicated event 42a occurs when a predetermined condition is met in the training game, and displays a story related to a character appearing in the training game or changes the values of various statuses in the training game.

Figure 5D is a diagram illustrating the dedicated event table. As shown in Figure 5D, the dedicated event table stores dedicated events 42a for each character owned by the player. Based on the dedicated events 42a stored in the dedicated event table, the dedicated events 42a are displayed on the character detail screen 40, as shown in Figure 4D. Note that the dedicated events 42a may include hint events that enable the possession or acquisition of skills, ability events that increase or decrease the numerical values of a character's ability parameters, aptitude events that change a character's aptitude parameters, story events that display a story related to a character, etc.

All of the dedicated events 42a displayed on the character detail screen 40 shown in FIG. 4D may be executed while the training game is being played, or at least some of them may be executed while the training game is being played, or none of them may be executed while the training game is being played if a predetermined condition is not met. Furthermore, for example, the number of dedicated events 42a provided for each character may be increased by consuming in-game currency. Furthermore, if a predetermined condition is met, dedicated events 42a not displayed as dedicated events 42a may be executed during the training game.

Furthermore, as shown in Figures 4C and 4D, a close operation section 43 marked "close" is displayed at the bottom of the character details screen 40. When the close operation section 43 of the character details screen 40 is tapped, the display of the character details screen 40 ends, and the main character selection screen 30 is displayed on the display 26.

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

Furthermore, when the next operation unit 34 is tapped on the main character selection screen 30 shown in Figure 4B, the selected character is set as the main character, and the support card setting screen 50 (Figure 6A) is displayed on the display 26.

<Support card (support character) registration>
6A is a first diagram illustrating a support card setting screen 50. 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, a return operation section 53 marked "Return" and a start operation section 54 marked "START" are displayed at the bottom of the support card setting screen 50.

The support card display area 51 displays multiple support card setting operation sections 52 (six in this example). The same number of support card setting operation sections 52 as the number of support cards (support characters) that the player can set are displayed. Note that when the support card setting screen 50 is first displayed, the support card setting operation sections 52 are displayed as blank spaces.

In this embodiment, six types of support cards (support characters) can be set from the support cards (support characters) possessed by the player. Of the six types that can be set, some (e.g., five types) may be selectable from support cards (support characters) possessed by the player, and the remaining (e.g., one type) may be selectable from support cards (support characters) not possessed by the player.

Figure 6B is a diagram illustrating the support card selection screen 60. When the support card setting operation section 52 on the support card setting screen 50 in Figure 6A is operated, the support card selection screen 60 shown in Figure 6B is displayed on the display 26. The support card selection screen 60 displays a list of icons 61 corresponding to the support cards (support characters) possessed by the player.

By tapping the icon 61 displayed on the support card selection screen 60, the player can select a support card (support character).

Figure 7A is a diagram explaining the support card table. As shown in Figure 7A, the support card table stores the type, rarity, level, and special training of the support character for each type of support card held by the player. Support characters correspond one-to-one with the type of support card. In other words, one character is always associated with each support card as the 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). R is set as the lowest rarity, and SSR is set as the highest. In this embodiment, the higher the rarity of a support card (support character), the greater the support effect, which will be described later. Also, in this embodiment, the higher the rarity of a support card (support character), the greater the number of possessed skills and support events, which will be described later.

There are 50 levels for support cards (support characters), ranging from level 1 to level 50. The level of a support card (support character) can be increased by the player, and the level increased by the player is stored for each support card. Note that the level of a support card can be increased by playing the training game or by using in-game currency. Note that there is an upper limit to the level of a support card (support character) depending on its rarity.

For example, the maximum level for support cards (support characters) with a rarity of R is 20, the maximum level for support cards (support characters) with a rarity of SR is 25, and the maximum level for support cards (support characters) with a rarity of SSR is 30.

The upper level limit can be increased in stages when certain conditions are met. For example, the upper level limit for a support card (support character) with an R rarity can be increased to a maximum of 40, the upper level limit for a support card (support character) with an SR rarity can be increased to a maximum of 45, and the upper level limit for a support card (support character) with an SSR rarity can be increased to a maximum of 50.

Figure 7B is a diagram illustrating the support effect table. As shown in Figure 7B, the support effect table stores support effects for each type of support card (support character) possessed by the player.

Support effects increase various stats in the training game. Support cards have multiple targets for their support effects. Support effect targets include strength, speed, stamina, power, tenacity, and intelligence.

Figure 7C is a diagram illustrating the possessed skill table. As shown in Figure 7C, the possessed skill table sets possessed skills for each support card (support character) possessed by the player.

In this embodiment, just as the character the player has set as the main character has skills, skills are set for each support card (support character). When a hint event occurs during the training game, the skills set for each support card (support character) can be acquired by the main character selected by the player, or by other characters promoted to team members (described below).

Figure 7D is a diagram illustrating the support event table. As shown in Figure 7D, the support event table stores support events that can occur for each support card (support character) possessed by the player. A support event is an event that can occur while the training game is being played. When a support event occurs, various status values in the training game may increase or decrease.

For example, the support event to be executed may be determined based on the number of turns, or may be determined by a predetermined lottery. Furthermore, multiple support events to be executed may be selected per turn. In either case, the support event to be executed may be determined according to a predetermined determination method that has been set in advance.

Figure 6C is a second diagram illustrating the support card setting screen 50. In this embodiment, when all six support cards are selected, the start operation unit 54 becomes operable, as shown in Figure 6C. On the other hand, when all six support cards are not selected, the start operation unit 54 becomes inoperable, as shown in Figure 6A.

When the return operation unit 53 on the support card setting screen 50 is operated, the main character selection screen 30 shown in Figure 4B is displayed on the display 26.

Also, as shown in FIG. 6C, when the start operation unit 54 is tapped on the support card setting screen 50, the selected support card (support character) is registered and the game screen 70 (FIG. 11A) is displayed on the display 26.

<Registering specific characters>
As described above, after the main character and the support card (support character) are registered, the specific character is then registered. In this embodiment, four types of characters are preset as candidates for the specific character.

Figure 8 is the first diagram illustrating the character identification information table. Figure 9 is the second diagram illustrating the character identification information table. Figure 8 shows a case where "Character C" is registered as the main character, and "Character E," "Character I," "Character L," "Character M," "Character Q," and "Character T" are registered as support cards (support characters). Figure 9 shows a case where "Character F" is registered as the main character, and "Character E," "Character J," "Character L," "Character M," "Character Q," and "Character T" are registered as support cards (support characters).

In this embodiment, there is a restriction to prevent overlap between the character type set for the main character and the character type set for the support card (support character).

In this embodiment, as shown in Figure 8, "Character F," "Character J," "Character N," and "Character R" are set as candidates for specific characters. When the player selects a main character from among multiple characters, the selected character is registered as the main character in the character identification information table.

In addition, when a support card (support character) is selected by the player, the character identification information table is updated and the character corresponding to the selected support card (support character) is registered as a support character.

When information about the main character and support card (support character) is registered in the character identification information table, information about the specific character is also registered. At this time, as shown in Figure 8, if the registered main character does not overlap with the above-mentioned pre-set specific character candidates, the pre-set specific character candidate is registered as the specific character. That is, in the case of Figure 8, "Character F," "Character J," "Character N," and "Character R" are registered as specific characters.

As shown in Figure 9, if a registered main character overlaps with one of the previously set specific character candidates, a character from among the previously set specific character candidates that does not overlap with the registered main character will be registered as the specific character. In the case of Figure 9, "Character J," "Character N," and "Character R" will be registered as the specific characters.

On the other hand, as shown in Figure 9, if a registered support card (support character) overlaps with a candidate for a specific character that has been preset as described above, that character will be registered as both a support card (support character) and a specific character.

<Setting initial character identification information>
As described above, once the main character, support card (support character), and specific character are registered, team members, sub-members, and random members are registered. As will be described in more detail below, in the training game, it is necessary to play a battle game using characters registered as team members. When a character registered as a sub-member meets certain conditions, that character is registered as a team member. Furthermore, during the training game, characters registered as random members appear. When a character registered as a random member meets certain conditions, it is promoted to a sub-member.

In this embodiment, at the start of the training game, the character registered as the main character in the character identification information table is registered as a team member. That is, in the case of Figure 8, "Character C" is registered as a team member. Also, in the case of Figure 9, "Character F" is registered as a team member.

In addition, characters registered as support cards (support characters) or specific characters in the character identification information table are registered as sub-members. That is, in the case of Figure 8, "Character E," "Character F," "Character I," "Character J," "Character L," "Character M," "Character N," "Character Q," "Character R," and "Character T" are registered as sub-members. In the case of Figure 9, "Character E," "Character J," "Character L," "Character M," "Character N," "Character Q," "Character R," and "Character T" are registered as sub-members.

In addition, in the character identification information table, characters or support cards (support characters) owned by the player that are not registered as team members or sub-members are registered as random members. Note that all of the remaining characters that are not registered as team members or sub-members, or a selection of characters selected by lottery, may be registered as random members.

In this way, information regarding team members, sub-members, and random members (initial character identification information) is stored in the character identification information table.

<Growth stage treatment>
When the preparation stage process is completed, the development stage process begins. In the development stage process, it is possible to develop the main character and characters registered as team members. Figure 10 is a diagram illustrating a selection item table. Note that a selection item table may be provided according to the type of main character, or a common selection item table may be provided regardless of the type of main character.

As shown in Figure 10, the training game consists of turns 1 through 60, and features gameplay in which various parameters are updated depending on the player's selections in each turn.

Figure 11A is a first diagram illustrating a game screen 70. Figure 11B is a second diagram illustrating a game screen 70. When the development stage processing begins, the game screen 70 shown in Figures 11A and 11B is displayed on the display 26. A stamina display section 71 and a condition display section 72 are displayed at the top of the game screen 70. The main character is provided with a "stamina" parameter. The "stamina" parameter is primarily used to calculate the failure rate, which is the probability of failing in training, as described below. The stamina display section 71 is displayed so that the current remaining "stamina" of the main character can be visually grasped relative to the upper limit of "stamina."

The main character is also given a "condition" parameter. The condition display section 72 displays the main character's current "condition" in multiple stages (five stages: very poor, poor, average, good, and excellent) so that it can be visually grasped. The higher the "condition" parameter, the more advantageous the main character's race development will be, and the greater the increase in ability parameters through training.

11A and 11B, the central portion of the game screen 70 displays an image of the main character, a status display section 73 showing the current status of the main character as a number and a number of rank levels (16 levels: G ^{+ ,} F, F ⁺ , E, E ⁺ , D, D ⁺ , C, C ^{+, B, B+} , A, A ⁺ , S, SS, SS ⁺ ), and a skill point display section 74 showing the remaining number of skill points possessed by the main character in the training game as a number. Specifically, in this embodiment, the numbers and ranks of each ability parameter, "Speed,""Stamina,""Power,""Spirit," and "Wisdom," are displayed.

Also, as shown in Figures 11A and 11B, the bottom of the game screen 70 displays a rest operation section 75 marked "Rest," a training operation section 76 marked "Training," a skill operation section 77 marked "Skill," a going out operation section 78 marked "Going Out," an individual race operation section 79a marked "Race," and a team race operation section 79b marked "Team Race."

The individual race operation section 79a shown in Figure 11A and the team race operation section 79b shown in Figure 11B share a common display area on the game screen 70. The current number of turns is also displayed at the top of the game screen 70.

In addition, the player selects one of the following options for each turn: "Rest" (rest operation unit 75), "Training" (training operation unit 76), "Going Out" (going out operation unit 78), "Race" (individual race operation unit 79a), or "Team Race" (team race operation unit 79b). At this time, the options available for selection for each turn are preset, as shown in Figure 10.

In this embodiment, when the "Team Race" (team race operation unit 79b) item is selectable, such as at turns 20, 30, 35, 57, 59, and 60 shown in FIG. 10, the "Rest" (rest operation unit 75), "Training" (training operation unit 76), "Going Out" (going out operation unit 78), and "Race" (individual race operation unit 79a) items are set to be unselectable. Furthermore, when the "Rest" (rest operation unit 75), "Training" (training operation unit 76), "Going Out" (going out operation unit 78), and "Race" (individual race operation unit 79a) items are selectable, the "Team Race" (team race operation unit 79b) item is set to be unselectable.

On the other hand, the skill operation section 77 is set to be selectable at all times during every turn. Furthermore, as will be explained in more detail below, even if a skill is acquired, the turn does not end.

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

As shown in Figure 12A, training items are displayed at the bottom of the training screen 80. Here, a speed control section 81 marked "Speed," a stamina control section 82 marked "Stamina," a power control section 83 marked "Power," a tenacity control section 84 marked "Spirit," and an intelligence control section 85 marked "Wisdom" are displayed.

When the player taps one of the operation units 81-85 once, the training item corresponding to the tapped operation unit 81-85 is provisionally selected, and the operation unit 81-85 corresponding to the provisionally selected training item is highlighted. Figure 12A shows the power operation unit 83 provisionally selected. Figure 12B shows the stamina operation unit 82 provisionally selected.

In addition, each operation unit 81-85 also displays the training level for each training item. As will be described in detail below, the training level is a parameter that increases as the team ranking increases, and the higher the training level, the greater the numerical increase in ability parameters when training is performed. The training level is initially set to level 1 and can increase up to a maximum of level 5.

In addition, the operation units 81-85 that are currently selected display a failure rate display unit 86 labeled "Failure." The failure rate, displayed numerically in the failure rate display unit 86, is set to increase in inverse proportion to the remaining stamina displayed in the stamina display unit 71.

In addition, the status display section 73 displays the value by which the ability parameter will increase if the training corresponding to the provisionally selected operation section 81-85 is performed and successful. For example, in Figure 12A, the power operation section 83 is provisionally selected, and the status display section 73 displays "Stamina" as "+8" and "Power" as "+10". In Figure 12B, the stamina operation section 82 is provisionally selected, and the status display section 73 displays "Stamina" as "+15" and "Spirit" as "+5".

In addition, an event notification display 87 is displayed on the operation units 81-85 corresponding to training items for which an event (a hint event, a support event, or a training event, as described below) will occur when training is performed. Note that the event notification display 87 can be displayed in different ways depending on the type of event.

In addition, in the upper right corner of the training screen 80, an icon 88 of the character placed in the training (joint training) is displayed for each of the tentatively selected operation units 81 to 85. In other words, one or more of the multiple sub-characters different from the main character are associated with one of the multiple types of training items (training events).

Furthermore, if a predetermined event (for example, a hint event, support event, or instruction event, as described below) occurs in response to the character displayed on the icon 88 while training is being performed, an event notification display 87 will be displayed on the corresponding icon 88.

Figure 12C is a diagram illustrating the training result notification screen 80a. When one of the provisionally selected operation units 81-85 is tapped again, the training corresponding to the tapped operation unit 81-85 is performed. In this way, multiple types of training items (training events) can be selected that correspond to one or more of the multiple ability parameters (ability information) that indicate the main character's abilities.

When the training is completed, a training result notification screen 80a is displayed on the display 26, informing the player of the success or failure of the training. Here, the word "Success" is displayed, informing the player of the success of the training.

At this time, the ability parameters displayed in the status display section 73 are updated based on the success of the training. In other words, the ability parameters (ability information) of the main character corresponding to the training item (training event) selected by the player are updated.

Here, the value of the ability parameter that increases if the training displayed in the status display section 73 in Figure 12A or 12B above is successful is added. In addition, the display in the stamina display section 71 is updated according to the training item performed. If speed, stamina, power, or perseverance training is performed and successful, stamina will decrease. On the other hand, if intelligence training is performed and successful, stamina will recover.

Failure to complete training will result in a prescribed penalty. Specific examples of the penalty include a decrease in stamina, a decrease in the numerical value of an ability parameter, and a decrease in condition. For example, a more severe penalty may be imposed when the failure rate is high (a larger decrease in stamina, a larger decrease in the numerical value of an ability parameter, or a larger decrease in condition) than a penalty imposed when the failure rate is low. The penalty may also be determined according to the training item. For example, if speed training is performed and fails, the value of the speed ability parameter may decrease, or if power training is performed and fails, the value of the power ability parameter may decrease. For some training items (e.g., intelligence), no penalty may be imposed even if training fails.

Figure 12D is a diagram illustrating the event screen 80b. When the display of the training result notification screen 80a ends, the event screen 80b may be displayed on the display 26. Various events are executed on the event screen 80b. For example, a hint event, support event, or instruction event, which will be described later, may occur. Note that multiple events may occur.

For example, when a hint event occurs, a skill hint is obtained. When a skill hint is obtained, the player can spend skill points to acquire the skill. There are multiple types of skills, and each skill may activate a specific ability. Each skill has its own activation conditions and effects, and when each activation condition is met, the predetermined effect is activated. Skills may be activated during individual races and team races, which are described below.

Events include events that acquire skills, events that restore stamina, events that decrease stamina, events that increase ability parameters, events that decrease ability parameters, events that increase mood, events that decrease mood, etc. Here, there are events that are predetermined for each turn, and events that occur when you win a predetermined lottery.

Also, once all events have ended, the game screen 70 for the next turn will be displayed.

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

The skill screen 90 displays acquired skills, skills preset for the main character, and skills acquired as a result of various events. In addition, if a hint event occurs for a skill, the skill points consumed to acquire that skill are discounted. Here, for skills for which a hint has been given, the skill points required to acquire them are displayed with a discount. At this time, the discount rate is also displayed.

In addition, the skills displayed on the skill screen 90 display the conditions for activating each skill and the effect that occurs when it is activated.

Also, the top of the skill screen 90 displays a stamina display section 71, a condition display section 72, and a skill point display section 74. Also, the top of the skill screen 90 displays the current number of turns.

When a player consumes skill points and acquires a possessed skill based on their operation, the word "GET" is displayed next to the acquired skill, as shown in Figure 13B, to notify the player that the possessed skill has been acquired, and the consumed skill points are subtracted from the skill points displayed in the skill point display section 74, and the display is updated.

Figure 14A is a diagram illustrating the individual race selection screen 100. When the individual race operation unit 79a on the game screen 70 is operated, the individual race selection screen 100 shown in Figure 14A is displayed. The individual race has a game-like aspect in which the main character races against so-called non-player characters (hereinafter referred to as NPCs).

A stamina display section 71 and a condition display section 72 are displayed at the top of the individual race selection screen 100. An individual race selection operation section 101 for selecting the type of individual race to participate in is displayed at the center of the individual race selection screen 100. A start operation section 102 labeled "Start" is displayed at the bottom of the individual race selection screen 100. The races that can be selected using the individual race selection operation section 101 on the individual race selection screen 100 are set in advance for each turn. Conditions for participating in each race may also be set in advance, and the player may participate in that race if the conditions are met.

Figure 14B is a diagram illustrating the individual race start screen 110. When the type of individual race to participate in is selected using the individual race selection operation unit 101 and the start operation unit 102 is operated, the individual race start screen 110 shown in Figure 14B is displayed. A strategy display unit 111 is displayed in the center of the individual race start screen 110. The strategy display unit 111 also highlights the currently selected strategy (chasing, overtaking, leading, or breaking away), and displays a change operation unit 112 labeled "Change." 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 for 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 labeled "Result" and a race operation section 114 labeled "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 video of the race unfolding (hereinafter also referred to as the race video).

Figure 14C is a diagram illustrating the individual race result screen 120. When playback of the race video described above has finished, or when the result operation unit 113 is operated, the individual race result screen 120 is displayed on the display 26. The individual race result screen 120 displays the finishing order of the individual race.

Figure 15A is a diagram illustrating the team race selection screen 130. When the team race operation unit 79b on the game screen 70 is operated, the team race selection screen 130 shown in Figure 15A is displayed. In the center of the team race selection screen 130, an opponent team selection operation unit 131 is displayed for selecting opponents for the team race in which the player will participate. The opponents can be NPCs. Furthermore, the opponents are not limited to NPCs, and may also be the team of another player. In this case, a communication battle is held with the team of another player.

Note that characters to compete in team races do not necessarily have to be main characters, as long as they can be selected from team members. Also, one team member may be able to compete in multiple races in a team race.

Figure 15B is a diagram illustrating the team formation screen 140. When the opposing team selection operation unit 131 is operated, the team formation screen 140 is displayed on the display 26. The team formation screen 140 displays a team formation operation unit 141. By operating the team formation operation unit 141, the player can form a character formation for the team race using characters registered as team members. In this embodiment, five races are held in the team race: "Short Distance," "Mile," "Middle Distance," "Long Distance," and "Dirt." The game has a feature in which the overall victory or defeat of the team race is determined based on the victory or defeat of each race.

Specifically, if the player's team wins more races out of the five races than the opponent's team, the player will win the team race overall. On the other hand, if the player's team wins fewer or the same number of races out of the five races as the opponent's team, the player will lose the team race overall. Players can organize up to three types of characters from their team members for each race. Note that characters of the same type cannot be organized into multiple races. A start operation unit 142 marked "Start" is displayed at the bottom of the team organization screen 140.

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

As shown in Figure 15C, the center of the team race start screen 150 displays the characters of the player's team for the race to be held and the characters of the opponent's team. Here, the example shows a case where the player has organized two characters for a "middle distance" race, and the opponent has organized two characters.

Also, as shown in Figure 15C, a result operation section 151 marked "Result" and a race operation section 152 marked "Race" are displayed at the bottom of the team race start screen 150. When the race operation section 152 is operated, a race video (not shown) is displayed.

Figure 15D is a diagram illustrating the team race interim results screen 160. When playback of the race video described above has finished, or when the result operation unit 151 on the team race start screen 150 is operated, the team race interim results screen 160 is displayed on the display 26. The team race interim results screen 160 displays the results of the race (here, the "middle distance" race). Note that there are no particular limitations on the method for determining the results of each of the five races in the team race. For example, the team to which the character that placed first belongs may be declared the winner. Alternatively, points may be awarded for each finishing order, and the team with the most points may be declared the winner.

Then, when the display of the team race interim results screen 160 in FIG. 15D is finished, the team race start screen 150 for the next race (for example, a "short distance" race) is displayed, and thereafter, in the same manner as above, the team race start screen 150 and the team race interim results screen 160 are displayed sequentially until all five types of races are completed.

Figure 16A is the first diagram illustrating the team race detailed results screen 170. Once the team race start screen 150 and team race interim results screen 160 for all five types of races have been displayed as described above, the team race detailed results screen 170 is displayed on the display 26. A win/loss result display section 171 is displayed in the center of the team race detailed results screen 170. The win/loss result display section 171 notifies the player of the win/loss results for each race. Here, as shown in Figure 16A, a case is shown in which there are three wins and two losses in each race.

Figure 16B is the first diagram illustrating the team race overall result screen 180. When the display of the win/loss result display section 171 ends, the team race overall result screen 180 is displayed on the display 26. The team race overall result screen 180 notifies the player of the overall win/loss results of the team race. As shown in Figure 16A, if there are 3 wins and 2 losses in each race, the team race overall result screen 180 will notify the player that the team has won the team race.

The team race overall results screen 180 also displays team rankings. In this embodiment, team rankings change based on the results of team races. For example, if a team wins a team race, the team ranking will rise.

In addition, on the team race overall results screen 180, which notifies the team that they have won the team race, a next operation unit 181 marked "NEXT" is displayed. When the next operation unit 181 on the team race overall results screen 180 is operated, the game screen 70 for the next turn is displayed.

Figure 16C is a second diagram illustrating the team race detailed results screen 170. Here, as shown in Figure 16C, a case is shown in which there are two wins and three losses in each race. Figure 16D is a second diagram illustrating the team race overall results screen 180. As shown in Figure 16C, if there are two wins and three losses in each race, the team race overall results screen 180 will notify you that the team has lost the team race.

In addition, on the team race overall results screen 180, which notifies the player that they have lost the team race, a continue operation section 182 marked "Continue" and a finish operation section 183 marked "Finish" are displayed.

When the continue operation unit 182 is operated, the results of the team race are discarded and the next five team races are restarted from the beginning. Note that the number of times a team can continue may be set within a predetermined maximum number of continuations.

Furthermore, if the finish operation unit 183 is operated, the game is over and the training game ends. However, the team race overall result screen 180, which notifies players that they have lost a team race, may display the next operation unit 181 without displaying the continue operation unit 182 and finish operation unit 183. In other words, even if a player loses a team race, the training game may continue without a game over. As described above, in this embodiment, a competitive game (individual race or team race) is played using either or both of the main character and sub-characters registered as team members.

Figure 17 is a diagram explaining the relationship between team members, sub-members, and random members. Below, characters registered as team members, characters registered as sub-members, and characters registered as random members may be simply referred to as team members, sub-members, and random members, respectively. In this embodiment, random members may be promoted to sub-members as the training game progresses. Specifically, as shown in Figure 17, once joint training with a random member is successful, the random member is promoted to sub-member.

Here, joint training refers to training in which the player selects and executes a training item in which a character is assigned. Therefore, if a training item in which a random member is assigned is selected and the training is successful, the random member will be promoted to a sub-member.

However, without being limited to this, if joint training with a random member is successful, a predetermined lottery may be held, and if the random member wins the lottery, the random member may be promoted to a sub-member. Alternatively, if joint training with a random member is held a predetermined number of times, the random member may be promoted to a sub-member, regardless of whether the training is successful or not.

Sub-members may also be demoted to random members. Specifically, as shown in FIG. 17, if joint training with a sub-member is unsuccessful over 20 turns, the sub-member is demoted to a random member. Note that if joint training with a sub-member is unsuccessful over 20 turns, the character registered for that sub-member may simply be deleted from the list of sub-members. In this case, that sub-member will no longer appear in the training game. Furthermore, for example, if joint training with a sub-member is not completed for a preset number of turns, the sub-member may be deleted or demoted to a random member.

In addition, in this embodiment, sub-members may be registered as team members. Specifically, sub-members are assigned registration parameters. The registration parameters are updated when predetermined registration conditions are met. As shown in FIG. 17, when the value of a sub-member's registration parameter becomes equal to or greater than a predetermined threshold value (100), the sub-member is registered as a team member.

Once a character is registered as a team member, it cannot be changed to a sub-member or random member. However, if a character registered as a team member meets certain pre-set conditions, it may be changed to a sub-member or random member.

Figure 18 is a diagram illustrating the registration parameter table. In this embodiment, characters registered as sub-members are assigned registration parameters. These registration parameters are used to determine whether or not a sub-member can be promoted to a team member.

Specifically, when a specific character is registered as a sub-member, "40" is registered as the initial value of the registered parameters, as shown in Figure 18. Then, each time a joint training session with that specific character is successful, an increase value randomly determined from between "10" and "20" is added to the registered parameters.

Furthermore, when a support character associated with a support card is registered as a sub-member, "0" is registered as the initial value of the registered parameters, as shown in Figure 18. Then, each time joint training with that support character is successful, an increase value randomly determined from "10" to "20" is added to the registered parameters. Note that here, if a support card (support character) and a specific character overlap, they are treated as the specific character. However, if a specific character overlaps with a support character, either or both of the initial value and the increase value may be set to an even higher value.

Furthermore, when a character other than a specific character or support character is registered as a sub-member, "0" is registered as the initial value of the registered parameters, as shown in FIG. 18. Then, each time joint training with that other character is successful, an increase value randomly determined from "5" to "10" is added to the registered parameters. In other words, the registered parameters of the sub-character associated with the training item (development event) selected by the player are updated. Note that here, the increase value of the registered parameters when joint training is successful is determined by lottery. However, the increase value may be a fixed value. Furthermore, the increase value may differ depending on the type of character.

In other words, the registration parameters of the sub-character associated with the training event selected by the player are updated based on predetermined registration conditions.

As shown in FIG. 18, specific characters have higher initial values for registered parameters than support characters and other characters, making it easier for their registered parameters to reach the threshold (100) than support characters and other characters. Furthermore, support characters have higher increased registered parameters than other characters, making it easier for their registered parameters to reach the threshold (100) than other characters. Thus, in this embodiment, specific characters and support characters are more likely to be promoted to team members than other characters.

Note that while this embodiment only illustrates cases where registered parameters increase, registered parameters may also decrease as long as they are updated based on predetermined registration conditions. For example, registered parameters may be set to decrease if training fails.

Figure 19 is a diagram explaining the general flow of the turn start processing. The development stage processing includes turn start processing, which is executed at the start of each turn in the development game. Details of the turn start processing will be explained in Figures 31, 32, 33, and 34, which will be described later. Here, we will explain the general flow of the turn start processing.

The turn start processing roughly involves the following processes, as shown in Figure 19: "Process to determine the number of random members to be placed," "Process to determine the aptitude type of the random members to be placed," "Process to determine the random members to be placed," "Process to determine whether or not to place team members," "Process to determine whether or not to place sub-members," "Process to determine the training items to be placed," "Process to determine the increase value of ability parameters," and "Process to determine the events that will appear."

<Process to determine the number of random members to be placed>
20A is a diagram illustrating a random member placement number table. In this embodiment, the total number of characters placed in each training (joint training) is limited to a maximum of 20.

As shown in Figure 20A, the number of characters to be placed in each training session is determined from the characters registered as random members based on the total number of characters registered as team members and characters registered as sub-members.

In this embodiment, as shown in FIG. 20A, if the total number of team members and sub-members is 20 or more, the number of random members to be placed is determined to be 0. Furthermore, if the total number of team members and sub-members is 19, the number of random members to be placed is determined to be 0 or 1 with a predetermined probability. Furthermore, if the total number of team members and sub-members is 18 or less, the number of random members to be placed is determined to be 0, 1, or 2 with a predetermined probability. Note that if the number of random members to be placed is determined to be 0, no random members will be placed in any training items.

<Process to determine the aptitude type of random members to be placed>
20B is a diagram illustrating an aptitude number table. As shown in FIG. 20B, in this embodiment, the number of characters registered as team members whose aptitude parameters related to a preset aptitude type are set to "A" (or "S") (A aptitude number) is stored. Specifically, in this embodiment, as shown in FIG. 20B, the preset aptitude types are set to "short distance,""mile,""middledistance,""longdistance," and "dirt."

The aptitude number table will be updated when a sub-member is promoted to a team member, or when certain conditions are met during the training game and the aptitude parameters for the above aptitude types of a team member's character are updated.

Here, as shown in Figure 20B, the A aptitude number A for "short distance" is stored as "3", the A aptitude number A for "mile" is stored as "2", the A aptitude number A for "medium distance" is stored as "3", the A aptitude number A for "long distance" is stored as "1", and the A aptitude number A for "dirt" is stored as "1".

As shown in Figure 5B, for example, character C has aptitude parameters of "A" for "mile" and "medium distance," and if character C is registered as a team member, he will be counted as a character with an "A" for both "mile" and "medium distance." In other words, the total value of each A aptitude number in Figure 20B does not necessarily match the total number of characters registered as team members.

Then, as described above, if the number of random members to be placed is determined to be "1" or "2" based on the lottery probability in Figure 20A, the character to actually be placed in the training item is determined from the characters registered as random members. In this embodiment, the aptitude number table is first referenced to extract the aptitude type with the lowest A aptitude number.

As shown in Figure 20B, if there are multiple aptitude types with the fewest A aptitude numbers, the aptitude type is extracted based on a preset priority order. Here, the priority order is set as "Short distance" > "Mile" > "Medium distance" > "Long distance" > "Dirt." For example, in the case of Figure 20B, the A aptitude numbers for "Long distance" and "Dirt" are registered as "1," so "Long distance" is extracted, as it has the highest priority of the two. Then, from the characters registered as random members, a random member whose extracted aptitude type (here, "Long distance") is "A" is extracted, and one character from the extracted random members is selected by lottery.

The specific lottery method is not particularly limited. For example, there may be random members that are more likely to be selected by lottery and random members that are less likely to be selected by lottery. For example, with reference to Figures 5A and 5B, the higher the initial values of the ability parameters or aptitude parameters of a random member, the more unlikely it is to be selected by lottery. Alternatively, the lottery may be held with equal probability. The random member selected by the lottery is then stored as the random member to be placed in one of the training items.

If there are multiple random members to be placed, the above-mentioned extraction of the aptitude type with the lowest A aptitude number and the lottery of random members with the extracted aptitude type "A" are repeated the number of times to be placed. In this case, when the random member to be placed is determined, the aptitude number table may be temporarily updated based on the aptitude parameters of the random member to be placed (see Figure 5B). In other words, when determining the second random member, the aptitude type of the first random member may be taken into account. This promotes equalization of the A aptitude number for each aptitude type.

<Process for determining whether team members are assigned and process for determining whether sub-members are assigned>
21 is a diagram illustrating a placement table. As shown in Fig. 21, the placement table sets a selection ratio of placement ("place" or "do not place") for each character's character identification information. In this embodiment, the placement of all team members and sub-members is determined based on the placement table shown in Fig. 21 and by referring to the character identification information table shown in Fig. 8 or 9.

Specifically, as shown in FIG. 21, in this embodiment, if the character identification information registered is "support character," "specific character," and "team member," there is an 80% chance that "Place" will be selected. Furthermore, if the character identification information registered is "support character," "specific character," and "sub-member," there is a 40% chance that "Place" will be selected.

Furthermore, if the character identification information is registered as "support character" and "team member," there is a 60% chance that "Place" will be selected.Furthermore, if the character identification information is registered as "support character" and "sub-member," there is a 20% chance that "Place" will be selected.

Furthermore, if the character identification information is registered as "specific character" and "team member," there is a 60% chance that "Place" will be selected.Furthermore, if the character identification information is registered as "specific character" and "sub-member," there is a 20% chance that "Place" will be selected.

If "Team Member" is registered as the character identification information, there is a 40% chance that "Place" will be selected. If "Sub-Member" is registered as the character identification information, there is a 10% chance that "Place" will be selected.

In other words, as shown in Figure 21, the character identification information is set so that when it includes "team member," the probability of selecting "Place" is higher than when it includes "sub-member."

Furthermore, as shown in Figure 21, when the character identification information includes "support character," the probability of selecting "Place" is set to be higher than when the character identification information does not include "support character."

Furthermore, as shown in FIG. 21, when the character identification information includes a "specific character," the probability of selecting "Place" is set to be higher than when the character identification information does not include a "specific character."

In other words, sub-members who are set as support characters are more likely to be associated with training items (training events) than sub-members who are not set as support characters. Furthermore, sub-members include specific characters (predetermined specific sub-characters), and these specific characters are more likely to be associated with training items (training events) than characters other than the specific characters.

<Process to determine the training items to be placed>
Next, for the "random member,""teammember," and "sub-member" whose placement has been determined as described above, it is determined which training item they will be placed in: "Speed,""Stamina,""Power,""Spirit," or "Wisdom."

The method for determining the training items to be placed is not particularly limited, but for example, a lottery may be held to ensure that each training item has an equal chance of being selected. Alternatively, the training items may be placed in training items that are preset for each character without a lottery. Furthermore, for example, a lottery may be held to ensure that training items are more likely to be placed in a character's specialty training (see Figure 7A). When a lottery is held, a lottery table that determines the selection ratio for the lottery may be stored in advance, or a lottery table may be created each time a lottery is held.

<Process to determine the increase value of ability parameters>
22A is a diagram illustrating a training level table. As shown in FIG. 22A , the training level is set to increase as the team ranking increases. Specifically, if the team ranking is 100th or lower, the training levels for "Speed,""Stamina,""Power,""Spirit," and "Wisdom" are set to "Level 1." If the team ranking is 99th or higher but 60th or lower, the training levels are set to "Level 2." If the team ranking is 59th or higher but 30th or lower, the training levels are set to "Level 3." If the team ranking is 29th or higher but 10th or lower, the training levels are set to "Level 4." If the team ranking is 9th or higher but 10th or lower, the training levels are set to "Level 5."

In this embodiment, the training level is set to increase as the team ranking increases, but this is not limited to this. For example, the training skills of team members may be counted for each training item, and the training level may increase according to the counted value (count value). Note that, although the training level for all training items is the same for the team ranking here, the training level may differ for each training item for the same team ranking.

In this embodiment, when the training selected by the player is performed and successful, the value of a specified ability parameter increases depending on the training item performed.

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

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

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

In addition, if "Spirit" training is performed and is successful, the values of the ability parameters "Speed," "Power," and "Spirit" will increase.

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

In this embodiment, the value of the ability parameter that increases when training is successful is calculated by multiplying a fixed increase value determined according to the training item and training level performed by a bonus addition rate (described below) and adding the result to the fixed increase value.

Figure 22B is a diagram explaining the fixed increase value (speed) table. Also, Figure 22C is a diagram explaining the fixed increase value table (power). That is, Figure 22B shows the fixed increase value when the training item is "Speed." Also, Figure 22C shows the fixed increase value when the training item is "Power."

As shown in Figures 22B and 22C, the fixed increase value table stores fixed increase values that are determined according to the training item and training level performed. In addition, in this embodiment, as shown in Figures 22B and 22C, the higher the training level, the greater the increase in ability parameters when training is performed.

Although not detailed here, there are also fixed increase value tables for each of the training items "Stamina," "Spirit," and "Wisdom."

In addition to the fixed increase value mentioned above, the bonus addition rate is determined based on the characters placed for each training item and the character identification information table shown in Figure 8 or Figure 9 above.

Figure 22D is a diagram illustrating the bonus addition rate table. In this embodiment, the bonus addition rate is determined based on the character identification information of the character assigned to each training session.

Specifically, as shown in Figure 22D, the bonus addition rate table sets, for each character's character identification information, whether or not a bonus addition rate is available and the selection ratio of the addition rate (10% increase or 20% increase).

If "Support Character," "Specific Character," and "Team Member" are registered as character identification information, there is a 50% chance that "None" will be selected, and a 50% chance that "20% Up" will be selected.

Also, if "Support Character" and "Team Member" are registered as character identification information, there is a 50% chance that "None" will be selected, and a 50% chance that "10% Up" will be selected.

Also, if "Specific Character" and "Team Member" are registered as character identification information, there is a 50% chance that "None" will be selected, and a 50% chance that "10% Up" will be selected.

Also, if "Team Member" is registered as character identification information, there is an 80% chance that "None" will be selected, and a 20% chance that "10% Up" will be selected.

In addition, if "Support Character" and "Specific Character" are registered as character identification information, if "Support Character" is registered as character identification information, if "Specific Character" is registered as character identification information, or if none of "Support Character", "Specific Character", and "Specific Character" are registered as character identification information, there is a 100% chance that "None" will be selected.

In other words, as shown in Figure 22D, when the character identification information includes "Team Member," the probability of selecting "10% Up" or "20% Up" is set to be higher than when "Team Member" is not included.

The amount of increase in the ability parameter value if the training is successful is then determined by multiplying the fixed increase value determined by the fixed increase value table by the bonus addition rate and adding the result to the fixed increase value. For training in which multiple characters are assigned, the amount of increase in the ability parameter value of the main character if the training is successful is determined by adding the bonus addition rates of each of the assigned characters, multiplying the total bonus addition rate by the fixed increase value, and then adding the fixed increase value. In the same way, the amount of increase in the ability parameter value of the main character if the training is successful is determined for all training types.

<Process to determine occurrence events>
FIG. 23 is a diagram illustrating a utility table. In this embodiment, when team members are assigned to the executed training, a training event or a hint event may occur as an event based on the conditions shown in FIG. 23. Note that in this embodiment, training events occur the same number of times as the number of team members who satisfy the predetermined conditions described below, whereas hint events occur only once per turn even if there are multiple team members who satisfy the predetermined conditions described below. Note that hint events may occur the same number of times as the number of team members who satisfy the predetermined conditions described below.

Specifically, as shown in FIG. 23, possible events are set based on the magnitude relationship of the ability parameters targeted by the training items. For example, when "Speed" training is performed, the ability parameters of the main character and team members related to the training item being performed ("Speed") are compared. In other words, the ability parameters (ability information) corresponding to the training item (training event) selected by the player are compared. Note that, for example, the total value of all ability parameters may be compared. Alternatively, the values of predetermined ability parameters may be compared. Alternatively, the values of ability parameters that are improved by the training item selected by the player may be compared.

Here, when team members are assigned and a training item is selected, the ability parameters indicating the team member's abilities are compared with the ability parameters of the main character for each team member associated with that training item.

The system is set up so that if the main character's ability parameters are equal to or greater than the ability parameters of a team member, a training event will always occur. Training events include a "success" execution pattern and a "great success" execution pattern, as will be described in more detail below. When a training event occurs and the training event has a "success" execution pattern, the team member's ability parameters will increase within a predetermined range. Furthermore, if the training event has a "great success" execution pattern, the team member's ability parameters will increase by a greater amount than the above-mentioned predetermined range, and a predetermined special event will also be carried out. In a special event, for example, the main character can acquire skill hints.

However, the present invention is not limited to this, and the ability parameters of the main character may be increased when a training event occurs. Also, when a training event occurs, the character whose ability parameters will be increased may be determined by lottery from among the team members. In this case, the number of characters selected by lottery may be 0, 1, or 2 or more.

Furthermore, if the ability parameters of the main character are lower than the ability parameters of a team member, a hint event related to a skill possessed by the team member can occur. Note that if there are multiple team members with ability parameters higher than the ability parameters of the main character, a hint event related to a skill possessed by any one of the team members will occur. Furthermore, as shown in FIG. 23, when a hint event occurs, the main character will acquire a hint for the possessed skill related to the hint event. Note that this may also include cases where a hint event is executed in which the ability parameters of the main character increase, or in which the main character acquires a skill that he or she has already acquired.

In other words, based on the results of a comparison between the ability parameters (ability information) of the sub-character and the ability parameters (ability information) of the main character, either a hint event (first type of event) that increases the ability parameters (ability information) of the main character or a training event (second type of event) that increases the ability parameters (ability information) of the sub-character is generated. Furthermore, the ability parameters (ability information) of the main character are updated based on the occurrence of a hint event (first type of event), and the ability parameters (ability information) of the sub-character are updated based on the occurrence of a training event (second type of event). Furthermore, if the ability parameters (ability information) of the sub-character are higher than the ability parameters (ability information) of the main character, a hint event (first type of event) is generated. Furthermore, if the ability parameters (ability information) of the main character are higher than the ability parameters (ability information) of the sub-character, a training event (second type of event) is generated.

Figure 24A is the first diagram explaining the event determination process. Figure 24A shows a case where there are five team members assigned to "Speed." In this case, the ability parameters related to "Speed" of the main character and the ability parameters related to "Speed" of the assigned team member characters are compared to determine which is larger or smaller.

In the case of Figure 24A, for Character A, Character B, and Character C, the main character has a higher ability parameter related to "Speed." In this case, a decision is made to execute a training event for each of Character A, Character B, and Character C. A special event is also decided to occur if the training event is a great success for each of them. The process of deciding whether the training event will be executed in a "success" or "great success" execution pattern is executed when "Speed" training is performed based on the player's operation.

In the case of Figure 24A, the ability parameter related to "Speed" for characters D and E is lower for the main character. In this case, the content of the hint event to be executed for characters D and E is determined by lottery. Note that the process of determining which hint event to execute for character D or character E is executed when "Speed" training is executed based on the player's operation.

In other words, if a training item (training event) associated with multiple sub-characters is selected during one turn, both a hint event (first type of event) and a guidance event (second type of event) may occur.

Figure 24B is a second diagram illustrating the process for determining whether or not an event will occur. Figure 24B shows a case where there are five team members placed in "Stamina." In the case of Figure 24B, for Character A, Character B, Character C, Character D, and Character E, the main character has a higher ability parameter for "Stamina." In this case, it is determined that a training event will be executed for each of Character A, Character B, Character C, Character D, and Character E. In addition, it is determined that a hint event will occur if the training event is a great success for each of them.

Figure 24C is a third diagram illustrating the process for determining whether or not an event will occur. Figure 24C shows a case where there are five team members assigned to "Stamina." In the case of Figure 24C, for Character A, Character B, Character C, Character D, and Character E, the main character has a lower ability parameter related to "Stamina." In this case, the execution content of the hint event for Character A, Character B, Character C, Character D, and Character E is determined by lottery.

Figure 25A is a diagram illustrating the success pattern table. Figure 25A shows the success pattern table that is referenced when training is performed based on the player's operations and a training event occurs, and the success pattern of that training event ("Success" or "Great Success") is determined.

As shown in Figure 25A, the success pattern table sets the selection ratio for the success pattern of training events ("Success" or "Great Success") according to the number of training events for the target team member. In this embodiment, the selection ratio is set so that the more training events there are, the more likely a training event will be executed with the "Great Success" success pattern. Also, in this embodiment, it is set so that a training event with the "Great Success" success pattern can only be executed once for each team member.

Figure 25B is a diagram illustrating the bonus event table. In this embodiment, when a training event occurs, a predetermined value is further added as a bonus to the main character's ability parameters, as shown in Figure 25B, depending on the training item performed. Note that in this embodiment, if training events involving multiple characters occur in one turn, the value added as the bonus will further increase depending on the number of training events occurring. In other words, when a training event (second type of event) occurs, the main character's ability parameters (ability information) are updated based on the number of sub-characters whose compared ability parameters (ability information) are lower than those of the main character. However, a fixed bonus may be added regardless of the number of training events occurring.

Next, we will explain the functional configuration of the player terminal 1 and server 1000 for executing the above game. Note that we will mainly explain the functional configuration related to the progress of the game, and will omit explanations of other configurations.

(Functional Configuration of Player Terminal 1)
26 is a diagram illustrating the configuration of the memory 12 in the player terminal 1 and its computer functions. The memory 12 is provided with a program storage area 12a and a data storage area 12b. When a game starts, 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, and a game execution control program 206. Note that the programs listed in Figure 26 are just examples, and the terminal-side game control program includes many other programs.

The data storage area 12b is provided with a player information storage unit 300 as a storage unit for storing data. Note that the data storage area 12b also has many other storage units.

The CPU 10 runs each program stored in the program memory area 12a and updates the data in each storage unit in the data memory area 12b. By running each program stored in the program memory area 12a, the CPU 10 causes the player terminal 1 (computer) to function as a terminal game control unit 1A. The terminal game control unit 1A includes a transmission/reception unit 200a, a character lottery unit 202a, a player information update unit 204a, and a game execution control unit 206a.

Specifically, the CPU 10 runs the transmission/reception program 200, causing the computer to function as the transmission/reception unit 200a. Similarly, the CPU 10 runs the character lottery program 202, the player information update program 204, and the game execution control program 206, causing them to function as the character lottery unit 202a, the player information update unit 204a, and the game execution control unit 206a, respectively.

(Functional configuration of server 1000)
27 is a diagram illustrating the configuration of the memory 1012 in the server 1000 and its computer functions. The memory 1012 is provided with a program storage area 1012a and a data storage area 1012b. When a game is started, the CPU 1010 stores a server-side game control program (module) in the 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. Note that the programs listed in Figure 27 are just examples, and the server-side game control program includes many other programs.

The data storage area 1012b includes a player information storage unit 1300 as a storage unit for storing data. Note that the above storage units are examples, and the data storage area 112b also includes many other storage units.

The CPU 1010 runs each program stored in the program memory area 1012a and updates the data in each memory unit in the data memory area 1012b. By running each program stored in the program memory area 1012a, the CPU 1010 causes the server 1000 to function as a server-side game control unit 1000A. 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, the CPU 1010 runs the transmission/reception program 1200, causing the computer to function as a transmission/reception unit 1200a. Similarly, the CPU 1010 runs the character lottery program 1202, the player information update program 1204, and the game execution control program 1206, causing them to function as a character lottery unit 1202a, a player information update unit 1204a, and a game execution control unit 1206a, respectively.

The transmitter/receiver units 200a and 1200a transmit and receive various information between the player terminal 1 and the server 1000.

The character lottery unit 202a, 1202a controls processing related to the gacha lottery.

The player information update unit 204a, 1204a stores all information related to the player as player information in the player information storage unit 300, 1300.

The game execution control unit 206a, 1206a controls the overall progress of the game.

(Communication Processing Between Player Terminal 1 and Server 1000)
28 is a sequence diagram illustrating basic processing of the player terminal 1 and the server 1000. In the following description, processing in the player terminal 1 will be referred to as Pn (n is an arbitrary integer), and processing in the server 1000 will be referred to as Sn (n is an arbitrary integer).

When a player performs an input operation (lottery request operation) on the gacha screen (not shown), the character lottery unit 202a of the player terminal 1 executes a lottery request information transmission process (P1) that transmits lottery request information to the server 1000.

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 a lottery process (S1) and enables the player terminal 1 to receive lottery result information indicating the lottery results. Furthermore, 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).

When the transmitter/receiver unit 200a of the player terminal 1 receives the lottery result information, the game execution control unit 206a displays the lottery result indicated in the lottery result information on the display 26 (P2). Furthermore, 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).

Furthermore, when the player operates the scenario operation unit 29 on the home screen 27 (operation to start the training game), the game execution control unit 206a of the player terminal 1 displays the main character selection screen 30 on the display 26 and executes a start information transmission process (P4) to transmit start information to the server 1000.

When the transmission/reception unit 200a of the server 1000 receives the start information, the game execution control unit 1206a of the server 1000 executes a necessary information output process (S3) to enable the player terminal 1 to receive the necessary information. The necessary information includes information on various tables necessary for executing the training game.

When the transmitter/receiver unit 200a of the player terminal 1 receives the necessary information, the player information update unit 204a of the player terminal 1 stores the necessary information in the data storage area 12b, and the preparatory stage processing (P5) is executed on the player terminal 1.

Figure 29 is a flowchart illustrating the preparatory stage processing (P5) at the player terminal 1. The game execution control unit 206a of the player terminal 1 determines whether the main character selection screen 30 is currently being displayed on the display 26 (P5-1). As a result, if the main character selection screen 30 is currently being displayed, processing proceeds to step P5-2; if the main character selection screen 30 is not currently being displayed, processing proceeds to step P5-7.

The game execution control unit 206a of the player terminal 1 determines whether a long press on the character icon 31 on the main character selection screen 30, an operation of the skill operation unit 41 or event operation unit 42 on the character details screen 40, or an operation of the menu bar 28, return operation unit 33, or next operation unit 34 on the main character selection screen 30 or character details screen 40 (display switching operation input) has been performed (P5-2). As a result, if a display switching operation input has been performed, processing proceeds to step P5-16; if a display switching operation input has not been performed, processing proceeds to step P5-3.

The game execution control unit 206a of the player terminal 1 determines whether a character icon 31 on the main character selection screen 30 has been operated (selection operation input) (P5-3). If a selection operation input has been performed, the process proceeds to step P5-4; if a selection operation input has not been performed, the process proceeds to step P5-5.

The game execution control unit 206a of the player terminal 1 temporarily stores the character corresponding to the character icon 31 for which the selection operation input was performed in the player information storage unit 300 (P5-4).

The game execution control unit 206a of the player terminal 1 determines whether the next operation unit 34 on the main character selection screen 30 has been operated (a confirmation operation input) (P5-5). If a confirmation operation input has been performed, processing proceeds to step P5-6; if a confirmation operation input has not been performed, processing proceeds to step P5-7.

The game execution control unit 206a of the player terminal 1 registers the character temporarily stored in step P5-4 above as the main character in the player information storage unit 300 (P5-6).

The game execution control unit 206a of the player terminal 1 determines whether the support card setting screen 50 is currently being displayed on the display 26 (P5-7). If the support card setting screen 50 is currently being displayed, processing proceeds to step P5-8; if the support card setting screen 50 is not currently being displayed, the preparation stage processing ends.

The game execution control unit 206a of the player terminal 1 determines whether the menu bar 28 or the return operation unit 53 on the support card setting screen 50 has been operated (display switching operation input) (P5-8). As a result, if the display switching operation input has been performed, processing proceeds to step P5-16; if the display switching operation input has not been performed, processing proceeds to step P5-9.

The game execution control unit 206a of the player terminal 1 determines whether the support card setting operation unit 52 of the support card setting screen 50 has been operated to select the support card (support character) icon 61 on the support card selection screen 60 (selection operation input). As a result, if a selection operation input has been performed, processing proceeds to step P5-10; if a selection operation input has not been performed, processing proceeds to step P5-11.

The game execution control unit 206a of the player terminal 1 temporarily stores the support card (support character) of the icon 61 selected in the player information storage unit 300 (P5-10).

The game execution control unit 206a of the player terminal 1 determines whether the start operation unit 54 on the support card setting screen 50 has been operated (a decision operation input) (P5-11). If a decision operation input has been performed, the process proceeds to step P5-12; if a decision operation input has not been performed, the preparation stage process ends.

The game execution control unit 206a of the player terminal 1 registers the support card (support character) that was temporarily stored in the player information storage unit 300 (P5-12).

The game execution control unit 206a of the player terminal 1 registers the specific character as described above (P5-13).

The game execution control unit 206a of the player terminal 1 sets the initial character identification information as described above (P5-14).

The game execution control unit 206a of the player terminal 1 executes the training stage start process, which displays the game screen 70 on the display 26, and then ends the preparation stage process (P5-15).

The game execution control unit 206a of the player terminal 1 switches the screen being displayed on the display 26 based on the player's operation (P5-16), and ends the preparation stage processing.

Returning to Figure 28, once the preparation stage processing (P5) is completed, the development stage processing (P6) is carried out. Figure 30 is a flowchart explaining the development stage processing in the player terminal 1. The game execution control unit 206a of the player terminal 1 determines whether it is the start of a turn (P6-1). As a result, if it is the start of a turn, the turn start processing of step P10 is executed, and if it is not the start of a turn, the turn in-progress processing of step P20 is executed.

Figure 31 is a flowchart explaining the turn start processing in the player terminal 1. The game execution control unit 206a of the player terminal 1 references the selection item table (Figure 10) stored in the player information storage unit 300 and determines whether the current turn is a turn in which the "Team Race" (team race operation unit 79b) item can be selected (a team race-only turn). If the result shows that it is a team race-only turn, processing proceeds to step P10-2; if it is not a team race-only turn, processing proceeds to step P11.

If it is not a team race limited turn, the game execution control unit 206a of the player terminal 1 executes placement processing (P11), numerical value determination processing (P12), and event determination processing (P13), which will be described in detail below.

If it is a team race limited turn, the game execution control unit 206a of the player terminal 1 executes team race start processing (P10-2). For example, it executes processing to determine opponents in the team race. Furthermore, if the player is competing against another player's team in the team race, it executes processing related to matching with the other player who will be the opponent.

The game execution control unit 206a of the player terminal 1 updates the screen displayed on the display 26 and ends the turn start processing (P10-3).

Figure 32 is a flowchart explaining the placement process at the player terminal 1. The game execution control unit 206a of the player terminal 1 references the character identification information table and derives the total number of characters registered as team members and characters registered as sub-members (P11-1).

The game execution control unit 206a of the player terminal 1 sets the random member placement number table shown in Figure 20A (P11-2).

The game execution control unit 206a of the player terminal 1 determines and stores the number of random members to be placed, based on the total number derived in step P11-1, by referencing the random member placement number table set in step P11-2 (P11-3).

The game execution control unit 206a of the player terminal 1 determines whether the number of random members to be placed determined in step P11-3 above is 0 (P11-4). As a result, if the number is 0, processing proceeds to step P11-10; if the number is not 0, processing proceeds to step P11-5.

The game execution control unit 206a of the player terminal 1 derives the above-mentioned A aptitude number for the characters registered as team members (P11-5).

The game execution control unit 206a of the player terminal 1 extracts and determines the aptitude type with the lowest number of A aptitudes based on the number of A aptitudes derived in step P11-5 above (P11-6).

The game execution control unit 206a of the player terminal 1 generates a lottery table for determining a random member whose aptitude type is "A" as determined in step P11-6 above from among the characters registered as random members (P11-7).

The game execution control unit 206a of the player terminal 1 determines and stores the random members to be placed based on the lottery table generated in step P11-7 above (P11-8).

The game execution control unit 206a of the player terminal 1 decrements the number of random members stored in step P11-3 by 1, and proceeds to step P11-4.

The game execution control unit 206a of the player terminal 1 references the character identification information table and extracts all characters registered as team members and sub-members (P11-10).

The game execution control unit 206a of the player terminal 1 selects a character that has not yet performed the processes P11-12 to P11-16 (described below) from among the team members, sub-members, or random members whose placement was determined in step P11-10 above, as the target character to perform the process (P11-11).

The game execution control unit 206a of the player terminal 1 references the character identification information table and confirms the character identification information of the target character selected in step P11-11 above (P11-12).

The game execution control unit 206a of the player terminal 1 sets the placement presence/absence table (Figure 21) based on the identification information confirmed in step P11-12 above (P11-13).

The game execution control unit 206a of the player terminal 1 determines whether or not to place the item ("place" or "do not place") based on the placement table set in step P11-13 (P11-14).

The game execution control unit 206a of the player terminal 1 determines whether "place" was selected in step P11-14 (P11-15). If "place" was selected, the process proceeds to step P11-16; if "place" was not selected, the process proceeds to step P11-17.

The game execution control unit 206a of the player terminal 1 determines and stores the training item in which to place the target character for which "placement" was determined in step P11-14 above (P11-16).

The game execution control unit 206a of the player terminal 1 determines whether the processing of P11-11 to P11-16 has been completed for all team members, sub-members, and random members whose placements were determined in step P11-10 (P11-17). As a result, if processing has been completed for all members, the placement processing is terminated; if processing has not been completed for all members, the processing proceeds to step P11-11.

Figure 33 is a flowchart explaining the numerical value determination process at the player terminal 1. The game execution control unit 206a of the player terminal 1 sets the processing target items for which the processing of steps P12-2 to P12-9 described below has not been executed from the training items "Speed," "Stamina," "Power," "Spirit," and "Wisdom" (P12-1).

The game execution control unit 206a of the player terminal 1 determines and stores the failure rate when training is performed for the processing item set in step P12-1 above, based on the main character's current physical strength (P12-2).

The game execution control unit 206a of the player terminal 1 determines and stores the stamina reduction value when training is performed for the processing target items set in step P12-1 above (P12-3).

The game execution control unit 206a of the player terminal 1 checks the current team rankings (P12-4).

The game execution control unit 206a of the player terminal 1 determines the training level by referencing the training level table (Figure 22A) based on the team ranking confirmed in step P12-4 above (P12-5).

The game execution control unit 206a of the player terminal 1 references the fixed increase value table (Figures 22B and 22C) corresponding to the processing target item set in step P12-1 above, and determines and sets the fixed increase value based on the training level determined in step P12-5 above (P12-6).

The game execution control unit 206a of the player terminal 1 checks the information (placement information) of the characters whose placement was determined in step P11 above for the training item to be processed (P12-7).

The game execution control unit 206a of the player terminal 1 calculates the bonus addition rate by referencing the bonus addition rate table (Figure 22D) based on the placement information confirmed in step P12-7 above (P12-8).

The game execution control unit 206a of the player terminal 1 updates the increase value for the training item being processed based on the bonus addition rate calculated in step P12-8 above (P12-9).

The game execution control unit 206a of the player terminal 1 determines whether the processing of steps P12-1 to P12-9 has been completed for all training items, "Speed," "Stamina," "Power," "Spirit," and "Wisdom" (P12-10). As a result, if processing of all training items has been completed, the numerical value determination process is terminated; if processing of all training items has not been completed, the process proceeds to step P12-1.

Figure 34 is a flowchart explaining the event determination process in the player terminal 1. The game execution control unit 206a of the player terminal 1 determines and executes an event for the main character (P13-1). Note that a main character event is a dedicated event set for the main character from among the dedicated events set in advance in the dedicated event table (Figure 5D).

The game execution control unit 206a of the player terminal 1 references the support event table (Figure 7D) to determine and execute the support event set for the support card (support character) (P13-2).

The game execution control unit 206a of the player terminal 1 sets the training items "Speed," "Stamina," "Power," "Spirit," and "Wisdom" as items to be processed that have not yet undergone the processing of steps P13-4 to P13-13 (described below) (P13-3).

The game execution control unit 206a of the player terminal 1 checks the placement information of the character whose placement was determined in step P11 above for the training of the processing item set in step P13-3 above (P13-4).

The game execution control unit 206a of the player terminal 1 determines whether team members have been assigned to the training of the processing item set in step P13-3 above, based on the assignment information confirmed in step P13-4 above (P13-5). If team members have been assigned, the process proceeds to step P13-6; if team members have not been assigned, the process proceeds to step P13-15.

The game execution control unit 206a of the player terminal 1 sets as processing targets those team members who have not performed the processing of steps P13-7 to P13-13 (described below) among the team members assigned to the training of the processing target item set in step P13-3 above (P13-6).

The game execution control unit 206a of the player terminal 1 compares the ability parameters related to the processing target item set in step P13-3 with the main character for the team member to be processed set in step P13-6 (P13-7).

In step P13-7, the game execution control unit 206a of the player terminal 1 determines whether the ability parameters of the main character are equal to or greater than the ability parameters of the team member being compared (P13-8). As a result, if the ability parameters of the main character are equal to or greater than the ability parameters of the team member being processed, processing proceeds to step P13-9; if the ability parameters of the main character are not equal to or greater than the ability parameters of the team member being processed, processing proceeds to step P13-12.

The game execution control unit 206a of the player terminal 1 executes a training event determination process to determine whether to execute a training event for the team member to be processed set in step P13-6 above (P13-9).

The game execution control unit 206a of the player terminal 1 stores the training event information related to the training event determined in step P13-9 above in the player information storage unit 300 (P13-10).

The game execution control unit 206a of the player terminal 1 determines the special event to be executed in the event of a great success, according to a predetermined determination method that has been set in advance (P13-11). Specifically, for example, the special event to be executed may be determined by referring to a special event table (not shown) in which special events for each character are set in advance. In a special event, for example, possessed or acquired skills related to running style aptitude (leading, leading, overtaking, chasing) may be available. Furthermore, a special event determined by referring to a dedicated event table (Figure 5D) for the main character may be executed as the special event. Furthermore, a special event determined by referring to a dedicated event table (Figure 5D) for the main character may be executed as the special event.

The game execution control unit 206a of the player terminal 1 executes a hint event determination process (P13-12) for the team member to be processed set in step P13-6 above, in which the game execution control unit 206a references the possessed skill table (Figure 7C) and determines the hint event to be executed according to a predetermined determination method that has been set in advance. For example, if the team member to be processed is a support character, the game execution control unit 206a may reference the support event table (Figure 7D) and determine the hint event to be executed from the support events set on the support card (support character). Furthermore, if the team member to be processed is not a support character, the game execution control unit 206a may reference the dedicated event table (Figure 5D) for the team member to be processed and determine the hint event to be executed from the dedicated events set for the team member to be processed.

The game execution control unit 206a of the player terminal 1 stores the hint event information related to the hint event determined in step P13-12 above in the player information storage unit 300 (P13-13).

The game execution control unit 206a of the player terminal 1 determines whether the processing of steps P13-6 to P13-13 has been executed for all team members assigned to the training of the processing item set in step P13-3 (P13-14). As a result, if processing has been completed for all team members, processing proceeds to step P13-15; if processing has not been completed for all team members, processing proceeds to step P13-6.

The game execution control unit 206a of the player terminal 1 determines whether the processing of steps P13-4 to P13-13 has been completed for all of the training items "Speed," "Stamina," "Power," "Spirit," and "Wisdom" (P13-15). As a result, if processing of all training items has been completed, the event determination process is terminated; if processing of all training items has not been completed, the process proceeds to step P13-3.

Figure 35 is a flowchart explaining the turn-in-turn processing at the player terminal 1. The game execution control unit 206a of the player terminal 1 determines whether the result operation unit 113 or the race operation unit 114 on the individual race start screen 110 has been operated to start the individual race (P20-1). If the result shows that the individual race has started, processing proceeds to step P20-2; if the individual race has not started, processing proceeds to step P20-4.

The game execution control unit 206a of the player terminal 1 derives the results of the individual race and stores them in the player information storage unit 300 (P20-2). Specifically, for example, a calculation formula is set in advance that weights the ability parameters and acquired skills of each of the NPC and main character, and the ranking in the individual race is determined based on the calculation result. Note that the above calculation formula may be set to be different for each race. Also, for example, multiple patterns of NPC ability parameters may be set for each race, and which ability parameters will be used may be determined by lottery. In other words, even if the ability parameters and acquired skills of the main character are exactly the same as the race in which they participate, the race results may not necessarily be the same. Also, there may be multiple patterns of calculation formulas, such as weighting, for each race, and the results may differ depending on the selected calculation formula.

The game execution control unit 206a of the player terminal 1 executes a race result display process to display the individual race result screen 120 or the race video on the display 26 based on the results of the individual race derived in step P20-2 above (P20-3).

The game execution control unit 206a of the player terminal 1 determines whether the result operation unit 151 or the race operation unit 152 on the team race start screen 150 has been operated to start the team race (P20-4). If the team race has started, processing proceeds to step P20-5; if the team race has not started, processing proceeds to step P20-8.

The game execution control unit 206a of the player terminal 1 derives the results of the team race and stores them in the player information storage unit 300 (P20-5). Specifically, for example, a calculation formula is set in advance that weights the ability parameters and acquired skills of the NPC, main character, and other team members, and the ranking in the team race is determined based on the results of this calculation. Note that the above calculation formula may be set to be different for each race. Also, for example, multiple patterns of NPC ability parameters may be set for each race, and the ability parameters to be used 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 in which they participate, the race results may not necessarily be the same. Also, there may be multiple patterns of calculation formulas, such as weighting, for each race, and the results may vary depending on the selected calculation formula.

The game execution control unit 206a of the player terminal 1 executes a race result display process (P20-6) to display the team race interim results screen 160, the team race detailed results screen 170, and the team race overall results screen 180 on the display 26 based on the team race results derived in step P20-5 above.

The game execution control unit 206a of the player terminal 1 executes a parameter update process (P20-7) to update information related to the team rankings based on the results of the team race derived in step P20-5 above.

The game execution control unit 206a of the player terminal 1 determines whether any of the speed operation unit 81, stamina operation unit 82, power operation unit 83, spirit operation unit 84, or wisdom operation unit 85 on the training screen 80 has been operated, and whether any of the training items "Speed," "Stamina," "Power," "Spirit," or "Wisdom" has been selected (P20-8). If any of the training items has been selected, processing proceeds to step P21; if none of the training items has been selected, processing proceeds to step P20-9.

The game execution control unit 206a of the player terminal 1 executes the training execution process (P21), which will be described in detail below, and ends the processing during that turn.

The game execution control unit 206a of the player terminal 1 performs other processing, such as consuming skill points to acquire skills, and ends the processing during that turn (P20-9).

Figure 36 is a flowchart explaining the training execution process in the player terminal 1. The game execution control unit 206a of the player terminal 1 updates the main character's stamina for the training item selected in step P20-8 above based on the stamina reduction value determined in step P12-3 above (P21-1).

The game execution control unit 206a of the player terminal 1 executes a success determination process (P21-2) for the training item selected in step P20-8 above, determining whether the training was successful based on the failure rate determined in step P12-2 above.

The game execution control unit 206a of the player terminal 1 determines whether the training was successful based on the result of step P21-2 (P21-3). If the training was successful, processing proceeds to step P21-5; if the training was unsuccessful, processing proceeds to step P21-4.

The game execution control unit 206a of the player terminal 1 subtracts ability parameters such as a decline in condition based on the training failure (P21-4).

The game execution control unit 206a of the player terminal 1 executes the character identification information update process (P23) in the event of failure, which will be described in detail below, and ends the training execution process.

The game execution control unit 206a of the player terminal 1 adds the increase value derived in step P12-9 above to the main character's ability parameters (P21-5).

The game execution control unit 206a of the player terminal 1 checks the hint event information stored in step P13-13 above (P21-6).

The game execution control unit 206a of the player terminal 1 determines whether hint event information is stored for the selected training item. If hint event information is stored, processing proceeds to step P21-8; if hint event information is not stored, processing proceeds to step P21-10.

The game execution control unit 206a of the player terminal 1 executes a hint event generation process to execute a hint event based on the hint event information related to the selected training item (P21-8). Note that if multiple hint event information items are stored for the selected training item, one of the hint events will be selected, and the selected hint event will occur.

The game execution control unit 206a of the player terminal 1 updates the skill information related to the main character stored in the player information storage unit 300 based on the hint event information generated in step P21-8 (P21-9).

The game execution control unit 206a of the player terminal 1 determines whether training event information is stored for the selected training item (P21-10). If training event information is stored, processing proceeds to step P21-11; if training event information is not stored, processing proceeds to step P22.

The game execution control unit 206a of the player terminal 1 sets the team members with whom the training event will be performed based on the training event information related to the training item selected in step P20-8 above (P21-11).

The game execution control unit 206a of the player terminal 1 adds "1" to the number of training events for the target team member set in step P21-11 above (P21-12).

The game execution control unit 206a of the player terminal 1 sets the success pattern lottery table (Figure 25A) (P21-13).

The game execution control unit 206a of the player terminal 1 determines whether the result is "Success" or "Great Success" by referencing the success pattern lottery table set in step P21-13 above, based on the number of training events for the target team member updated in step P21-12 above (P21-14).

The game execution control unit 206a of the player terminal 1 updates the ability parameters of the target team members based on the success pattern determined in step P21-14 above (P21-15).

The game execution control unit 206a of the player terminal 1 determines whether the processing of steps P21-11 to P21-15 has been performed for all team members who are the targets of the training event, based on the training event information related to the selected training item (P21-16). As a result, if processing has been completed for all team members, processing proceeds to step P21-17; if processing has not been completed for all team members, processing proceeds to step P21-11.

The game execution control unit 206a of the player terminal 1 adds a bonus addition value to the main character's ability parameters based on the selected training item and training event information (P21-17).

The game execution control unit 206a of the player terminal 1 executes the character identification information update process (P22) upon success, which will be described in detail below, and ends the training execution process.

Figure 37 is a flowchart explaining the character identification information update process at the player terminal 1 when the training is successful. The game execution control unit 206a of the player terminal 1 extracts the sub-members placed in the selected training item (P22-1).

The game execution control unit 206a of the player terminal 1 determines whether a sub-member has been extracted (or is present) in step P22-1 (P22-2). If a sub-member has been placed, processing proceeds to step P22-3; if no sub-member has been placed, processing proceeds to step P22-10.

The game execution control unit 206a of the player terminal 1 sets the sub-member to be processed from the sub-members extracted in step P22-1 above (P22-3).

The game execution control unit 206a of the player terminal 1 references the registered parameter table (Figure 18) and determines the increase value of the registered parameter (P22-4).

The game execution control unit 206a of the player terminal 1 updates the registered parameters of the sub-member being processed based on the increase value determined in step P22-4 above (P22-5).

The game execution control unit 206a of the player terminal 1 determines whether the value of the registered parameter of the sub-member being processed, which was updated in step P22-5 above, is equal to or greater than a preset threshold value (100) (P22-6). If the value is equal to or greater than the threshold value, processing proceeds to step P22-8; if the value is less than the threshold value, processing proceeds to step P22-7.

The game execution control unit 206a of the player terminal 1 sets the demotion counter for the sub-member being processed to 20 (P22-7).

The game execution control unit 206a of the player terminal 1 updates the character identification information (Figures 8 and 9) to change the sub-member being processed to a team member (P22-8).

The game execution control unit 206a of the player terminal 1 determines whether the processing of steps P22-3 to P22-8 has been performed for all sub-members extracted in step P22-1 (P22-9). If the processing of all sub-members has been completed, the process proceeds to step P22-10. If the processing of all sub-members has not been completed, the process proceeds to step P22-3.

The game execution control unit 206a of the player terminal 1 references the character identification information (Figures 8 and 9) and extracts sub-members other than those extracted in step P22-1 above (non-placed sub-members) (P22-10).

The game execution control unit 206a of the player terminal 1 determines whether or not a non-placed sub-member has been extracted (P22-11) in step P22-10. If a non-placed sub-member is found, processing proceeds to step P22-12; if no non-placed sub-member is found, processing proceeds to step P22-17.

The game execution control unit 206a of the player terminal 1 sets the sub-member to be processed from the non-placed sub-members extracted in step P22-10 above (P22-12).

The game execution control unit 206a of the player terminal 1 decrements the demotion counter of the sub-member being processed by 1 (P22-13).

The game execution control unit 206a of the player terminal 1 determines whether the value of the demotion counter updated in step P22-13 is "0" (P22-14). As a result, if the value of the demotion counter is "0", processing proceeds to step P22-15, and if the value of the demotion counter is not "0", processing proceeds to step P22-16.

The game execution control unit 206a of the player terminal 1 updates the character identification information (Figures 8 and 9) to change the sub-member to be processed to a random member (P22-15).

The game execution control unit 206a of the player terminal 1 determines whether the processing of steps P22-12 to P22-15 has been performed for all non-placed sub-members extracted in step P22-10 (P22-16). As a result, if processing of all sub-members has been completed, processing proceeds to step P22-17; if processing of all sub-members has not been completed, processing proceeds to step P22-12.

The game execution control unit 206a of the player terminal 1 extracts a random member placed in the training item selected in step P20-8 above (P22-17).

The game execution control unit 206a of the player terminal 1 determines whether the random member placed in step P22-17 has been extracted (P22-18). If a random member has been placed, the process proceeds to step P22-19; if a random member has not been placed, the successful character identification information update process ends.

The game execution control unit 206a of the player terminal 1 sets the random member to be processed from the random members extracted in step P22-17 above (P22-19).

The game execution control unit 206a of the player terminal 1 updates the character identification information (Figures 8 and 9) to change the random member being processed to a sub-member (P22-20).

The game execution control unit 206a of the player terminal 1 sets the demotion counter for the random member being processed to 20 (P22-21).

The game execution control unit 206a of the player terminal 1 determines whether the processing of steps P22-19 to P22-21 has been executed for all random members extracted in step P22-17 (P22-22). As a result, if processing of all random members has been completed, the successful character identification information update processing ends; if processing of all random members has not been completed, processing proceeds to step P22-19.

Figure 37 is a flowchart explaining the character identification information update process in the event of a failure at a player terminal 1. The game execution control unit 206a of the player terminal 1 references the character identification information (Figures 8 and 9) and extracts sub-members (P23-1).

The game execution control unit 206a of the player terminal 1 determines whether a sub-member has been extracted (or is present) in step P23-1 (P23-2). If a sub-member is present, the process proceeds to step P23-3; if a sub-member is not present, the character identification information update process for the failed game is terminated.

The game execution control unit 206a of the player terminal 1 sets the sub-member to be processed from the sub-members extracted in step P23-1 above (P23-3).

The game execution control unit 206a of the player terminal 1 decrements the demotion counter of the sub-member being processed by 1 (P23-4).

The game execution control unit 206a of the player terminal 1 determines whether the value of the demotion counter updated in step P23-3 above is "0" (P23-5). As a result, if the value of the demotion counter is "0", processing proceeds to step P23-6, and if the value of the demotion counter is not "0", processing proceeds to step P23-7.

The game execution control unit 206a of the player terminal 1 updates the character identification information (Figures 8 and 9) to change the sub-member to be processed to a random member (P23-6).

The game execution control unit 206a of the player terminal 1 determines whether the processing of steps P23-3 to P23-6 has been executed for all sub-members extracted in step P23-1 (P23-7). As a result, if processing has been completed for all sub-members, the character identification information update processing in the event of failure is terminated; if processing has not been completed for all sub-members, processing proceeds to step P23-3.

Returning to FIG. 28, when the development stage processing (P6) ends, the game execution control unit 206a of the player terminal 1, which transmits end information to the server 1000, executes development game end processing (P7). The end information includes various parameters related to the final main character in the development game.

When the transmission/reception unit 200a of the server 1000 receives the termination information, 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 termination information (S4).

In the above embodiment, the division of processing between the player terminal 1 and the server 1000 is merely an example. For example, each of the above processes may be executed by at least one of the player terminal 1 and the server 1000, with no particular limitations on the timing of execution or the device by which it is executed. For example, in the above embodiment, the case was shown in which all of the processing related to the preparation stage processing (P5) and the development stage processing (P6) was executed on the player terminal 1 side, but when various lotteries are executed in the development game, the lotteries may be executed on the server 1000 side, and the player terminal 1 may obtain the lottery results to progress the development game.

In addition, in the above embodiment, the training game is described as consisting of 1 to 60 turns, but the number of turns is not limited. In other words, it is sufficient that the game consists of at least two turns.

Furthermore, while the above embodiment illustrates a case where performance parameters related to multiple training items increase when one training item is performed, the present invention is not limited to this. For example, performance parameters related to one training item may increase when one training item is performed. Alternatively, the present invention may include both a case where performance parameters related to multiple training items increase when one training item is performed, and a case where performance parameters related to one training item increase when one training item is performed.

Furthermore, in the above embodiment, the player is required to select a support card (support character) when playing the training game, but the training game may also be playable without the need for a support card (support character).

Furthermore, while the above embodiment illustrates a case in which a specific character is provided in the training game, the present invention is not limited to this. In other words, a specific character does not necessarily have to be provided.

<Modification>
The modified examples will be described in detail below. The game features in the modified examples may be combined with the game features in the above embodiment. In the following, the description of the same configuration as the above embodiment will be omitted, and the configuration that differs from the above embodiment will be described in detail.

<Preparation Stage Processing According to Modification>
In the preparation stage processing according to the modified example, mainly, the registration of the main character, the registration of the support card (support character), the registration of the specific character, and the setting of the initial character identification information are performed. Note that the registration of the main character, the registration of the support card (support character), and the registration of the specific character in the preparation stage processing according to the modified example are performed in the same manner as in the above embodiment.

<Setting of initial character identification information according to modified examples>
Once the main character, support card (support character), and specific character are registered, team members and sub-members are registered. Figure 39 is a diagram illustrating a character identification information table according to a modified example. As shown in Figure 39, in the modified example, once the main character, support card (support character), and specific character are registered, team members and sub-members are registered.

In the above embodiment, the character identification information includes main character, support character, specific character, team member, sub-member, and random member. In contrast, in the modified example, as shown in FIG. 39, the character identification information includes main character, support character, specific character, team member, and sub-member. In other words, the modified example differs significantly from the above embodiment in that random member is not included as character identification information.

For this reason, while the above embodiment shows a case in which a random member is promoted to a sub-member and the sub-member is promoted to a team member as the training game progresses, the modified example only provides for a case in which a sub-member is promoted to a team member. Furthermore, as will be described in more detail below, in the modified example, when a character registered as a sub-member meets certain conditions, the character registered as a sub-member is registered (promoted) as a team member.

In a modified example, at the start of the training game, characters registered as main characters, support characters, or specific characters in the character identification information table are registered as team members.

In addition, in the character identification information table, characters or support cards (support characters) owned by the player that are not registered as team members are registered as sub-members. In other words, all remaining characters that are not registered as team members among the predetermined characters are registered as sub-members. Note that, among the predetermined characters, some characters selected by lottery may also be registered as sub-members.

In addition, at the start of the training game, the character registered as the main character in the character identification information table may be registered as a team member, and characters other than the main character may be registered as sub-members.

Figure 39 shows a case where "Character C" is registered as the main character, and "Character E," "Character I," "Character L," "Character M," "Character Q," and "Character T" are registered as support cards (support characters). In other words, in the case of Figure 39, "Character C," "Character E," "Character I," "Character L," "Character M," "Character Q," and "Character T" will be registered as team members.

In this way, information related to team members and sub-members (initial character identification information) is stored in the character identification information table.

<Growth Stage Processing According to Modification>
When the preparation stage processing is completed, the development stage processing begins. In the development stage processing, it is possible to develop the main character and characters registered as team members. As in the above embodiment, the development game is made up of 1st turn to 60th turn, and has a gameplay in which various parameters are updated according to the selection results of the player in each turn.

Figure 40 is a diagram illustrating the general flow of the turn start processing in a modified example. The development stage processing includes turn start processing, which is executed at the start of each turn in the development game. Details of the turn start processing will be described in more detail in Figures 46, 47, 48, and 49, which will be described later. Here, we will explain the general flow of the turn start processing.

In the turn start processing of this modified example, roughly as shown in Figure 40, the following processes are executed: "Process for determining whether or not to assign team members," "Process for determining training items to assign," "Process for determining the increase value of ability parameters," "Process for determining events that will appear," and "Process for determining guest characters."

Furthermore, the training game according to the modified example differs significantly from the above embodiment in that the characters to be placed in each training session (joint training) can only be determined from the characters registered as team members excluding the main character. Therefore, the turn start processing according to the modified example does not execute the "process to determine the number of random members to be placed," "process to determine the aptitude type of the random members to be placed," "process to determine the random members to be placed," and "process to determine whether or not to place sub-members" that are part of the turn start processing (Figure 19) according to the above embodiment.

However, it may also be possible to assign characters registered as sub-members to each training session (joint training session). In this case, the "process for determining random members to be assigned" and the "process for determining whether or not to assign sub-members" can be performed in the same manner as in the above embodiment.

On the other hand, the "processing to determine whether or not to assign team members," "processing to determine training items to assign," and "processing to determine the increase value of ability parameters" in the turn start processing in this modified example are performed in the same manner as in the above embodiment.

<Process for Determining Appearing Events According to Modification>
The major difference in the modified example is that a training event, which will be described in detail later, can be executed instead of the instruction event in the above embodiment. Therefore, in the modified example, the "processing for determining an event to appear" in the turn start processing is significantly different from the above embodiment.

Figure 41A is a diagram illustrating a game screen 70 according to a modified example. Figure 41A shows a case where a training event, described below, occurs in the turn in question. In this case, an event notification display 87 is displayed in the training operation section 76 of the game screen 70, as shown in Figure 41A.

Figure 41B is a diagram illustrating a training screen 80 according to a modified example. When the training operation unit 76 on the game screen 70 is operated, the training screen 80 is displayed on the display 26. When a training event (described below) occurs in response to a character displayed in an icon 88 on the training screen 80, an event notification display 87 is displayed on the icon 88 of the corresponding character.

Also, as shown in Figure 41B, a bond gauge 88a and a special icon 88b are displayed for each character icon 88 placed in training (joint training).

The bond gauge 88a indicates a parameter (hereafter referred to as the bond parameter) that increases depending on the number of training sessions (joint training) performed with the corresponding team member's character. This bond parameter is initially set to 0 and can increase up to a maximum of 100. The bond gauge 88a visually indicates the value of the bond parameter.

In addition, the special icon 88b indicates the number of times a training event has been performed for the corresponding team member's character. As will be described in more detail below, the special icon 88b is displayed in a manner that corresponds to the number of training events that have been performed for the character of the icon 88 on which the special icon 88b is displayed.

Figure 42A is a diagram illustrating a training event execution/non-execution decision table according to a modified example. In this modified example, when it is determined that a team member will be assigned to each training item, whether or not a training event will be executed is determined by lottery for each team member assigned to each training item based on the training event execution/non-execution decision table shown in Figure 42A. Hereinafter, team members for whom it has been determined that a training event will be executed are also referred to as team members to be trained.

Specifically, as shown in Figure 42A, the probability of selecting whether or not to execute a special training event is set based on the bond parameter value of the team member being trained. Here, the selection probability is set so that the larger the bond parameter value, the more likely it is that a special training event will be selected. Note that in a modified example, the number of special training events that can occur is the same as the number of team members who win the lottery. However, it is also possible to set a limit on the number of team members being trained that can occur simultaneously for one training item.

Figure 42B is a diagram illustrating a special icon determination table according to a modified example. In this modified example, the special training event includes a "success" execution pattern and a "great success" execution pattern. In this modified example, when a training event is executed for the fifth time for each training target team member, the special training event is always executed using the "great success" execution pattern. On the other hand, when a training event other than the fifth time is executed for each training target team member, the special training event is always executed using the "success" execution pattern. In other words, a training event can be executed only once using the "great success" execution pattern for one training target team member. Note that the event notification display 87 may be displayed in different ways depending on the content of the training event to be executed (the "success" execution pattern or the "great success" execution pattern) and the number of team members for whom the special training event has been decided to be executed.

As shown in FIG. 42B, if the number of times the training event for each training target team member character has been executed is 0 to 4 times, i.e., if the training event has not yet been executed in the "great success" execution pattern, the special icon 88b will be displayed in a larger size the more times the training event has been executed.

Whether the training event will have a "great success" or "success" execution pattern may be determined by lottery. In this case, the lottery probability may be set so that the more times the training event is performed for the team member being trained, the more likely the "great success" execution pattern will be selected. In this case, the larger the special icon 88b, the more likely the "great success" execution pattern will be selected, so the special icon 88b indicates the likelihood of the "great success" execution pattern being selected.

Furthermore, after a training event has been executed with the "great success" execution pattern, that is, if the training event for the team member being trained has been executed five or more times, a special icon 88b is displayed in a larger size than when the training event for the team member being trained has been executed zero to four times, and a suggestion display a is displayed, as shown in FIG. 42B, indicating that the training event has been executed with the "great success" execution pattern.

In addition, when a training event occurs and the execution pattern of the training event is "successful," the ability parameters of the team member being trained and the ability parameters of the main character will increase within a predetermined range. In addition, when the execution pattern of the training event is "great success," the ability parameters of the team member being trained and the ability parameters of the main character will increase by a greater amount than the above-mentioned predetermined range.

Also, as shown in FIG. 41B, when it is decided to carry out a training event, a bonus icon 88c indicating the value by which the main character's ability parameters will increase as a result of the training event is displayed in the status display section 73 of the training screen 80.

Figure 42C is a diagram illustrating a bonus icon determination table according to a modified example. The bonus icon 88c is displayed in different sizes depending on the value by which the main character's ability parameter increases as a result of the training event. Here, the bonus icon 88c is displayed in a larger size when the value by which the main character's ability parameter increases as a result of the training event is between 20 and 39 than when it is between 0 and 19. Also, the bonus icon 88c is displayed in a larger size when the value by which the main character's ability parameter increases as a result of the training event is 40 or above than when it is between 20 and 39.

Figure 43A is a diagram illustrating a fixed bonus value (main character) table related to a modified example. When the above-mentioned training event is executed, the value by which the main character's ability parameter will increase as a result of the training event (fixed bonus value) is determined according to the number of team members for whom the training event has been decided. Here, as shown in Figure 43A, the setting is such that the greater the number of team members for whom the training event has been decided, the greater the value by which the main character's ability parameter will increase as a result of the training event (fixed bonus value).

Figure 43B is a diagram illustrating a bonus addition value (main character) table related to a modified example. When a training event is executed with the "great success" execution pattern, in addition to the fixed bonus value described above, the value by which the main character's ability parameter will increase due to the training event with the "great success" execution pattern (bonus addition value) is determined. Here, as shown in Figure 43B, the value by which the main character's ability parameter will increase (bonus addition value) is set according to the training specialty of the team member for whom the training event is executed with the "great success" execution pattern. In other words, the value by which the main character's ability parameter will increase due to the training event is the sum of the fixed bonus value and the bonus addition value described above.

Figure 44A is a diagram illustrating a fixed increase value (training target) table related to a modified example. When the above-mentioned training event is carried out, the value (fixed increase value) by which the ability parameters of the training target team member will increase due to the training event is determined. Here, as shown in Figure 44A, a range of values (fixed increase value) by which the ability parameters of the training target team member will increase is set depending on the type of training carried out. Here, a value (fixed increase value) within the range set in Figure 44A is determined by lottery.

Figure 44B is a diagram illustrating a bonus increase value (training target) table related to a modified example. When a training event is executed with the "great success" execution pattern, in addition to the fixed increase value described above, the value by which the ability parameters of the training target team member are increased by the training event (bonus increase value) is determined. Here, as shown in Figure 44B, the value by which the ability parameters of the training target team member are increased (bonus increase value) is set according to the special training of the training target team member for whom the training event is executed with the "great success" execution pattern.

When a training event is executed in a "great success" execution pattern, an additional increase event may be executed that increases the ability parameters of the team member being trained and the ability parameters of the main character, depending on the number (number of times) of training events in the "great success" execution pattern that are executed simultaneously. For example, the greater the number (number of times) of training events in the "great success" execution pattern that are executed simultaneously, the greater the increase in the ability parameters of the team member being trained and the ability parameters of the main character.

<Process for Determining Guest Characters According to Modification>
40, the modified example differs significantly from the above embodiment in that a "guest character determination process" that is not performed in the above embodiment is performed. In the modified example, a character registered as a sub-member may be set as a guest character in an individual race or a team race based on a predetermined process (guest character determination process (P100)).

The game has a feature where if the race result in an individual or team race in which a guest character is assigned reaches a predetermined rank or higher, the sub-member of the guest character assigned to that individual or team race is promoted to a team member. For example, the predetermined rank could be third place. However, the predetermined rank may also be set in advance for each individual or team race, or the predetermined rank may also be determined by lottery.

In this process, a first lottery is held to determine whether or not a guest character will be set. If the first lottery is not won, a guest character will not be set for that turn.

On the other hand, if a player wins the first lottery or has not won the first lottery in the last two consecutive turns (the previous turn and the turn before that), a guest character will be set. However, even if a player wins the first lottery or has not won the first lottery in the last two consecutive turns, a guest character will not be set if the total number of characters registered as team members is 21 or more.

Next, as in the above embodiment, the aptitude number table (Figure 20B) is referenced to extract and determine the aptitude type with the lowest A aptitude number. Note that if there are multiple aptitude types with the lowest A aptitude numbers, the aptitude type is extracted and determined based on a pre-set priority order. Here, the priority order is set as "Short distance" > "Mile" > "Middle distance" > "Long distance" > "Dirt."

Then, from the characters registered as sub-members, sub-members with the extracted aptitude type "A" are extracted, and a first lottery table is generated based on the extracted sub-members. Note that if characters registered as sub-members can be placed in each training (joint training), sub-members with the extracted aptitude type "A" are extracted from the characters registered as sub-members, and the first lottery table is generated by excluding sub-members placed in each training from the extracted sub-members.

Next, a second lottery table is generated from the characters registered as sub-members, excluding the sub-members included in the first lottery table. If characters registered as sub-members can be placed in each training (joint training), a second lottery table is generated from the characters registered as sub-members, excluding the sub-members included in the first lottery table and the determined sub-members placed in each training.

Then, a lottery is performed to determine whether the first lottery table or the second lottery table generated as described above will be used, and the guest character is determined using the determined lottery table (first lottery table or second lottery table). When determining whether the first lottery table or the second lottery table will be used, a lottery table with a set selection ratio for the lottery may be prepared in advance. For example, a lottery table may be prepared in advance in which the first lottery table is more likely to be selected than the second lottery table, or a lottery table may be prepared in advance in which the second lottery table is more likely to be selected than the first lottery table. Alternatively, a lottery table may be created each time a lottery is performed to determine whether the first lottery table or the second lottery table will be used.

The individual race or team race in which the guest character determined as described above will be placed is then determined and registered by lottery. In this modified example, a case in which the guest character is set to individual races and team races will be described, but the guest character may also be set to only team races, or the guest character may also be set to only individual races.

Figure 45A is a diagram illustrating a game screen 70 according to a modified example. When the development stage processing begins, the game screen 70 shown in Figure 45A is displayed on the display 26. When a guest character is selected for an individual race as described above, a guest icon 70a and a guest notification display 70b indicating the guest character are displayed on the game screen 70, superimposed on the individual race operation section 79a of the game screen 70. Note that when a guest character is selected for a team race, a guest icon 70a and a guest notification display 70b indicating the guest character are displayed on the game screen 70, superimposed on the team race operation section 79b of the game screen 70.

Figure 45B is a diagram illustrating an individual race selection screen 100 according to a modified example. When the individual race operation unit 79a on the game screen 70 is operated, the individual race selection screen 100 shown in Figure 45B is displayed.

On the individual race selection screen 100, a guest icon 70a and a guest notification display 70b are displayed superimposed on the individual race selection operation section 101 corresponding to the individual race for which the guest character has been set.

In the modified example, as shown in Figure 45B, a guest character is set in one individual race selection operation unit 101, but a guest character may also be set in each of multiple individual races in one turn. Also, a guest character may be set in all individual races that the player can select. When guest characters are set in multiple individual races, a different guest character may be set for each individual race, or the same guest character may be set in multiple individual races.

Also, a guest character may be set for each of multiple team races in one turn. Alternatively, a guest character may be set for all team races that the player can select. Note that when a guest character is set for multiple team races, a different guest character may be set for each team race, or the same guest character may be set for multiple team races.

Next, we will explain the processing related to a modified example for executing the above game. Note that, below, we will omit explanations of processing that is the same as in the above embodiment, and will instead provide detailed explanations of processing that differs from the above embodiment.

Figure 46 is a flowchart illustrating the turn start processing at a player terminal according to a modified example. In this modified example, the turn start processing shown in Figure 46 is executed instead of the turn start processing shown in Figure 31 in the above embodiment. As shown in Figure 46, this modified example differs from the above embodiment in that after step P10-2 in the turn start processing shown in Figure 31 in the above embodiment, a guest character determination process (P100), which will be described in detail later, is executed.

Figure 47 is a flowchart illustrating the placement processing at a player terminal 1 according to a modified example. In this modified example, the placement processing shown in Figure 47 is executed instead of the placement processing shown in Figure 32 in the above embodiment. As shown in Figure 47, the modified example differs from the above embodiment in that steps P11-1 to P11-11 in the placement processing shown in Figure 32 are not executed. Also, as shown in Figure 47, the modified example differs from the above embodiment in that a guest character determination process (P100), which will be described in detail later, is executed.

The game execution control unit 206a of the player terminal 1 references the character identification information table and extracts all characters registered as team members (P11-a).

The game execution control unit 206a of the player terminal 1 selects, from among the team members extracted in step P11-a above, a character that has not yet performed the processes P11-12 to P11-16 (described below) as the target character to perform the process (P11-b).

The game execution control unit 206a of the player terminal 1 references the character identification information table and confirms the character identification information of the target character selected in step P11-b above (P11-12).

The game execution control unit 206a of the player terminal 1 sets the placement presence/absence table (Figure 21) based on the character identification information confirmed in step P11-12 above (P11-13).

The game execution control unit 206a of the player terminal 1 determines whether or not to place the item ("place" or "do not place") based on the placement table set in step P11-13 (P11-14).

The game execution control unit 206a of the player terminal 1 determines whether "place" was selected in step P11-14 (P11-15). If "place" was selected, the process proceeds to step P11-16; if "place" was not selected, the process proceeds to step P11-17.

The game execution control unit 206a of the player terminal 1 determines and stores the training item in which to place the target character for which "placement" was determined in step P11-14 above (P11-16).

The game execution control unit 206a of the player terminal 1 determines whether the processing of P11-11 to P11-16 has been completed for all team members extracted in step P11-a above (P11-17). If the processing of all members has been completed, the game execution control unit 206a executes the guest character determination process (P100), which will be described in detail below.

Figure 48 is a flowchart explaining the guest character determination process (P100) at a player terminal 1 according to a modified example.

The game execution control unit 206a of the player terminal 1 determines whether the counter value of the non-win counter, which indicates the number of consecutive turns in which a guest character has not been determined, is 2 or greater (P100-1). As a result, if the counter value of the non-win counter is not 2 or greater, processing proceeds to step P100-3; if the counter value of the non-win counter is 2 or greater, processing proceeds to step P100-5.

The game execution control unit 206a of the player terminal 1 executes a first lottery to determine whether or not to set a guest character (P100-2).

The game execution control unit 206a of the player terminal 1 determines whether or not the first lottery drawing in step P100-2 was won (P100-3). If the result shows that the first lottery drawing was not won, processing proceeds to step P100-4; if the first lottery drawing was won, processing proceeds to step P100-5.

The game execution control unit 206a of the player terminal 1 increments the counter value of the non-winning counter and ends the guest character determination process (P100-4).

The game execution control unit 206a of the player terminal 1 clears the counter value of the non-winning counter (P100-5).

The game execution control unit 206a of the player terminal 1 references the character identification information table and derives the total number of characters registered as team members (hereinafter also referred to as the number of team members) (P100-6).

The game execution control unit 206a of the player terminal 1 determines whether the number of team members derived in step P100-6 above is less than 20 (P100-7). If the number of team members is less than 20, processing proceeds to step P100-8; if the number of team members is not less than 20, the guest character determination process ends.

The game execution control unit 206a of the player terminal 1 derives the above-mentioned A aptitude number for the characters registered as team members (P100-8).

The game execution control unit 206a of the player terminal 1 extracts and determines the aptitude type with the lowest number of A aptitudes based on the number of A aptitudes derived in step P100-8 above (P100-9).

The game execution control unit 206a of the player terminal 1 extracts sub-members whose aptitude class determined in step P100-9 above is "A" from among the characters registered as sub-members (P100-10).

The game execution control unit 206a of the player terminal 1 generates a first lottery table based on the sub-members extracted in step P100-10 above (P100-11).

The game execution control unit 206a of the player terminal 1 excludes the sub-members included in the first lottery table generated in step P100-11 from the characters registered as sub-members (P100-12), and generates a second lottery table (P100-13).

The game execution control unit 206a of the player terminal 1 determines by lottery whether to use the first lottery table generated in step P100-11 or the second lottery table generated in step P100-13 (P100-14).

The game execution control unit 206a of the player terminal 1 determines and registers a guest character by lottery using the lottery table (first lottery table or second lottery table) determined in step P100-14 above (P100-15).

The game execution control unit 206a of the player terminal 1 determines and registers by lottery the individual race or team race in which the guest character determined and registered in step P100-15 will be placed (P100-16), and ends the guest character determination process.

Figure 49 is a flowchart illustrating the event determination process at a player terminal 1 according to a modified example. In this modified example, the event determination process shown in Figure 49 is executed instead of the event determination process shown in Figure 34 in the above embodiment.

The game execution control unit 206a of the player terminal 1 determines and executes an event for the main character (P130-1). Note that a main character event refers to a dedicated event set for the main character from among the dedicated events set in advance in the dedicated event table (Figure 5D).

The game execution control unit 206a of the player terminal 1 references the support event table (Figure 7D) and determines and executes the support event set for the support card (support character) (P130-2).

The game execution control unit 206a of the player terminal 1 sets the training items "Speed," "Stamina," "Power," "Spirit," and "Wisdom" as items to be processed that have not yet undergone the processing of steps P130-4 to P130-15 (described below) (P130-3).

The game execution control unit 206a of the player terminal 1 checks (P130-4) the placement information of the character whose placement was determined in step P11 (Figure 47) for the training processing item set in step P130-3.

The game execution control unit 206a of the player terminal 1 determines whether team members have been assigned to the training of the processing item set in step P130-3 above, based on the assignment information confirmed in step P130-4 above (P130-5). If team members have been assigned, processing proceeds to step P130-6; if team members have not been assigned, processing proceeds to step P130-18.

The game execution control unit 206a of the player terminal 1 sets as processing targets those team members who have not performed the processing of steps P130-7 to P130-15 (described below) among the team members assigned to the training of the processing target item set in step P130-3 above (P130-6).

The game execution control unit 206a of the player terminal 1 checks the bond parameter value for the team member being processed that was set in step P130-6 above (P130-7).

The game execution control unit 206a of the player terminal 1 determines by lottery whether or not to execute a training event, based on the bond parameter value confirmed in step P130-7 above, and refers to the training event execution/non-execution determination table shown in FIG. 42A (P130-8).

The game execution control unit 206a of the player terminal 1 determines whether or not it was decided in step P130-8 above that a training event be held (P130-9). As a result, if it is determined that a training event be held, processing proceeds to step P130-10; if it is determined that a training event be held, processing proceeds to step P130-12.

The game execution control unit 206a of the player terminal 1 executes a hint event determination process (P130-10) to determine the hint event to be executed for the team member to be processed set in step P130-6 above, by referencing the possessed skill table (Figure 7C) and following a predetermined determination method that has been set in advance.

The game execution control unit 206a of the player terminal 1 stores hint event information related to the hint event determined in step P130-10 in the player information storage unit 300 (P130-11).

The game execution control unit 206a of the player terminal 1 determines the value (fixed increase value) by which the ability parameter of the training target team member will increase (P130-12) by referencing the fixed increase value (training target) table shown in Figure 44A for the team member to be processed set in step P130-6 above.

The game execution control unit 206a of the player terminal 1 determines whether the training event has been executed four times for the team member to be processed set in step P130-6 above (P130-13). If the training event has been executed four times, processing proceeds to step P130-14; if the training event has not been executed four times, processing proceeds to step P130-16.

The game execution control unit 206a of the player terminal 1 determines the value (bonus increase value) by which the ability parameter of the training target team member will increase (P130-14) by referencing the bonus increase value (training target) table shown in FIG. 44B for the team member to be processed set in step P130-6 above.

The game execution control unit 206a of the player terminal 1 references the bonus addition value (main character) table shown in Figure 43B and determines the value (bonus addition value) by which the main character's ability parameters will increase (P130-15).

The game execution control unit 206a of the player terminal 1 determines whether the processing of steps P130-6 to P130-15 has been executed for all team members assigned to the training of the processing item set in step P130-3 (P130-16). As a result, if processing has been completed for all team members, processing proceeds to step P130-17; if processing has not been completed for all team members, processing proceeds to step P130-6.

The game execution control unit 206a of the player terminal 1 references the fixed bonus value (main character) table shown in Figure 43B and determines the value (fixed bonus value) by which the main character's ability parameter will increase (P130-17).

The game execution control unit 206a of the player terminal 1 determines whether the processing of steps P130-4 to P130-15 has been completed for all of the training items "Speed," "Stamina," "Power," "Spirit," and "Wisdom" (P130-18). As a result, if processing of all training items has been completed, the event determination process is terminated; if processing of all training items has not been completed, the process proceeds to step P130-3.

Figure 50 is a flowchart illustrating the mid-turn processing at a player terminal 1 according to a modified example. In this modified example, the mid-turn processing shown in Figure 50 is executed instead of the mid-turn processing shown in Figure 35 in the above embodiment. As shown in Figure 50, the modified example differs from the above embodiment in that a character identification information update process (P200), which will be described in detail later, is executed between steps P20-2 and P20-3 in the mid-turn processing shown in Figure 35 in the above embodiment. Also, as shown in Figure 50, the modified example differs from the above embodiment in that a character identification information update process (P200), which will be described in detail later, is executed between steps P20-6 and P20-7 in the mid-turn processing shown in Figure 35 in the above embodiment.

Figure 51 is a flowchart explaining the character identification information update process at a player terminal 1 according to a modified example.

The game execution control unit 206a of the player terminal 1 references the results of the individual race or team race derived in step P20-2 and stored in the player information storage unit 300, and determines whether the finishing order in the individual race or team race is equal to or higher than a predetermined rank. If the finishing order is equal to or higher than the predetermined rank, processing proceeds to step P200-2; if the finishing order is not equal to or higher than the predetermined rank, the character identification information update processing ends.

In step P100-16, the game execution control unit 206a of the player terminal 1 determines whether a guest character is registered in the individual race or team race. If a guest character is registered, processing proceeds to step P200-3; if a guest character is not registered, the character identification information update processing ends.

The game execution control unit 206a of the player terminal 1 updates the character identification information (Figure 39) to change the sub-member of the guest character registered in the individual race or team race to a team member, and the character identification information update process ends. At this time, the ability parameters of the sub-member promoted to a team member may be registered with preset initial values, or the ability parameters of the main character or adjusted values adjusted according to the team level may be registered.

Figure 52 is a flowchart illustrating the training execution processing in a player terminal 1 according to a modified example. In this modified example, the training execution processing shown in Figure 52 is executed instead of the training execution processing shown in Figure 36 in the above embodiment. As shown in Figure 51, in this modified example, steps P22 and P23 in the training execution processing shown in Figure 36 in the above embodiment are not executed.

Furthermore, the processing of steps P21-1 to P21-5 and steps P21-6 to P21-9 is executed in the same manner as the training execution processing shown in FIG. 36 in the above embodiment. After the processing of step P21-5 is completed, the game execution control unit 206a of the player terminal 1 adds an increase value to the bond parameter value (P21-a). Note that the increase value to be added may be a fixed value, or a value determined by lottery.

Furthermore, steps P21-b to P21-g, which will be described later, are added after step P21-9. The game execution control unit 206a of the player terminal 1 determines whether special training event information is stored for the selected training item (P21-b). As a result, if special training event information is stored, processing proceeds to step P21-c; if special training event information is not stored, the training execution processing ends.

The game execution control unit 206a of the player terminal 1 sets the team members to be the targets of the training event based on the training event information related to the training item selected in step P20-8 (P21-c).

The game execution control unit 206a of the player terminal 1 adds "1" to the number of training events for the target team member set in step P21-c above (P21-d).

The game execution control unit 206a of the player terminal 1 updates the ability parameters of the target team members based on the fixed increase value and bonus increase value determined in steps P130-12 and P130-14 above (P21-e).

The game execution control unit 206a of the player terminal 1 determines whether the processing of steps P21-c to P21-e has been performed for all team members who are the targets of the training event, based on the training event information related to the selected training item (P21-f). As a result, if processing has been completed for all team members, processing proceeds to step P21-g; if processing has not been completed for all team members, processing proceeds to step P21-c.

The game execution control unit 206a of the player terminal 1 adds the bonus addition value and fixed bonus value derived in steps P130-15 and P130-17 above to the main character's ability parameters based on the selected training item and training event information (P21-g), and then ends the training execution process.

In the above variant, a first lottery is performed to determine whether or not a guest character will be set for each turn, but a predetermined individual race (hereinafter also referred to as a target individual race) or a predetermined team race (hereinafter also referred to as a target team race) may also be the individual race or team race in which a guest character can be set. For example, a guest character may always be set in a target individual race or target team race, or a guest character may be set in a target individual race or target team race if the lottery is won. Note that target individual races and target team races may be set, for example, depending on the type of main character to be developed.

In addition, in the above variant, we have shown that if a guest character achieves a predetermined ranking or higher in a registered individual or team race, the guest character's sub-members are always changed to team members, but this is not limited to this. For example, in an individual or team race in which a guest character is registered, a lottery may be held based on the player's finishing position, and if the player wins the lottery, the guest character's sub-members may be changed to team members. In this case, the higher the player's finishing position, the higher the probability of winning the lottery.

In addition, while the above modified example shows a case where the guest character determination process (P100) is performed during the turn start process as shown in Figures 46 and 47, this is not limited to this, and the guest character determination process (P100) may also be performed during the turn process as shown in Figure 50. Specifically, the guest character determination process (P100) may be performed between step P20-2 and step P200, and between step P20-5 and step P20-6 in the turn process shown in Figure 50. In this case, since the guest character determination process (P100) is performed after the results of the individual race or team race are determined, the guest icon 70a and guest notification display 70b shown in Figures 45A and 45B are not displayed. In other words, before the start of the individual race or team race, the player is not notified as to whether a guest character is registered in that individual race or team race.

Although one 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 clear that a person skilled in the art could conceive of various modifications or alterations within the scope of the claims, and it is understood that these naturally fall within the technical scope.

The information processing program for executing the processes in the above embodiments and variations may be stored on a computer-readable storage medium and provided as such. Furthermore, a game terminal device including this storage medium may be provided. Furthermore, the above embodiments and variations may also be information processing methods that implement the functions and steps shown in the flowcharts.

1. Player terminal (game terminal)
1000 Server S Information Processing System

Claims (5)

a process of setting a game medium selected by a player from a plurality of game media including game media set as specific game media in a development scenario and game media not set as the specific game medium , as a deck to be used in a development game that progresses in accordance with the development scenario ;
a process of placing at least one of a plurality of game media, including the game media set in the specific game media and the game media set in the deck, in one of a plurality of selection items selectable by a player in the training game;
a process of displaying a selection screen that allows identification of the plurality of selection items and the game contents arranged in the selection items;
a process for allowing a player to input a selection operation for selecting one of the plurality of selection items displayed on the selection screen;
a process of executing a first update process of updating a training parameter linked to the training target game medium when the selection operation is input;
a process of executing a second update process, when the selection operation is input, of updating a specific parameter associated with the game content arranged in the selection item for which the selection operation is input;
a process of granting an advantageous effect that is advantageous to the player under at least one of the conditions that the game medium set for the specific game medium is set in the deck, and that the game medium set for the specific game medium and set in the deck is placed in the selection item for which the selection operation was input;
The computer executes the following .
The process of imparting the advantageous effect includes:
increasing an update amount of the specific parameter in the second update process when the specific game content is set to the selection item for which the selection operation is input and the game content set to the deck is placed;
Information processing program. The process of imparting the advantageous effect includes:
When the game content set for the specific game content is set in the deck, increasing the initial value of the specific parameter linked to the game content.
The information processing program according to claim 1 . The process of imparting the advantageous effect includes:
increasing the probability that the game medium set to the specific game medium and set to the deck will be placed in the selection item compared to the probability that the game medium not set to the specific game medium and set to the deck will be placed in the selection item;
3. The information processing program according to claim 1. 1. An information processing method performed by one or more computers, comprising:
The computer
a process of setting a game medium selected by a player from a plurality of game media including game media set as specific game media in a development scenario and game media not set as the specific game medium , as a deck to be used in a development game that progresses in accordance with the development scenario ;
In the training game, a process of placing at least one of a plurality of game media including the game media set in the specific game media and the game media set in the deck in one of a plurality of selection items selectable by a player;
a process of displaying a selection screen that allows identification of the plurality of selection items and the game contents arranged in the selection items;
a process for allowing a player to input a selection operation for selecting one of the plurality of selection items displayed on the selection screen;
a process of executing a first update process of updating a training parameter linked to the training target game medium when the selection operation is input;
a process of executing a second update process, when the selection operation is input, of updating a specific parameter associated with the game content arranged in the selection item for which the selection operation is input;
a process of granting an advantageous effect that is advantageous to the player under at least one of the conditions that the game medium set for the specific game medium is set in the deck, and that the game medium set for the specific game medium and set in the deck is placed in the selection item for which the selection operation was input;
and
The process of imparting the advantageous effect includes:
increasing an update amount of the specific parameter in the second update process when the specific game content is set to the selection item for which the selection operation is input and the game content set to the deck is placed;
Information processing methods. An information processing system comprising one or more computers,
The computer
a process of setting a game medium selected by a player from a plurality of game media including game media set as specific game media in a development scenario and game media not set as the specific game medium , as a deck to be used in a development game that progresses in accordance with the development scenario ;
In the training game, a process of placing at least one of a plurality of game media including the game media set in the specific game media and the game media set in the deck in one of a plurality of selection items selectable by a player;
a process of displaying a selection screen that allows identification of the plurality of selection items and the game contents arranged in the selection items;
a process for allowing a player to input a selection operation for selecting one of the plurality of selection items displayed on the selection screen;
a process of executing a first update process of updating a training parameter linked to the training target game medium when the selection operation is input;
a process of executing a second update process, when the selection operation is input, of updating a specific parameter associated with the game content arranged in the selection item for which the selection operation is input;
a process of granting an advantageous effect that is advantageous to the player under at least one of the conditions that the game medium set for the specific game medium is set in the deck, and that the game medium set for the specific game medium and set in the deck is placed in the selection item for which the selection operation was input;
and
The process of imparting the advantageous effect includes:
increasing an update amount of the specific parameter in the second update process when the specific game content is set to the selection item for which the selection operation is input and the game content set to the deck is placed;
Information processing system.