Information processing program, information processing method, and information processing system

JP2025118960A5Pending Publication Date: 2025-10-30CYGAMES INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2025084037
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2025-05-20
Publication Date
2025-10-30

AI Technical Summary

Technical Problem

Conventional character development games lack strategic depth, leading to reduced enjoyment for players, as the training method is largely determined by desired abilities and character development is often straightforward.

Method used

An information processing system that allows players to select multiple training events for a main character, associate sub-characters with these events, compare abilities, and generate events to either enhance the main character or sub-characters based on ability comparisons, thereby increasing strategic complexity and engagement.

Benefits of technology

Enhances game enjoyment by introducing strategic depth through dynamic ability updates and interactions between main and sub-characters, making gameplay more engaging and interactive.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

To improve amusement properties of a game.SOLUTION: A game machine executes: processing for updating ability information on a main character corresponding to a selected rearing item; processing for associating any one or a plurality of a plurality of sub-characters with any one of a plurality of kinds of rearing items; processing for comparing ability information showing ability of sub-characters for each sub-character associated with the rearing item with ability information on the main character when the rearing item associated with the sub-character is selected; processing for generating either an event of a first kind for enhancing the ability information on the main character or an event of a second kind for enhancing the ability information on the sub-character on the basis of a result of the comparison between the ability information on the sub-character and the ability information on the main character; processing for updating the ability information on the main character on the basis of the generation of the event of the first kind, and updating the ability information on the sub-character on the basis of the generation of the event of the second kind; and processing for performing a match game on the basis of the ability information on the main character and the ability information on the sub-character.SELECTED DRAWING: Figure 26
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates to an information processing program, an information processing method, and an information processing system. [Background technology]

[0002] Conventionally, as shown in Patent Document 1, for example, a genre of games called "training games" has been known. In training games, a plurality of 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 targeted for ability improvement. Therefore, a player can selectively improve desired abilities of the character to be trained. By increasing the parameters of the character to be trained, a player can advance advantageously in a fighting game or the like.

[0003] Furthermore, for example, Patent Document 2 discloses a game in which a player can scout players and organize a team. In this game, a competitive game can be played using the team organized by the player. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2019-154564 [Patent Document 2] Patent No. 6732178 Summary of the Invention [Problem to be solved by the invention]

[0005] In a character development game, the player's training method is largely determined by the character's desired abilities. Furthermore, when playing a competitive game using the characters developed, the character's abilities are largely determined. Therefore, conventional character development games require players to have little strategy, which can reduce the enjoyment of the game.

[0006] An object of the present invention is to provide an information processing program, an information processing method, and an information processing system that can increase the enjoyment of a game. [Means for solving the problem]

[0007] In order to solve the above problem, an information processing program is an information processing program that causes a computer to repeatedly execute a process for each turn multiple times, A process for selecting, in at least two or more turns, a plurality of types of training events corresponding to one or more of a plurality of pieces of ability information indicating the abilities of the main character; a process of updating the ability information of the main character corresponding to the training event selected by a player; A process of associating one or more of a plurality of sub-characters different from the main character with any of a plurality of types of the training events; When the training event associated with the sub-character is selected, a process of comparing ability information indicating the ability of the sub-character associated with the training event with the ability information of the main character for each sub-character associated with the training event; a process of generating either a first type of event that increases the ability information of the main character or a second type of event that increases the ability information of the sub-character based on a result of a comparison between the ability information of the sub-character and the ability information of the main character; a process of updating the ability information of the main character based on the occurrence of the first type of event, and updating the ability information of the sub-character based on the occurrence of the second type of event; a process of executing a fighting game based on the ability information of the main character and the ability information of the sub-character; The computer performs the following.

[0008] When the training event associated with a plurality of the sub-characters is selected during one turn, both the first type of event and the second type of event may occur.

[0009] In the process of comparing the ability information of the sub-character with the ability information of the main character, the ability information corresponding to the training event selected by a player is compared; In the process of generating the first type of event or the second type of event, if the ability information of the sub-character is higher than the ability information of the main character, the first type of event may be generated, and if the ability information of the main character is higher than the ability information of the sub-character, the second type of event may be generated.

[0010] In the process of updating the ability information of the sub-characters based on the occurrence of the second type of event, the ability information of all the sub-characters whose compared ability information is lower than that of the main character is updated; When the second type of event occurs, updating the ability information of the main character based on the number of sub-characters whose ability information is lower than that of the main character; Furthermore, the process may be performed by a computer.

[0011] In order to solve the above problem, the information processing method is an information processing method that performs processing for each turn by repeating the processing multiple times, and includes the steps of: making it possible to select, in at least two or more turns, multiple types of training events corresponding to any one or more of multiple ability information indicating the abilities of a main character; updating the ability information of the main character corresponding to the training event selected by a player; associating any one or more of multiple sub-characters different from the main character with any of the multiple types of training events; and, when the training event associated with the sub-character is selected, updating the ability information of the sub-character for each of the sub-characters associated with the training event. The method includes the steps of: comparing ability information indicating abilities with the ability information of the main character; generating either a first type of event that increases the ability information of the main character or a second type of event that increases the ability information of the sub-character based on the result of the comparison between the ability information of the sub-character and the ability information of the main character; updating the ability information of the main character based on the occurrence of the first type of event, and updating the ability information of the sub-character based on the occurrence of the second type of event; and executing a fighting game based on the ability information of the main character and the ability information of the sub-character.

[0012] In order to solve the above problem, the information processing system is an information processing system including a computer that executes a process for each turn by repeating it a plurality of times, and the computer performs the following processes in at least two or more turns: a process for selecting a plurality of types of training events corresponding to one or more of a plurality of pieces of ability information indicating the abilities of a main character; a process for updating the ability information of the main character corresponding to the training event selected by a player; a process for associating one or more of a plurality of sub-characters different from the main character with one of the plurality of types of training events; and a process for updating the sub-characters associated with the training event when the training event associated with the sub-character is selected. a process of comparing ability information indicating the ability of the sub-character with the ability information of the main character for each event; a process of generating either a first type of event that increases the ability information of the main character or a second type of event that increases the ability information of the sub-character based on a result of the comparison between the ability information of the sub-character and the ability information of the main character; a process of updating the ability information of the main character based on the occurrence of the first type of event and updating the ability information of the sub-character based on the occurrence of the second type of event; and a process of executing a fighting game based on the ability information of the main character and the ability information of the sub-character. Carry out the following. [Effects of the Invention]

[0013] According to the present invention, the interest in the game can be increased. [Brief explanation of the drawings]

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

[0015] An embodiment of the present invention will be described in detail below with reference to the accompanying drawings. Numerical values and the like shown in the embodiment are merely examples for ease of understanding and do not limit the present invention unless otherwise specified. In this specification and drawings, elements having substantially the same functions and configurations are designated by the same reference numerals to avoid redundant explanation, and elements not directly related to the present invention are not shown.

[0016] (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.

[0017] In the information processing system S of this embodiment, the player terminal 1 and the server 1000 function as a 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.

[0018] 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.

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

[0020] The communication base station Na is connected to the communication network N and wirelessly transmits and receives information 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.

[0021] (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 includes 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.

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

[0023] 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. Therefore, the following will describe the hardware configuration of the player terminal 1, and a description of the server 1000 will be omitted.

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

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

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

[0027] The communication unit 20 is wirelessly connected to the communication base station Na for communication, 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, the programs and the like received from the server 1000 are stored in the memory 12 or the storage unit 18.

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

[0029] The output unit 24 includes a display device and a speaker. The output unit 24 may 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.

[0030] (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 a character acquired by a lottery known as gacha, or a character distributed by the management side. Furthermore, a player can own a support card (support character) acquired by a lottery known as gacha, or a support card (support character) distributed by the management side. As will be described in detail later, this embodiment has a game feature 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 game feature in which the player trains the character and aims to come in first in a race that imitates a horse race.

[0031] FIG. 3 is a diagram for explaining the general flow of the training game. The training game is broadly divided into a preparatory stage process and a training stage process. The preparatory stage process will be described in detail in FIG. 29, which will be described later. The training stage process will be described in detail in FIGS. 30, 31, 32, 33, 34, 35, 36, and 37, which will be described later. Here, to facilitate understanding, the general flow of the preparatory stage process and the training stage process will be described first.

[0032] <Preparatory processing> In the preparation stage processing, mainly, registration of the main character, registration of support cards (support characters), registration of specific characters, and setting of initial character identification information are performed.

[0033] <Registering the main character> 4A is a diagram illustrating a home screen 27. In this embodiment, when a game app 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.

[0034] The menu bar 28 has a plurality of operation sections that can be operated (tapped) by the player. The menu bar 28 has a home screen selection operation section 28a marked "home" and a race screen selection operation section 28b marked "race" and a gacha screen selection operation section 28c marked "gacha." In the menu bar 28, the operation sections corresponding to each screen are highlighted so that the screen currently being displayed on the display 26 can be identified.

[0035] 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 a 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 participate in the gacha lottery by consuming in-game currency.

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

[0037] 4B is a diagram illustrating the main character selection screen 30. A plurality of character icons 31 are displayed in the center of the main character selection screen 30, displaying a list of characters owned by the player. A parameter display section 32 is displayed in the upper part of the main character selection screen 30. A return operation section 33 marked "Return" and a next operation section 34 marked "NEXT" are displayed in the lower part of the main character selection screen 30.

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

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

[0040] In this embodiment, initial ability parameter values are set for each of a plurality of types of abilities for each character. 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 a wisdom ability parameter marked "Wisdom" in the parameter display section 32.

[0041] The initial values of the ability parameters for each character may be increased by consuming in-game currency. The values of the ability parameters change when a predetermined condition is met after the start of the training game. Therefore, the player aims to increase the numerical values of the ability parameters of the character in the training game.

[0042] In this embodiment, aptitude parameters (initial values) are set for each character. FIG. 5B is a diagram illustrating an aptitude parameter (initial value) table. In this embodiment, as shown in FIG. 5B, the 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 and G indicates the lowest aptitude. Note that the initial values of aptitude parameters may be displayed on parameter display unit 32 based on the initial values of aptitude parameters stored in the aptitude parameter (initial value) table.

[0043] In this embodiment, initial values of aptitude parameters are set for each of a plurality of types of aptitude for each character. Specifically, the aptitude parameters include aptitude parameters relating to turf and dirt track aptitude, aptitude parameters relating to distance aptitude for short distance, mile, middle distance, and long distance, and aptitude parameters relating to running style aptitude for breakaway, leading, overtaking, and closing in.

[0044] The initial value of the aptitude parameter for each character may be increased by consuming 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.

[0045] Fig. 4C is a first diagram illustrating the character details screen 40. Fig. 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.

[0046] A skill operation section 41 and an event operation section 42 are displayed in the center of the character detail screen 40. As shown in FIG. 4C, when the 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. Each character's skills can be activated to gain an advantage in the race.

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

[0048] A character is set with one acquired skill 41a from the start of the training game. In addition to the acquired skill 41a, a plurality of possessed skills 41b are set with the character. The possessed skills 41b are skills that can be acquired by consuming skill points, which will be described later, after the training game starts. In other words, the possessed skills 41b can become acquired skills 41a in exchange for skill points.

[0049] In this embodiment, skills corresponding to "◎" in the skill table shown in Fig. 5C are displayed as acquired skills 41a on the character details screen 40 of Fig. 4C. Skills corresponding to "◯" in the skill table shown in Fig. 5C are displayed as possessed skills 41b on the character details screen 40 of Fig. 4C. In this embodiment, as shown on the character details screen 40 of Fig. 4C, acquired skills 41a are highlighted so that acquired skills 41a and possessed skills 41b can be easily distinguished from each other.

[0050] In this embodiment, FIG. 4C shows a case in which one acquired skill 41a and seven possessed skills 41b are 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. Furthermore, for example, the number of acquired skills 41a and possessed skills 41b for each character may be increased by consuming in-game currency.

[0051] Furthermore, when the player taps the event operation section 42 on the character detail screen 40, the content of the character detail screen 40 changes, and a dedicated event 42a provided for each character is displayed, as shown in Fig. 4D. In this case, the event operation section 42 is highlighted, as shown in Fig. 4D. The dedicated event 42a 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.

[0052] 5D is a diagram illustrating a dedicated event table. As shown in FIG. 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 FIG. 4D. The dedicated events 42a may include hint events that enable the player to possess or acquire a skill, ability events that increase or decrease the numerical value of a character's ability parameter, aptitude events that change a character's aptitude parameter, story events that display a story related to a character, and the like.

[0053] Note that the dedicated events 42a displayed on the character detail screen 40 shown in FIG. 4D may all be executed during the execution of the training game, or at least some of them may be executed during the execution of the training game, or none of them may be executed during the execution of the training game 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, dedicated events 42a not displayed as dedicated events 42a may be executed during the training game if a predetermined condition is met.

[0054] 4C and 4D, a close operation section 43 marked "close" is displayed at the bottom of the character detail screen 40. When the close operation section 43 of the character detail screen 40 is tapped, the display of the character detail screen 40 ends, and the main character selection screen 30 is displayed on the display 26.

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

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

[0057] <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 units 52. In addition, a return operation unit 53 marked "Return" and a start operation unit 54 marked "START" are displayed at the bottom of the support card setting screen 50.

[0058] A plurality of (here, six) support card setting operation units 52 are displayed in the support card display area 51. The number of support card setting operation units 52 displayed is the same as the number of support cards (support characters) that can be set by the player. When the support card setting screen 50 is initially displayed, the support card setting operation units 52 are displayed as blank spaces.

[0059] In this embodiment, six types of support cards (support characters) can be set from among the support cards (support characters) possessed by the player. Note that, of the six types that can be set, some (for example, five types) may be selectable from among the support cards (support characters) possessed by the player, and the remaining (for example, one type) may be selectable from among the support cards (support characters) that the player does not possess.

[0060] Fig. 6B is a diagram illustrating a support card selection screen 60. When the support card setting operation unit 52 on the support card setting screen 50 in Fig. 6A is operated, the support card selection screen 60 shown in Fig. 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.

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

[0062] 7A is a diagram illustrating a support card table. As shown in FIG. 7A, the support card table stores the type, rarity, level, and special training of the support character for each type of support card possessed by the player. The 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.

[0063] 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 rarity. In this embodiment, the higher the rarity of a support card (support character), the stronger 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 skills and support events possessed, which will be described later.

[0064] There are 50 levels for support cards (support characters), 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. The level of a support card can be increased by playing a training game or by using in-game currency. The level of a support card (support character) is capped depending on its rarity.

[0065] 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.

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

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

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

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

[0070] In this embodiment, just as the character that the player has set as the main character has the skills, the skills that are set for each support card (support character) are set. The skills that are set for each support card (support character) can be acquired by the main character selected by the player or by other characters that have been promoted to team members, which will be described later, when a hint event occurs during the training game.

[0071] FIG. 7D is a diagram illustrating a support event table. As shown in FIG. 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.

[0072] For example, the support event to be executed may be determined according to the number of turns, or may be determined by a predetermined lottery. Also, 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.

[0073] 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 FIG. 6C. On the other hand, when all six support cards are not selected, the start operation unit 54 becomes inoperable, as shown in FIG. 6A.

[0074] When the return operation section 53 on the support card setting screen 50 is operated, the main character selection screen 30 shown in FIG. 4B is displayed on the display 26.

[0075] Furthermore, 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.

[0076] <Registering specific characters> As described above, once the main character and support card (support character) are registered, the specific character is then registered. In this embodiment, four types of characters are set in advance as candidates for the specific character.

[0077] Fig. 8 is a first diagram illustrating a character identification information table. Fig. 9 is a second diagram illustrating a character identification information table. Fig. 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). Fig. 9 also 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).

[0078] In this embodiment, the character type set for the main character and the character type set for the support card (support character) are restricted so as not to overlap.

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

[0080] Furthermore, when a support card (support character) is selected by the player's operation, the character identification information table is updated, and the character corresponding to the selected support card (support character) is registered as a support character.

[0081] Then, when information related to the main character and the support card (support character) is registered in the character identification information table, information related to the specific character is registered. At this time, as shown in Fig. 8, if the registered main character does not overlap with the above-mentioned predetermined candidate for the specific character, the predetermined candidate for the specific character is registered as the specific character. That is, in the case of Fig. 8, "character F," "character J," "character N," and "character R" are registered as the specific characters.

[0082] As shown in Figure 9, if the registered main character overlaps with the above-mentioned preset candidate specific character, a character from among the preset candidate specific characters that does not overlap with the registered main character is registered as the specific character. In the case of Figure 9, "Character J," "Character N," and "Character R" are registered as the specific characters.

[0083] 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 previously set up as described above, the character will be registered as both a support card (support character) and a specific character.

[0084] <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 later, 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.

[0085] 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.

[0086] Furthermore, 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 Fig. 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. Also, in the case of Fig. 9, "Character E," "Character J," "Character L," "Character M," "Character N," "Character Q," "Character R," and "Character T" are registered as sub-members.

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

[0088] In this way, information (initial character identification information) relating to team members, sub-members, and random members is stored in the character identification information table.

[0089] <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. FIG. 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.

[0090] As shown in FIG. 10, the training 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.

[0091] FIG. 11A is a first diagram illustrating a game screen 70. FIG. 11B is a second diagram illustrating the game screen 70. When the process moves to the development stage, the game screen 70 shown in FIGS. 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 mainly 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."

[0092] The main character is also provided with a "condition" parameter. Condition display section 72 displays the current "condition" of the main character 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.

[0093] 11A and 11B, the central part of the game screen 70 displays an image of the main character, the current status of the main character as a number, and a rank (G + , F, F + , E, E + , D, D+ , C, C + , B, B + , A, A + , S, SS, SS + and a skill point display section 74 that numerically indicates the remaining number of skill points possessed by the main character in the training game. Specifically, in this embodiment, the numerical values and ranks of each ability parameter, "Speed," "Stamina," "Power," "Spirit," and "Wisdom," are displayed.

[0094] Also, as shown in Figures 11A and 11B, at the bottom of the game screen 70, 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" are displayed.

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

[0096] Furthermore, the player selects one of the following options for each turn: "Rest" (rest operation section 75), "Training" (training operation section 76), "Going Out" (going out operation section 78), "Race" (individual race operation section 79a), or "Team Race" (team race operation section 79b). At this time, the options that can be selected for each turn are preset, as shown in FIG. 10.

[0097] In this embodiment, when the "Team Race" (team race operation unit 79b) item is selectable, such as at the 20th, 30th, 35th, 57th, 59th, and 60th turns 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. Also, 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.

[0098] On the other hand, the skill operation section 77 is set to be always selectable in all turns. Note that, as will be described in detail later, even if a skill is acquired, the turn does not end.

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

[0100] 12A, training items are displayed at the bottom of the training screen 80. Here, a speed operation section 81 marked "Speed" is displayed, a stamina operation section 82 marked "Stamina" is displayed, a power operation section 83 marked "Power" is displayed, a guts operation section 84 marked "Spirit" is displayed, and an intelligence operation section 85 marked "Wisdom" is displayed.

[0101] When the player taps one of the operation units 81 to 85 once, the training item corresponding to the tapped operation unit 81 to 85 is provisionally selected, and the operation unit 81 to 85 corresponding to the provisionally selected training item is highlighted. Fig. 12A shows a state in which the power operation unit 83 has been provisionally selected. Fig. 12B shows a state in which the stamina operation unit 82 has been provisionally selected.

[0102] Additionally, each of the operation units 81 to 85 also displays the training level for each training item. As will be described in detail later, 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 the ability parameter when training is performed. The training level is initially set to level 1 and can increase up to a maximum of level 5.

[0103] Furthermore, the operation units 81 to 85 that are currently being temporarily selected display a failure rate display unit 86 that reads "Failure." The failure rate, which is displayed as a numerical value 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.

[0104] Additionally, in the status display section 73, training corresponding to the provisionally selected operation sections 81 to 85 is performed, and if successful, the value by which the ability parameter will increase is displayed. For example, in the case of FIG. 12A, the power operation section 83 is provisionally selected, and "Stamina" is displayed as "+8" and "Power" is displayed as "+10" in the status display section 73. In the case of FIG. 12B, the stamina operation section 82 is provisionally selected, and "Stamina" is displayed as "+15" and "Spirit" is displayed as "+5" in the status display section 73.

[0105] Furthermore, an event notification display 87 is displayed on the operation units 81 to 85 corresponding to the training items in which an event (a hint event, a support event, or a guidance event) described below occurs when the training is performed. The event notification display 87 can be displayed in different modes depending on the type of event.

[0106] Additionally, an icon 88 of a character placed in the training (joint training) is displayed for each of the temporarily selected operation units 81 to 85 in the upper right portion of the training screen 80. That is, one or more of a plurality of sub-characters different from the main character are associated with one of a plurality of types of training items (training events).

[0107] In addition, if a predetermined event (for example, a hint event, support event, or instruction event, which will be described later) occurs in response to the character displayed on the icon 88 while training is being performed, an event notification display 87 is displayed on the corresponding icon 88.

[0108] 12C is a diagram illustrating the training result notification screen 80a. When any of the temporarily selected operation units 81 to 85 is tapped again, the training corresponding to the tapped operation unit 81 to 85 is executed. In this way, it is possible to select a plurality of types of training items (training events) corresponding to one or more of the plurality of ability parameters (ability information) indicating the abilities of the main character.

[0109] Then, when the training is carried out, a training result notification screen 80a informing the player of the success or failure of the training is displayed on the display 26. Here, the word "success" is displayed, informing the player of the success of the training.

[0110] At this time, based on the success of the training, the ability parameters are updated and displayed in the status display section 73. That is, the ability parameters (ability information) of the main character corresponding to the training item (training event) selected by the player are updated.

[0111] Here, the value of the ability parameter that increases when the training displayed in the status display section 73 in FIG. 12A or 12B is successful is added. Also, the display in the stamina display section 71 is updated according to the training item that was performed. When speed, stamina, power, or tenacity training is performed and the training is successful, stamina decreases. On the other hand, when wisdom training is performed and the training is successful, stamina is restored.

[0112] Furthermore, if training fails, a predetermined penalty is imposed. Specific examples of the penalty include a decrease in stamina, a decrease in the numerical value of an ability parameter, a decrease in condition, and the like. For example, a penalty imposed when the failure rate is high may be more severe (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. Furthermore, for some training items (e.g., intelligence), no penalty may be imposed even if training fails.

[0113] 12D is a diagram illustrating the event screen 80b. When the display of the training result report 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, a support event, or a guidance event, which will be described later, may occur. Note that multiple events may occur.

[0114] For example, when a hint event occurs, a skill hint is obtained. When a skill hint is obtained, the player can acquire the skill by consuming skill points. There are multiple types of skills, and each skill may activate a predetermined ability. Each skill has a predetermined activation condition and effect, and when each activation condition is met, the predetermined effect is activated. Skills may be activated during individual races and team races, which will be described later.

[0115] 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 a predetermined lottery is won.

[0116] When all the events that have occurred have ended, the game screen 70 for the next turn is displayed.

[0117] Fig. 13A is a first diagram illustrating the skill screen 90. Fig. 13B is a second diagram illustrating the skill screen 90. When the skill operation unit 77 on the game screen 70 is operated, the skill screen 90 shown in Fig. 13A is displayed on the display 26.

[0118] 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 obtained, the skill points required to acquire the skill are displayed with a discount. At this time, the discount rate is also displayed.

[0119] Furthermore, for the skills displayed on the skill screen 90, the conditions for activating each skill and the effect when activated are displayed.

[0120] Also displayed at the top of the skill screen 90 are a stamina display section 71, a condition display section 72, and a skill point display section 74. Also displayed at the top of the skill screen 90 is the current number of turns.

[0121] When a player consumes skill points to acquire a skill they possess, as shown in FIG. 13B, the word "GET" is displayed next to the acquired skill to notify the player that the skill has been acquired, and the skill points consumed are subtracted from the skill points displayed in the skill point display section 74, and the display is updated.

[0122] Fig. 14A is a diagram illustrating an 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 Fig. 14A is displayed. The individual race has a game aspect in which the main character races against so-called non-player characters (hereinafter referred to as NPCs).

[0123] 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 marked "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.

[0124] FIG. 14B is a diagram illustrating an individual race start screen 110. When the start operation unit 102 is operated after the type of individual race in which the player will participate has been selected using the individual race selection operation unit 101, the individual race start screen 110 shown in FIG. 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.

[0125] Also, at the bottom of the individual race start screen 110, a result operation section 113 marked "Result" and a race operation section 114 marked "Race" are displayed.

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

[0127] 14C is a diagram illustrating the individual race result screen 120. When the playback of the race video 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.

[0128] FIG. 15A is a diagram illustrating a 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 FIG. 15A is displayed. In the center of the team race selection screen 130, an opponent team selection operation unit 131 for selecting an opponent for the team race to participate in is displayed. The opponent may be an NPC. Furthermore, the opponent is not limited to an NPC, and may be another player's team. In this case, a communication battle is held with the other player's team.

[0129] Note that characters to be entered in a team race need only be selectable from among team members, and do not necessarily have to include the main character. Also, one team member may be allowed to enter multiple races in a team race.

[0130] FIG. 15B is a diagram illustrating a team formation screen 140. When the competing team selection operation unit 131 is operated, the team formation screen 140 is displayed on the display 26. A team formation operation unit 141 is displayed on the team formation screen 140. By operating the team formation operation unit 141, the player can form a character formation for a 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.

[0131] Specifically, if the number of races won by the player's team out of the five races is greater than the number of races won by the opposing team, the player will win the team race overall. On the other hand, if the number of races won by the player's team out of the five races is less than or equal to the number of races won by the opposing team, the player will lose the team race overall. Note that the player can organize up to three types of characters from among his team members for each race. Note that the same type of character cannot be organized into multiple races. Also, a start operation unit 142 marked "Start" is displayed at the bottom of the team organization screen 140.

[0132] Fig. 15C is a diagram illustrating a 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 Fig. 15C is displayed. In this embodiment, five races are run in the team race, and the order in which they are run may be a predetermined order or may be determined randomly.

[0133] 15C, the characters of the player's team and the characters of the opponent's team for the race to be held are displayed in the center of the team race start screen 150. Here, the example shows a case where the player has organized two characters and the opponent has organized two characters for a "middle distance" race.

[0134] 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.

[0135] FIG. 15D is a diagram illustrating the team race interim result screen 160. When playback of the race video ends, or when the result operation unit 151 on the team race start screen 150 is operated, the team race interim result screen 160 is displayed on the display 26. The team race interim result screen 160 displays the results of the race (here, the "middle distance" race). Note that the method for determining the results of each of the five races in the team race is not particularly limited. 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.

[0136] Then, when the display of the team race interim results screen 160 in Figure 15D is completed, 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.

[0137] FIG. 16A is a first diagram illustrating a team race detailed result screen 170. Once the team race start screen 150 and the team race interim result screen 160 for all five types of races have been displayed as described above, the team race detailed result 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 result screen 170. The win / loss result display section 171 notifies the player of the win / loss results of each race. Here, as shown in FIG. 16A, a case is shown in which there are three wins and two losses in each race.

[0138] FIG. 16B is a 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 in the team race. As shown in FIG. 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.

[0139] Additionally, the team ranking is displayed on the team race overall result screen 180. In this embodiment, the team ranking changes based on the results of the team race. For example, if a team wins a team race, the team ranking increases.

[0140] Furthermore, on the team race overall result 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 result screen 180 is operated, the game screen 70 relating to the next turn is displayed.

[0141] Fig. 16C is a second diagram illustrating the team race detailed result screen 170. Here, as shown in Fig. 16C, a case is shown in which there are 2 wins and 3 losses in each race. Fig. 16D is a second diagram illustrating the team race overall result screen 180. As shown in Fig. 16C, if there are 2 wins and 3 losses in each race, the team race overall result screen 180 will notify that the team has lost the team race.

[0142] Furthermore, on the team race overall result screen 180 that 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.

[0143] 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 times.

[0144] Furthermore, when the finish operation unit 183 is operated, the game is over and the training game ends. However, the continue operation unit 182 and the finish operation unit 183 may not be displayed on the team race overall result screen 180 that notifies the player that a team race has been lost, and the next operation unit 181 may be displayed instead. In other words, even if a player is defeated in a team race, the training game may continue without the game being 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 the sub-characters registered as team members.

[0145] FIG. 17 is a diagram illustrating the relationship between team members, sub-members, and random members. Hereinafter, 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 FIG. 17, once joint training with a random member is successful, the random member is promoted to a sub-member.

[0146] Here, joint training refers to training in which a player selects 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 random member is successful in this training, the random member will be promoted to a sub-member.

[0147] However, without being limited to this, if a joint training session 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 a joint training session 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 session is successful or not.

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

[0149] In this embodiment, a sub-member may be registered as a team member. Specifically, a sub-member is provided with a registration parameter as a parameter. The registration parameter is updated when a predetermined registration condition is met. Then, as shown in FIG. 17, when the value of the registration parameter of a sub-member becomes equal to or greater than a predetermined threshold value (100), the sub-member is registered as a team member.

[0150] Once a character is registered as a team member, it cannot be changed to a sub-member or a random member. However, if a character registered as a team member meets a predetermined condition, it may be changed to a sub-member or a random member.

[0151] 18 is a diagram illustrating a registration parameter table. In this embodiment, a character registered as a sub-member is assigned a registration parameter. The registration parameter is a parameter used to determine whether or not a sub-member is promoted to a team member.

[0152] Specifically, when a specific character is registered as a sub-member, "40" is registered as the initial value of the registered parameter, as shown in Fig. 18. Then, thereafter, each time a joint training session with the specific character is successful, an increase value randomly determined from "10" to "20" is added to the registered parameter.

[0153] 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 FIG. 18. Then, each time joint training with the support character is successful, a randomly determined increase value between "10" and "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 and a support character overlap, either or both of the initial value and the increase value may be set to a higher value.

[0154] Furthermore, when a character other than a specific character or a 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, thereafter, each time a joint training session with the 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 (training event) selected by the player are updated. Note that, here, the increase value of the registered parameters when the joint training session 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.

[0155] That is, the registration parameters of the sub-character associated with the training event selected by the player are updated based on the predetermined registration conditions.

[0156] As shown in Figure 18, specific characters have higher initial values for registered parameters than support characters and other characters, and therefore their registered parameters are more likely to reach the threshold value (100) than support characters and other characters. Also, support characters have higher increased registered parameters than other characters, and therefore their registered parameters are more likely to reach the threshold value (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.

[0157] Although the present embodiment only describes the case where the registered parameters increase, the registered parameters may also decrease as long as they are updated based on predetermined registration conditions. For example, the registered parameters may be set to decrease when training fails.

[0158] Figure 19 is a diagram illustrating the general flow of the turn start processing. The training stage processing includes turn start processing that is executed at the start of each turn of the training game. Details of the turn start processing will be described in detail later with reference to Figures 31, 32, 33, and 34. Here, the general flow of the turn start processing will be described.

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

[0160] <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.

[0161] 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.

[0162] 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.

[0163] <Process to determine the aptitude type of random members to be placed> Fig. 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 preset aptitude types are "A" (or "S") (A aptitude number) is stored. Specifically, in this embodiment, as shown in Fig. 20B, "short distance," "mile," "middle distance," "long distance," and "dirt" are set as preset aptitude types.

[0164] In addition, the aptitude number table will be updated when a sub-member is promoted to a team member, or when a predetermined condition is met during the training game and the aptitude parameters related to the above aptitude types of the team member's character are updated.

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

[0166] As shown in Figure 5B, for example, character C has aptitude parameters for "mile" and "medium distance" of "A," and if character C is registered as a team member, he will be counted as a character with an aptitude parameter of "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.

[0167] 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, first, the aptitude number table is referenced and the aptitude type with the smallest A aptitude number is extracted.

[0168] As shown in FIG. 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" > "middle distance" > "long distance" > "dirt." For example, in the case of FIG. 20B, the A aptitude numbers for "long distance" and "dirt" are registered as "1," so "long distance," which has the highest priority, is extracted. Then, from the characters registered as random members, a random member whose extracted aptitude type (here, "long distance") is "A" is extracted, and one of the extracted random members is selected by lottery.

[0169] Note that the specific lottery method is not particularly limited. For example, random members that are more likely to be selected by lottery and random members that are less likely to be selected by lottery may be provided. For example, with reference to Figures 5A and 5B, the higher the initial value of the ability parameter or the initial value of the aptitude parameter of a random member, the less likely it is that the random member will be selected by lottery. Alternatively, the lottery may be conducted with equal probability. Then, the random member that is selected by the lottery is stored as the random member to be placed in one of the training items.

[0170] If there are multiple random members to be placed, the above-mentioned extraction of the aptitude type with the smallest A aptitude number and the lottery of the extracted random members with an "A" aptitude type are repeated the number of times to be placed. At this time, 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 FIG. 5B). In other words, when determining the second random member, the aptitude type of the first random member may be taken into consideration. This promotes equalization of the A aptitude number for each aptitude type.

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

[0172] Specifically, in this embodiment, as shown in Figure 21, if "support character", "specific character", and "team member" are registered as the character identification information, "place" is selected with an 80% probability. Also, if "support character", "specific character", and "sub-member" are registered as the character identification information, "place" is selected with a 40% probability.

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

[0174] If the character identification information is registered as "specific character" and "team member," there is a 60% chance that "place" will be selected. If the character identification information is registered as "specific character" and "sub-member," there is a 20% chance that "place" will be selected.

[0175] 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.

[0176] In other words, as shown in FIG. 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."

[0177] Also, as shown in FIG. 21, when the character identification information includes a "support character," the probability of selecting "place" is set to be higher than when the character identification information does not include a "support character."

[0178] Also, 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."

[0179] That is, a sub-member who is set as a support character is more likely to be associated with a training item (training event) than a sub-member who is not set as a support character. Also, the sub-members include specific characters (predetermined specific sub-characters), and the specific characters are more likely to be associated with a training item (training event) than characters other than the specific characters.

[0180] <Process to determine the training items to be placed> Next, for the "random members," "team members," and "sub-members" that have been determined to be placed as described above, it is decided which training item they will be placed in: "Speed," "Stamina," "Power," "Spirit," or "Wisdom."

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

[0182] <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 related to "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, the training levels are set to "Level 5."

[0183] 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). Here, the training level for all training items is the same for the team ranking, but the training level may be different for each training item for the same team ranking.

[0184] In this embodiment, when the training selected by the player is executed and successful, the value of a predetermined ability parameter increases due to the executed training item.

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

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

[0187] Furthermore, if "Power" training is performed and is successful, the values of the ability parameters "Stamina" and "Power" will increase.

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

[0189] Additionally, "Wisdom" training is performed, and if successful, the values of the ability parameters "Speed" and "Wisdom" will increase.

[0190] In this embodiment, the value of the ability parameter that increases when training is successful is calculated by multiplying a fixed increase value determined in accordance with the training item and training level performed by a bonus addition rate, which will be described later, and adding the result to the fixed increase value.

[0191] FIG. 22B is a diagram illustrating a fixed increase value (speed) table. Also, FIG. 22C is a diagram illustrating a fixed increase value table (power). That is, FIG. 22B shows fixed increase values when the training item is "Speed." Also, FIG. 22C shows fixed increase values when the training item is "Power."

[0192] 22B and 22C, the fixed increase value table stores fixed increase values determined in accordance with the training item and training level performed. In this embodiment, as shown in FIGS. 22B and 22C, the higher the training level, the greater the increase in the ability parameter when training is performed.

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

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

[0195] 22D is a diagram illustrating a bonus addition rate table. In this embodiment, the bonus addition rate is determined based on the character identification information of the character whose placement in each training session has been determined.

[0196] Specifically, as shown in FIG. 22D, the bonus addition rate table sets, for each character identification information of a character, whether or not there is a bonus addition rate and a selection ratio of the addition rate (10% increase or 20% increase).

[0197] 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.

[0198] Furthermore, 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.

[0199] Furthermore, 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.

[0200] Furthermore, if "team member" is registered as character identification information, there is an 80% probability that "none" will be selected, and a 20% probability that "10% up" will be selected.

[0201] Additionally, 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, then "none" will be selected with a 100% probability.

[0202] In other words, as shown in FIG. 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 the character identification information does not include "team member."

[0203] The fixed increase value determined by the fixed increase value table is then multiplied by the bonus addition rate and added to the fixed increase value to determine the increase amount of the ability parameter value when the training is successful. Note that for training in which multiple characters are assigned, the bonus addition rates for each of the assigned characters are added together, the total value of the bonus addition rates is multiplied by the fixed increase value, and the fixed increase value is then added again to determine the increase amount of the main character's ability parameter when the training is successful. In the same way, the increase amount of the main character's ability parameter when the training is successful is determined for all training types.

[0204] <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.

[0205] Specifically, as shown in FIG. 23, possible events are set based on the magnitude relationship of the ability parameters of 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. That is, 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 the ability parameter values 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.

[0206] Here, when team members are arranged and a training item is selected, for each team member associated with the training item, a skill parameter indicating the ability of the team member is compared with a skill parameter of the main character.

[0207] Furthermore, if the ability parameters of the main character are equal to or greater than the ability parameters of the team members, a training event is set to occur without fail. As will be described in detail later, training events include a "success" execution pattern and a "great success" execution pattern. When a training event occurs and the training event has a "success" execution pattern, the ability parameters of the team members increase within a predetermined range. Furthermore, when the training event has a "great success" execution pattern, the ability parameters of the team members increase by a greater amount than the above-mentioned predetermined range, and a predetermined special event is also carried out. In the special event, for example, the main character can acquire skill hints.

[0208] 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. Furthermore, when a training event occurs, the character whose ability parameter is 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.

[0209] Furthermore, if the ability parameter of the main character is lower than the ability parameter 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 parameter of the main character, a hint event related to a skill possessed by any one of the team members will occur. Also, as shown in FIG. 23, when a hint event occurs, the main character will acquire a hint for a skill possessed related to the hint event. Note that this may include a hint event in which the ability parameter of the main character increases, or a hint event in which the main character acquires a skill that has already been acquired.

[0210] That is, based on the result 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, based on the occurrence of a hint event (first type of event), the ability parameters (ability information) of the main character are updated, and based on the occurrence of a training event (second type of event), the ability parameters (ability information) of the sub-character are updated. 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.

[0211] Figure 24A is the first diagram illustrating 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 characters of the assigned team members are compared to determine which is larger or smaller.

[0212] In the case of FIG. 24A, for Character A, Character B, and Character C, the main character has a higher ability parameter related to "Speed." In this case, the execution of a training event is determined for each of Character A, Character B, and Character C. Also, a special event that occurs when the training event is a great success is determined for each of them. The process of determining whether the training event will be executed in a "success" or "great success" execution pattern is executed when "Speed" training is executed based on the player's operation.

[0213] Also, in the case of FIG. 24A, for characters D and E, the ability parameter related to "Speed" is lower for the main character. In this case, the execution content of the hint event for characters D and E is determined by lottery. The process of determining which hint event for character D or character E will be executed is executed when training for "Speed" is executed based on the player's operation.

[0214] That is, when 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.

[0215] FIG. 24B is a second diagram illustrating the process of determining whether or not an event will occur. FIG. 24B shows a case where there are five team members placed in "Stamina." In the case of FIG. 24B, for Character A, Character B, Character C, Character D, and Character E, the main character has a higher ability parameter related to "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 when the training event is a great success for each of them.

[0216] FIG. 24C is a third diagram illustrating the process of determining whether or not an event will occur. FIG. 24C shows a case where there are five team members assigned to "Stamina." In the case of FIG. 24C, for Character A, Character B, Character C, Character D, and Character E, the ability parameter related to "Stamina" is lower for the main character. 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.

[0217] 25A is a diagram illustrating a success pattern table. Fig. 25A shows the success pattern table that is referenced when training is performed based on the player's operation and a training event occurs, and the success pattern of the training event ("success" or "great success") is determined for that training event.

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

[0219] FIG. 25B is a diagram illustrating an event table eligible for bonus points. In this embodiment, when a training event occurs, a predetermined value is further added as a bonus to the ability parameter of the main character, as shown in FIG. 25B, depending on the training item that was executed. In this embodiment, when training events involving multiple characters occur in one turn, the value added as the bonus increases depending on the number of training events that occur. In other words, when a training event (a second type of event) occurs, the ability parameter (ability information) of the main character is updated based on the number of sub-characters whose compared ability parameters (ability information) are lower than that of the main character. However, a fixed bonus may be added regardless of the number of training events that occur.

[0220] Next, a description will be given of the functional configuration of the player terminal 1 and the server 1000 for executing the above game. Note that the functional configuration related to the progress of the game will be mainly described here, and a description of other configurations will be omitted.

[0221] (Functional Configuration of Player Terminal 1) 26 is a diagram illustrating the configuration of the memory 12 in the player terminal 1 and its functions as a computer. 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.

[0222] 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 Fig. 26 are just examples, and the terminal-side game control program includes many other programs.

[0223] 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 is also provided with many other storage units.

[0224] The CPU 10 runs each program stored in the program storage area 12a and updates data in each storage unit in the data storage area 12b. The CPU 10 runs each program stored in the program storage area 12a, causing 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.

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

[0226] (Functional configuration of server 1000) 27 is a diagram illustrating the configuration of memory 1012 in server 1000 and its computer functions. Memory 1012 is provided with a program storage area 1012a and a data storage area 1012b. When a game starts, CPU 1010 stores a server-side game control program (module) in program storage area 1012a.

[0227] 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 Fig. 27 are just examples, and the server-side game control program includes many other programs.

[0228] The data storage area 1012b is provided with a player information storage unit 1300 as a storage unit for storing data. Note that the above-mentioned storage units are examples, and the data storage area 112b is provided with many other storage units.

[0229] The CPU 1010 runs each program stored in the program memory area 1012a and updates data in each memory unit in the data memory area 1012b. The CPU 1010 runs each program stored in the program memory area 1012a, causing 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.

[0230] Specifically, the CPU 1010 runs a transmission / reception program 1200, causing the computer to function as a transmission / reception unit 1200a. Similarly, the CPU 1010 runs a character lottery program 1202, a player information update program 1204, and a 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.

[0231] The transmitting / receiving units 200a and 1200a transmit and receive various types of information between the player terminal 1 and the server 1000.

[0232] The character lottery units 202a and 1202a control the processing related to the gacha lottery.

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

[0234] The game execution control units 206a and 1206a control the overall progress of the game.

[0235] (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 is represented as Pn (n is an arbitrary integer), and processing in the server 1000 is represented as Sn (n is an arbitrary integer).

[0236] When a player performs an input operation (lottery request operation) on a gacha screen (not shown), the character lottery unit 202a of the player terminal 1 executes lottery request information transmission processing (P1) for transmitting lottery request information to the server 1000.

[0237] 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 result. In addition, 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).

[0238] When the transmitting / receiving 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).

[0239] In addition, when the player operates the scenario operation section 29 on the home screen 27 (operation to start the training game), the game execution control section 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.

[0240] When the transmitting / receiving 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 reception of the necessary information by the player terminal 1. The necessary information includes information on various tables necessary for executing the training game.

[0241] When the transmitting / receiving unit 200a of the player terminal 1 receives the necessary information, the player information updating unit 204a of the player terminal 1 stores the necessary information in the data storage area 12b, and the player terminal 1 executes a preparation stage process (P5).

[0242] 29 is a flowchart illustrating the preparation stage processing (P5) in 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, the process proceeds to step P5-2, and if the main character selection screen 30 is not currently being displayed, the process proceeds to step P5-7.

[0243] 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 the event operation unit 42 on the character detail screen 40, or an operation of the menu bar 28, the return operation unit 33 or the next operation unit 34 on the main character selection screen 30 or the character detail screen 40 (display switching operation input) has been performed (P5-2).As a result, if a display switching operation input has been performed, the process proceeds to step P5-16, and if a display switching operation input has not been performed, the process proceeds to step P5-3.

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

[0245] 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 has been performed in the player information storage unit 300 (P5-4).

[0246] 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 decision operation input) (P5-5). If a decision operation input has been performed, the process proceeds to step P5-6, and if a decision operation input has not been performed, the process proceeds to step P5-7.

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

[0248] 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). As a result, if the support card setting screen 50 is currently being displayed, the process proceeds to step P5-8, and if the support card setting screen 50 is not currently being displayed, the preparation stage process ends.

[0249] The game execution control unit 206a of the player terminal 1 determines whether the menu bar 28 or the return operation unit 53 of 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, the process proceeds to step P5-16, and if the display switching operation input has not been performed, the process proceeds to step P5-9.

[0250] 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 icon 61 of a support card (support character) on the support card selection screen 60 (selection operation input) (P5-9). As a result, if the selection operation input has been performed, the process proceeds to step P5-10, and if the selection operation input has not been performed, the process proceeds to step P5-11.

[0251] The game execution control unit 206a of the player terminal 1 temporarily stores the support card (support character) of the icon 61 for which the selection operation has been performed in the player information storage unit 300 (P5-10).

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

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

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

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

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

[0257] 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.

[0258] Returning to Figure 28, when the preparation stage processing (P5) ends, the development stage processing (P6) is carried out. Figure 30 is a flowchart illustrating 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 mid-processing of step P20 is executed.

[0259] 31 is a flowchart illustrating 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 (FIG. 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, the processing proceeds to step P10-2, and if it is not a team race-only turn, the processing proceeds to step P11.

[0260] 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 later.

[0261] If it is a team race limited turn, the game execution control unit 206a of the player terminal 1 executes a team race start process (P10-2). For example, a process for determining an opponent in the team race is executed. Furthermore, if the player is competing against another player's team in the team race, a process for matching with the other player who will be the opponent is executed.

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

[0263] 32 is a flowchart illustrating the placement process in the player terminal 1. The game execution control unit 206a of the player terminal 1 refers to the character identification information table and derives the total number of characters registered as team members and characters registered as sub-members (P11-1).

[0264] The game execution control unit 206a of the player terminal 1 sets the random member placement number table of FIG. 20A (P11-2).

[0265] 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 referring to the random member placement number table set in step P11-2 (P11-3).

[0266] 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). If the number is 0, the process proceeds to step P11-10. If the number is not 0, the process proceeds to step P11-5.

[0267] 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).

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

[0269] 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" determined in step P11-6 above from among the characters registered as random members (P11-7).

[0270] 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 (P11-8).

[0271] 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 moves the process to step P11-4.

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

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

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

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

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

[0277] The game execution control unit 206a of the player terminal 1 determines whether "place" was determined in step P11-14 (P11-15). As a result, if "place" was determined, the process proceeds to step P11-16, and if "place" was not determined, the process proceeds to step P11-17.

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

[0279] The game execution control unit 206a of the player terminal 1 determines whether the processes of P11-11 to P11-16 have been completed for all of the team members, sub-members, and random members whose placements have been determined in step P11-10 (P11-17). If the process for all members has been completed, the placement process is terminated, and if the process for all members has not been completed, the process proceeds to step P11-11.

[0280] 33 is a flowchart illustrating the numerical value determination process in 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 among the training items "Speed," "Stamina," "Power," "Spirit," and "Wisdom" (P12-1).

[0281] 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 current physical strength of the main character (P12-2).

[0282] The game execution control unit 206a of the player terminal 1 determines and stores the reduction value of physical strength when training is performed for the processing target item set in step P12-1 (P12-3).

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

[0284] The game execution control unit 206a of the player terminal 1 determines the training level based on the team ranking confirmed in step P12-4 above, with reference to the training level table (FIG. 22A) (P12-5).

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

[0286] The game execution control unit 206a of the player terminal 1 checks the information (arrangement information) of the characters whose arrangement has been determined in step P11 above for the training of the processing target item (P12-7).

[0287] The game execution control unit 206a of the player terminal 1 calculates the bonus addition rate by referring to the bonus addition rate table (FIG. 22D) based on the arrangement information confirmed in step P12-7 (P12-8).

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

[0289] 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 of the training items, "Speed," "Stamina," "Power," "Spirit," and "Wisdom" (P12-10). If the processing of all of the training items has been completed, the numerical value determination process is terminated, and if the processing of all of the training items has not been completed, the process proceeds to step P12-1.

[0290] 34 is a flowchart illustrating 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 the event for the main character refers to a dedicated event set for the main character among the dedicated events set in advance in the dedicated event table (FIG. 5D).

[0291] The game execution control unit 206a of the player terminal 1 refers to the support event table (FIG. 7D), and determines and executes the support event set for the support card (support character) (P13-2).

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

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

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

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

[0296] The game execution control unit 206a of the player terminal 1 compares the ability parameters relating to the processing target items set in step P13-3 with the main character and the team members to be processed set in step P13-6 (P13-7).

[0297] 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, the process proceeds to step P13-9, and if the ability parameters of the main character are not equal to or greater than the ability parameters of the team member being processed, the process proceeds to step P13-12.

[0298] The game execution control unit 206a of the player terminal 1 executes a training event determination process (P13-9) to determine whether a training event will be executed for the team member to be processed that was set in step P13-6.

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

[0300] The game execution control unit 206a of the player terminal 1 determines a special event to be executed in the event of a great success according to a predetermined determination method 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 the special event, for example, possessed or acquired skills related to running style aptitude (escape, leading, overtaking, and chasing) may be available. Also, a special event determined by referring to a dedicated event table (FIG. 5D) related to the main character may be executed as the special event. Also, a special event determined by referring to a dedicated event table (FIG. 5D) related to the main character may be executed as the special event.

[0301] The game execution control unit 206a of the player terminal 1 executes a hint event determination process (P13-12) for determining a hint event to be executed for the team member to be processed set in step P13-6 above, in accordance with a predetermined determination method set in advance, with reference to the possessed skill table (FIG. 7C). For example, if the team member to be processed is a support character, the hint event to be executed may be determined from the support events set on the support card (support character) with reference to the support event table (FIG. 7D). Furthermore, if the team member to be processed is not a support character, the hint event to be executed may be determined from the dedicated events set for the team member to be processed with reference to the dedicated event table (FIG. 5D) for the team member to be processed.

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

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

[0304] 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 the processing of all training items has been completed, the event determination processing is terminated, and if the processing of all training items has not been completed, the processing proceeds to step P13-3.

[0305] 35 is a flowchart illustrating the during-turn processing in 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 individual race has started, the process proceeds to step P20-2, and if the individual race has not started, the process proceeds to step P20-4.

[0306] 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 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 and the race in which they participate are exactly the same, the race results may not necessarily be the same. Also, multiple patterns of calculation formulas, such as weighting, may be set for each race, and the results may vary depending on the selected calculation formula.

[0307] 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 individual race result derived in step P20-2 (P20-3).

[0308] 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, the process proceeds to step P20-5, and if the team race has not started, the process proceeds to step P20-8.

[0309] 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 calculation result. Note that the calculation formula may be set differently 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, multiple patterns of calculation formulas, such as weighting, may be set for each race, and the results may vary depending on the selected calculation formula.

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

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

[0312] 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, the process proceeds to step P21, and if none of the training items has been selected, the process proceeds to step P20-9.

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

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

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

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

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

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

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

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

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

[0322] 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, the process proceeds to step P21-8, and if hint event information is not stored, the process proceeds to step P21-10.

[0323] The game execution control unit 206a of the player terminal 1 executes a hint event generation process for executing a hint event based on the hint event information related to the selected training item (P21-8). Note that if multiple pieces of hint event information are stored for the selected training item, any one of the hint events is selected, and the selected hint event occurs.

[0324] 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 the above step P21-8 (P21-9).

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

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

[0327] 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 (P21-12).

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

[0329] The game execution control unit 206a of the player terminal 1 determines either "success" or "great success" by referring to the success pattern lottery table set in step P21-13, based on the number of training events of the target team member updated in step P21-12 (P21-14).

[0330] The game execution control unit 206a of the player terminal 1 updates the ability parameters of the team members to be executed based on the successful pattern determined in step P21-14 (P21-15).

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

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

[0333] The game execution control unit 206a of the player terminal 1 executes a character identification information update process (P22) when the game is successful, which will be described in detail later, and ends the training execution process.

[0334] 37 is a flowchart illustrating the character identification information update process at the time of success in the player terminal 1. The game execution control unit 206a of the player terminal 1 extracts the sub-members placed in the selected training item (P22-1).

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

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

[0337] The game execution control unit 206a of the player terminal 1 refers to the registered parameter table (FIG. 18) and determines the increase value of the registered parameter (P22-4).

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

[0339] The game execution control unit 206a of the player terminal 1 determines (P22-6) whether the value of the registered parameter of the processing target sub-member updated in step P22-5 is equal to or greater than a preset threshold value (100). If the value is equal to or greater than the threshold value, the process proceeds to step P22-8, and if the value is less than the threshold value, the process proceeds to step P22-7.

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

[0341] The game execution control unit 206a of the player terminal 1 updates the character identification information (FIGS. 8 and 9) so as to change the sub-member to be processed to a team member (P22-8).

[0342] The game execution control unit 206a of the player terminal 1 determines (P22-9) whether the processing of steps P22-3 to P22-8 has been executed for all sub-members extracted in step P22-1. 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.

[0343] The game execution control unit 206a of the player terminal 1 refers to the character identification information (FIGS. 8 and 9) and extracts sub-members (non-placed sub-members) other than the sub-members extracted in step P22-1 (P22-10).

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

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

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

[0347] 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). If the value of the demotion counter is "0", the process proceeds to step P22-15, and if the value of the demotion counter is not "0", the process proceeds to step P22-16.

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

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

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

[0351] The game execution control unit 206a of the player terminal 1 determines (P22-18) whether the random member placed in step P22-17 has been extracted (is present). As a result, if a random member has been placed, the process proceeds to step P22-19, and if no random member has been placed, the successful character identification information update process ends.

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

[0353] The game execution control unit 206a of the player terminal 1 updates the character identification information (FIGS. 8 and 9) so as to change the random member to be processed to a sub-member (P22-20).

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

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

[0356] 37 is a flowchart illustrating the character identification information update process at the time of failure in the player terminal 1. The game execution control unit 206a of the player terminal 1 references the character identification information (FIGS. 8 and 9) and extracts sub-members (P23-1).

[0357] The game execution control unit 206a of the player terminal 1 determines (P23-2) whether a sub-member has been extracted (is present) in step P23-1. 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 at the time of failure is terminated.

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

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

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

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

[0362] 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). If the processing of all sub-members has been completed, the character identification information update processing at the time of failure is terminated, and if the processing of all sub-members has not been completed, the processing proceeds to step P23-3.

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

[0364] When the transmitting / receiving unit 200a of the server 1000 receives the end information, the player information updating unit 1204a of the server 1000 updates the player information stored in the player information storage unit 1300 based on the end information (S4).

[0365] 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, and the execution timing and device are not particularly limited. For example, in the above embodiment, a case has been described in which the processing related to the preparation stage processing (P5) and the training stage processing (P6) is all executed on the player terminal 1 side, but when various lotteries are executed in the training game, the lotteries may be executed on the server 1000 side, and the player terminal 1 may obtain the lottery results to progress the training game.

[0366] In the above embodiment, the case where the training game is made up of the first to sixtieth turns has been described, but the number of turns is not limited. That is, it is sufficient that the training game is made up of at least two turns.

[0367] Furthermore, in the above embodiment, a case has been described in which the performance parameters related to multiple training items increase when one training item is performed, but the present invention is not limited to this. For example, the performance parameter related to one training item may increase when one training item is performed. Alternatively, the present invention may include both a case in which the performance parameters related to multiple training items increase when one training item is performed, and a case in which the performance parameter related to one training item increases when one training item is performed.

[0368] Furthermore, in the above embodiment, the case where the player always selects a support card (support character) in the training game has been described, but the training game may be executed without the need for a support card (support character).

[0369] Furthermore, in the above embodiment, a specific character is provided in the training game, but the present invention is not limited to this. That is, a specific character does not have to be provided.

[0370] <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.

[0371] <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.

[0372] <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.

[0373] In the above embodiment, the character identification information includes main character, support character, specific character, team member, sub-member, and random member. On the other hand, in the modified example, as shown in Figure 39, the character identification information includes main character, support character, specific character, team member, and sub-member. That is, the modified example differs significantly from the above embodiment in that the character identification information does not include random member.

[0374] Therefore, in the above embodiment, a case was shown 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, but in the modified example, only the case in which a sub-member is promoted to a team member is provided. Note that, as will be described in detail later, in the modified example, when a character registered as a sub-member meets a predetermined condition, the character registered as the sub-member is registered (promoted) as a team member.

[0375] 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.

[0376] Furthermore, in the character identification information table, characters or support cards (support characters) possessed by the player that are not registered as team members are registered as sub-members. That is, all of the 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 be registered as sub-members.

[0377] At the start of the training game, a character registered as a 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.

[0378] 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). That is, in the case of Figure 39, "Character C," "Character E," "Character I," "Character L," "Character M," "Character Q," and "Character T" are registered as team members.

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

[0380] <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 to 60th turns, and has a gameplay in which various parameters are updated according to the player's selection results in each turn.

[0381] Figure 40 is a diagram illustrating the general flow of the turn start processing according to a modified example. The training stage processing includes a turn start processing that is executed at the start of each turn of the training game. Details of the turn start processing will be described in detail later with reference to Figures 46, 47, 48, and 49. Here, the general flow of the turn start processing will be described.

[0382] In the turn start processing of the modified example, roughly as shown in Figure 40, "processing to determine whether or not to place team members," "processing to determine training items to be placed," "processing to determine the increase value of ability parameters," "processing to determine events that will appear," and "processing to determine guest characters" are executed.

[0383] 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" in the turn start processing (FIG. 19) according to the above embodiment.

[0384] However, it may be possible to place characters registered as sub-members in each training session (joint training session). In this case, the "process for determining random members to be placed" and the "process for determining whether or not to place sub-members" can be executed in the same manner as in the above embodiment.

[0385] On the other hand, the "processing to determine whether or not to deploy team members," "processing to determine the training items to be deployed," and "processing to determine the increase value of ability parameters" in the turn start processing in the modified example are executed in the same manner as in the above embodiment.

[0386] <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.

[0387] Fig. 41A is a diagram illustrating a game screen 70 according to a modified example. Fig. 41A shows a case where a training event, which will be described later, occurs in the turn. In this case, an event notification display 87 is displayed in the training operation section 76 of the game screen 70, as shown in Fig. 41A.

[0388] 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 later) occurs in response to a character displayed on an icon 88 on the training screen 80, an event notification display 87 is displayed on the icon 88 of the corresponding character.

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

[0390] The bond gauge 88a indicates a parameter (hereinafter referred to as the bond parameter) that increases according to the number of training sessions (joint training sessions) 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.

[0391] Furthermore, the special icon 88b indicates the number of times that a training event has been carried out for the character of the corresponding team member. As will be described in detail later, the special icon 88b is displayed in a display mode that corresponds to the number of times that a training event has been carried out for the character of the icon 88 on which the special icon 88b is displayed.

[0392] 42A is a diagram illustrating a training event execution / non-execution decision table according to a modified example. In the modified example, when it is determined that a team member is assigned to each training item, whether or not to execute a training event 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 FIG. 42A. Hereinafter, a team member for whom it has been determined that a training event will be executed is also referred to as a team member to be trained.

[0393] Specifically, as shown in FIG. 42A, the probability of selecting whether or not to execute a special training event is set based on the value of the bond parameter of the team member being trained. Here, the selection probability is set so that the larger the value of the bond parameter, the more likely it is that the special training event will be selected. 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 who can simultaneously be trained for one training item.

[0394] FIG. 42B is a diagram illustrating a special icon determination table according to a modified example. In the modified example, the special training event includes a "success" execution pattern and a "great success" execution pattern. In the modified example, when the fifth special training event is executed 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 special training event other than the fifth is executed for each training target team member, the special training event is always executed using the "success" execution pattern. In other words, for one training target team member, the special training event can be executed using the "great success" execution pattern only once. Note that the event notification display 87 may be displayed in different ways depending on the content of the special training event to be executed (the "success" execution pattern or the "great success" execution pattern) and the number of team members for whom the execution of the special training event has been determined.

[0395] As shown in Figure 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.

[0396] 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 carried out for the team member being trained, the more likely the "great success" execution pattern will be selected. In this case, the larger the size of the special icon 88b, the more likely the "great success" execution pattern will be selected, and therefore the special icon 88b indicates the likelihood of the "great success" execution pattern being selected.

[0397] Furthermore, after a training event has been executed with the "great success" execution pattern, that is, when the number of times the training event has been executed for the team member being trained is 5 or more, a special icon 88b is displayed in a larger size than when the number of times the training event has been executed for the team member being trained is 0 to 4, and a suggestion display a is displayed, as shown in Figure 42B, indicating that the training event has been executed with the "great success" execution pattern.

[0398] Furthermore, when a training event occurs and the training event has a "success" execution pattern, the ability parameters of the team members being trained and the ability parameters of the main character increase within a predetermined range. Furthermore, when the training event has a "great success" execution pattern, the ability parameters of the team members being trained and the ability parameters of the main character increase by a greater amount than the predetermined range.

[0399] Furthermore, 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 ability parameter of the main character will increase as a result of the training event is displayed in the status display section 73 of the training screen 80.

[0400] 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 special 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 special 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 special training event is 40 or more than when it is between 20 and 39.

[0401] 43A is a diagram illustrating a bonus fixed value (main character) table according to a modified example. When the above-mentioned training event is executed, the value (bonus fixed value) by which the ability parameter of the main character is increased by the special training event is determined according to the number of team members for whom the special training event is decided to be executed. Here, as shown in FIG. 43A, the value (bonus fixed value) by which the ability parameter of the main character is increased by the special training event is set to be larger the greater the number of team members for whom the special training event is decided to be executed.

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

[0403] FIG. 44A is a diagram illustrating a fixed increase value (training target) table according to a modified example. When the above-described training event is executed, the value (fixed increase value) by which the ability parameter of the training target team member is increased by the training event is determined. Here, as shown in FIG. 44A, a range of values (fixed increase value) by which the ability parameter of the training target team member is increased is set depending on the type of training executed. Here, a value (fixed increase value) within the range set in FIG. 44A is determined by lottery.

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

[0405] When a training event is executed in the "great success" execution pattern, an additional increase event may be executed to increase 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 executed simultaneously. For example, the greater the number (number of times) of training events in the "great success" execution pattern executed simultaneously, the greater the increase in the ability parameters of the team member being trained and the ability parameters of the main character.

[0406] <Process for Determining Guest Characters According to Modification> As shown in Figure 40, the modified example differs significantly from the above embodiment in that it executes a "guest character determination process" that is not executed in the above embodiment. 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)).

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

[0408] In this process, a first lottery is performed to determine whether or not a guest character is to be set. If the first lottery is not won, a guest character is not set in that turn.

[0409] 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, if the total number of characters registered as team members is 21 or more, a guest character will not be set.

[0410] Next, as in the above embodiment, the aptitude number table (FIG. 20B) is referenced to extract and determine the aptitude type with the smallest A aptitude number. If there are multiple aptitude types with the smallest 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."

[0411] Then, from the characters registered as sub-members, sub-members whose extracted aptitude type is "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 whose extracted aptitude type is "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.

[0412] Next, a second lottery table is generated from among the characters registered as sub-members, excluding the sub-members included in the first lottery table. Note that, if it is possible to place characters registered as sub-members in each training (joint training), a second lottery table is generated from among 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.

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

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

[0415] Figure 45A is a diagram illustrating a game screen 70 according to a modified example. When the process moves to the development stage, the game screen 70 shown in Figure 45A is displayed on the display 26. When a guest character is determined 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 an individual race operation section 79a of the game screen 70. When a guest character is determined 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 a team race operation section 79b of the game screen 70.

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

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

[0418] In the modified example, as shown in FIG. 45B, a guest character is set in one individual race selection operation unit 101, but a guest character may 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 a guest character is 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.

[0419] A guest character may also be set for each of multiple team races in one turn. Also, a guest character may be set for all team races that the player can select. 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.

[0420] Next, a process according to a modified example for executing the above game will be described. Note that, in the following, a description of the same processes as in the above embodiment will be omitted, and only processes that differ from the above embodiment will be described in detail.

[0421] Figure 46 is a flowchart illustrating turn start processing in 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, the modified example differs from the above embodiment in that a guest character determination processing (P100), which will be described in detail later, is executed after step P10-2 in the turn start processing shown in Figure 31 in the above embodiment.

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

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

[0424] The game execution control unit 206a of the player terminal 1 selects, from among the team members extracted in step P11-a, a character that has not yet executed the processes of P11-12 to P11-16 (described later), as a target character to execute the processes (P11-b).

[0425] The game execution control unit 206a of the player terminal 1 refers to the character identification information table and checks the character identification information of the target character selected in step P11-b above (P11-12).

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

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

[0428] The game execution control unit 206a of the player terminal 1 determines whether "place" was determined in step P11-14 (P11-15). As a result, if "place" was determined, the process proceeds to step P11-16, and if "place" was not determined, the process proceeds to step P11-17.

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

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

[0431] FIG. 48 is a flowchart illustrating the guest character determination process (P100) in the player terminal 1 according to the modified example.

[0432] The game execution control unit 206a of the player terminal 1 determines whether the counter value of the non-winning counter, which indicates the number of consecutive turns in which a guest character has not been determined, is 2 or greater (P100-1). If the counter value of the non-winning counter is not 2 or greater, the process proceeds to step P100-3, and if the counter value of the non-winning counter is 2 or greater, the process proceeds to step P100-5.

[0433] 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).

[0434] 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, the process proceeds to step P100-4, and if the first lottery drawing was won, the process proceeds to step P100-5.

[0435] 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).

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

[0437] The game execution control unit 206a of the player terminal 1 refers to 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).

[0438] 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, the process proceeds to step P100-8; if the number of team members is not less than 20, the guest character determination process ends.

[0439] 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).

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

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

[0442] 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 (P100-11).

[0443] 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).

[0444] The game execution control unit 206a of the player terminal 1 determines by lottery which of the first lottery table generated in the above step P100-11 and the second lottery table generated in the above step P100-13 will be used (P100-14).

[0445] 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 (P100-15).

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

[0447] Fig. 49 is a flowchart illustrating an event determination process in a player terminal 1 according to a modified example. In the modified example, the event determination process shown in Fig. 49 is executed instead of the event determination process shown in Fig. 34 in the above embodiment.

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

[0449] The game execution control unit 206a of the player terminal 1 refers to the support event table (FIG. 7D), and determines and executes the support event set for the support card (support character) (P130-2).

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

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

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

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

[0454] The game execution control unit 206a of the player terminal 1 checks the value of the bond parameter for the team member to be processed, which was set in step P130-6 (P130-7).

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

[0456] The game execution control unit 206a of the player terminal 1 determines whether or not the execution of the special training event has been decided in the above step P130-8 (P130-9). As a result, if the execution of the special training event has not been decided, the process proceeds to step P130-10, and if the execution of the special training event has been decided, the process proceeds to step P130-12.

[0457] The game execution control unit 206a of the player terminal 1 executes a hint event determination process (P130-10) for determining the hint event to be executed for the team member to be processed set in the above step P130-6, in accordance with a predetermined determination method set in advance, by referring to the possessed skill table (FIG. 7C).

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

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

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

[0461] The game execution control unit 206a of the player terminal 1 determines the value (bonus increase value) by which the ability parameters of the training target team member will increase for the team member set in step P130-6 above, by referring to the bonus increase value (training target) table shown in Figure 44B (P130-14).

[0462] The game execution control unit 206a of the player terminal 1 refers to the bonus addition value (main character) table shown in FIG. 43B and determines the value (bonus addition value) by which the ability parameter of the main character will increase (P130-15).

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

[0464] The game execution control unit 206a of the player terminal 1 refers to the fixed bonus value (main character) table shown in FIG. 43B and determines the value (fixed bonus value) by which the ability parameter of the main character will increase (P130-17).

[0465] 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). If the processing of all training items has been completed, the event determination process is terminated, and if the processing of all training items has not been completed, the process proceeds to step P130-3.

[0466] FIG. 50 is a flowchart illustrating the mid-turn processing in a player terminal 1 according to a modified example. In the modified example, the mid-turn processing shown in FIG. 50 is executed instead of the mid-turn processing shown in FIG. 35 in the above embodiment. As shown in FIG. 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 FIG. 35 in the above embodiment. Also, as shown in FIG. 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 FIG. 35 in the above embodiment.

[0467] FIG. 51 is a flowchart illustrating the character identification information update process in the player terminal 1 according to the modified example.

[0468] 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, the process proceeds to step P200-2, and if the finishing order is not equal to or higher than the predetermined rank, the character identification information update process ends.

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

[0470] The game execution control unit 206a of the player terminal 1 updates the character identification information (FIG. 39) so as 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, for the ability parameters of the sub-member promoted to a team member, a preset initial value may be registered, or the ability parameters of the main character or a corrected value corrected according to the team level may be registered.

[0471] Figure 52 is a flowchart illustrating the training execution process in a player terminal 1 according to a modified example. In the modified example, the training execution process shown in Figure 52 is executed instead of the training execution process shown in Figure 36 in the above embodiment. As shown in Figure 51, in the modified example, the processes of step P22 and step P23 in the training execution process shown in Figure 36 in the above embodiment are not executed.

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

[0473] 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, the process proceeds to step P21-c, and if special training event information is not stored, the training execution process ends.

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

[0475] 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).

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

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

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

[0479] In the above-described modified example, a first lottery is executed for each turn to determine whether or not a guest character is to be set. However, 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 be set as the individual race or team race in which a guest character may 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 the target individual race and the target team race may be set according to the type of main character to be developed, for example.

[0480] In the above-described modified example, the sub-member of a guest character is always changed to a team member when the guest character finishes at or above a predetermined ranking in an individual race or team race in which the guest character is registered. However, this is not limited to this. For example, a lottery may be held based on the player's finishing position in the individual race or team race in which the guest character is registered, and if the player wins the lottery, the sub-member of the guest character may be changed to a team member. In this case, the higher the player's finishing position, the higher the probability of winning the lottery.

[0481] Furthermore, in the above-described modified example, the guest character determination process (P100) is performed during the turn start process as shown in FIGS. 46 and 47. However, the present invention is not limited to this. The guest character determination process (P100) may be performed during the turn process as shown in FIG. 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 as shown in FIG. 50. In this case, the guest character determination process (P100) is performed after the results of the individual race or the team race are determined, and therefore the guest icon 70a and the guest notification display 70b shown in FIGS. 45A and 45B are not displayed. In other words, the player is not notified of whether a guest character is registered in the individual race or the team race before the start of the individual race or the team race.

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

[0483] The information processing program for executing the processes in the above-described embodiment and modified examples may be stored in a computer-readable storage medium and provided as such. Furthermore, a game terminal device including such a storage medium may be provided. Furthermore, the above-described embodiment and modified examples may also be information processing methods for implementing the functions and steps shown in the flowcharts. [Explanation of symbols]

[0484] 1. Player terminal (game terminal) 1000 servers S Information Processing System

Claims

1. A process of placing an auxiliary game medium different from the development target game medium 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 auxiliary game media 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; When the selection operation is input, a process of executing an update process of updating a first parameter linked to the training target game medium; When the selection item in which the auxiliary game medium that satisfies a predetermined condition is placed is selected, a process of executing a predetermined event in accordance with conditions based on the first parameter linked to the development target game medium and a second parameter linked to the auxiliary game medium; a process of displaying, on the selection screen, whether or not the predetermined event can occur in association with the auxiliary game medium arranged in the selection item; An information processing program that causes a computer to carry out the above.

2. The process of executing the predetermined event comprises: increasing the update amount of the first parameter in the update process; The information processing program according to claim 1 .

3. An information processing method performed by one or more computers, The computer a process of placing a supplementary game medium different from the development target game medium 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 auxiliary game media 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; When the selection operation is input, a process of executing an update process of updating a first parameter linked to the training target game medium; When the selection item in which the auxiliary game medium that satisfies a predetermined condition is placed is selected, a process of executing a predetermined event in accordance with conditions based on the first parameter linked to the development target game medium and a second parameter linked to the auxiliary game medium; a process of displaying, on the selection screen, whether or not the predetermined event can occur in association with the auxiliary game medium arranged in the selection item; An information processing method for carrying out the above.

4. An information processing system comprising one or more computers, The computer a process of placing a supplementary game medium different from the development target game medium 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 auxiliary game media 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; When the selection operation is input, a process of executing an update process of updating a first parameter linked to the training target game medium; When the selection item in which the auxiliary game medium that satisfies a predetermined condition is placed is selected, a process of executing a predetermined event in accordance with conditions based on the first parameter linked to the development target game medium and a second parameter linked to the auxiliary game medium; a process of displaying, on the selection screen, whether or not the predetermined event can occur in association with the auxiliary game medium arranged in the selection item; An information processing system that carries out the above.