Non-transitory computer-readable storage medium, game processing method, and

Abstract

To enhance motivation to play a training part.SOLUTION: A non-transitory computer-readable storage medium having stored therein a game program of a game including a first part for updating data associated with one assembly including a plurality of components and a second part using the assembly updated by the first part, the game program causing a computer to execute, in the first part, A game program causing a computer to execute a step of updating data associated with an aggregate, a step of managing data of the updated aggregate in response to an end of a first part, and a step of performing processing using the managed aggregate based on the updated data in a second part, wherein the data of the updated aggregate managed by the managing step is not updated again.SELECTED DRAWING: Figure 25

Description

[Technical Field]

[0001] The present invention relates to a game program, a game processing method, and a game device. [Background technology]

[0002] A game program is known that executes game processing including a training part in which components (e.g., game characters) included in a group (e.g., a team) are trained, and a battle part in which a group formed using multiple components trained in the training part is used to play a battle (see, for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2016-163679 Summary of the Invention [Problem to be solved by the invention]

[0004] In the past, components (e.g., game characters) were developed one by one, and by simply completing the development of many components, a powerful group (e.g., a team) could be created. However, on the other hand, the development part was not very difficult, making gameplay monotonous and reducing motivation to play the development part.

[0005] One of the objectives of some aspects of the present invention is to provide a game program, a game processing method, and a game device that increase motivation to play the training part.

[0006] Another aspect of the present invention aims to provide a game program, a game processing method, and a game device that are capable of achieving the effects described in the embodiments described below. [Means for solving the problem]

[0007] In order to solve the above-mentioned problems, one aspect of the present invention is a game program for a game including a first part that updates data associated with an aggregate consisting of multiple components, and a second part that uses the aggregate updated by the first part, the game program causing a computer to execute the steps of: updating the data associated with the aggregate in the first part; managing the data of the aggregate whose update has been completed in response to the end of the first part; and performing processing using the managed aggregate in the second part based on the updated data, and the data of the aggregate whose update has been completed and managed in the managing step is not updated again.

[0008] Furthermore, one aspect of the present invention is a game processing method executed by a computer based on a game program for a game including a first part that updates data associated with an aggregate consisting of a plurality of components, and a second part that uses the aggregate updated by the first part, the game processing method including: in the first part, a step of updating data associated with the aggregate; a step of managing the data of the aggregate whose update has been completed in response to the end of the first part; and a step of performing processing using the managed aggregate based on the updated data in the second part, wherein the data of the aggregate whose update has been completed and managed by the managing step is not updated again.

[0009] Furthermore, one aspect of the present invention is a game device that executes a game program for a game including a first part that updates data associated with an aggregate consisting of a plurality of components, and a second part that uses the aggregate updated by the first part, and the game device comprises: an update unit in the first part that updates the data associated with the aggregate; a management unit that manages the data of the aggregate whose update has been completed in response to the end of the first part; and a processing unit in the second part that performs processing using the managed aggregate based on the updated data, and the data of the aggregate whose update has been completed and that is managed by the management step is not updated again. [Brief explanation of the drawings]

[0010] [Figure 1] 1 is a flowchart showing the overall flow of a game according to an embodiment. [Figure 2] FIG. 4 is a diagram showing an example of a home screen. [Figure 3] FIG. 10 is a diagram showing an example of a character list screen. [Figure 4] FIG. 10 is a diagram showing an example of a character details screen. [Figure 5] A diagram showing the process flow of the training part. [Figure 6] FIG. 10 is a diagram showing an example of a high school selection screen. [Figure 7] A diagram showing the training period and the increase or decrease in the number of members. [Figure 8] FIG. 10 is a diagram showing turns during the development period. [Figure 9] FIG. 10 is a diagram showing an example of an event screen when an event occurs. [Figure 10] FIG. 10 is a diagram showing an example of an event occurrence schedule. [Figure 11] FIG. 10 is a diagram showing an example of a director menu screen. [Figure 12] FIG. 4 is a diagram illustrating an example of character data. [Figure 13] FIG. 10 is a diagram showing an example of a practice menu screen. [Figure 14] FIG. 10 is a schematic diagram illustrating a change in an update condition according to a tentative selection. [Figure 15] FIG. 10 is a diagram showing an example of a mission screen. [Figure 16] FIG. 10 is a diagram showing an example of a supervisor skill screen. [Figure 17] FIG. 10 is a diagram showing an example of a teaching screen. [Figure 18] FIG. 10 is a diagram showing an example of a teaching character selection screen. [Figure 19] A diagram showing an example of the development situation at each high school. [Figure 20] FIG. 10 is a diagram showing an example of usage settings for competing teams. [Figure 21] FIG. 10 is a diagram showing an example of a usage setting screen for setting usage of a competition team. [Figure 22] FIG. 10 is a diagram showing an example of an order setting screen for setting team orders. [Figure 23] FIG. 1 is a block diagram showing an example of the configuration of a game system according to an embodiment. [Figure 24] FIG. 2 is a diagram showing an example of the hardware configuration of a game terminal according to an embodiment. [Figure 25] FIG. 2 is a diagram showing an example of the functional configuration of a game terminal according to an embodiment. [Figure 26] FIG. 4 is a diagram showing an example of character data stored in a storage unit. [Figure 27] FIG. 4 is a diagram showing an example of owned character data stored in a storage unit. [Figure 28] FIG. 4 is a diagram showing an example of high school data stored in a storage unit. [Figure 29] FIG. 4 is a diagram showing an example of development data stored in a storage unit. [Figure 30] FIG. 4 is a diagram showing an example of team data stored in a storage unit. [Figure 31] FIG. 4 is a diagram showing an example of team member data stored in a storage unit. [Figure 32] 10 is a flowchart showing an example of a training part process according to an embodiment. [Figure 33] 10 is a flowchart showing an example of a process for setting a target to be raised according to the embodiment. [Figure 34] 10 is a flowchart showing an example of one turn processing according to the embodiment. [Figure 35] 10 is a flowchart showing an example of a practice process according to the embodiment. [Figure 36] 10 is a flowchart showing an example of a training target change process according to the embodiment. [Figure 37] 10 is a flowchart showing an example of a battle part process according to the embodiment. [Figure 38] 10 is a flowchart showing an example of a usage setting process according to the embodiment. [Figure 39] 10 is a flowchart showing an example of an enhancement item process according to the embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. [1. Game Overview] First, an overview of an example of a game executed in the game system according to this embodiment will be described. The game according to this embodiment is a game played using a plurality of characters. Characters are game characters such as people, animals, and objects (e.g., vehicles) that appear in the game, and are displayed as images (character images) on the game screen. Specifically, the example of the game according to this embodiment is a baseball game that includes a training part and a competition part.

[0012] The development part is a game part in which a baseball team composed of characters corresponding to multiple players is developed on a team-by-team basis. In the development part, the team can be developed by improving the abilities of the characters included in the team. For example, in the development part, a user organizes a development team including multiple characters and has the characters practice while progressing through a scenario. This improves the abilities of the multiple characters included in the development team, thereby strengthening the team. Below, as an example of a scenario in the development part, a scenario will be described in which a user, as a coach or other instructor, coaches (develops) a high school baseball team (development team) over a predetermined period (e.g., two and a half years) and aims to win a baseball tournament. Note that the scenario is not limited to one related to a high school baseball team; for example, it may be related to a university or corporate baseball team or a professional baseball team. In the example game according to this embodiment, multiple scenarios with different content are provided for each type of high school where the user plays the development part as a coach, and the user can freely select a scenario to apply to the development part. On the other hand, the battle part is a game part in which the team trained in the training part (i.e., a team including a plurality of characters whose abilities have been improved in the training part) is used to play a baseball game against an opposing team. For example, a battle is played between the teams trained by the user and another user in the training part.

[0013] 1 is a flowchart showing the overall flow of the game according to this embodiment. When the game starts, the screen transitions to the home screen (step S1). The home screen is a screen that displays a home image corresponding to the main menu that is the starting point of this game.

[0014] 2 is a diagram showing an example of a home screen. The illustrated home screen G100 displays icons P110, P120, P130, P140, P150, and P160, each of which functions as an operator that accepts a user operation. Each icon is an image displayed as part of the home image. Each icon is associated with a process that is executed in response to the acceptance of the operation, and displays content (text, image, etc.) corresponding to the associated process.

[0015] Icon P110 displays "Training" and is associated with a process for starting play of the training part. When an operation for selecting icon P110 is performed (step S11 in FIG. 1: YES), the processing for the training part is executed (step S13 in FIG. 1).

[0016] Icon P120 displays "Match" and is associated with a process for starting the battle part of the game. When an operation for selecting icon P130 is performed (step S21 in FIG. 1: YES), the battle part of the game is executed (step S23 in FIG. 1).

[0017] Icon P130 displays "Character List" and is associated with a character display process for displaying an owned character list image showing a list of owned characters. An owned character is a character owned by the user. The user can acquire (own) a character through an in-game lottery or as the game progresses (for example, by winning a match or by playing the game a predetermined number of times). Owned characters can be used to set a team to be developed in the development part. When an operation to select icon P130 is performed (step S31: YES in FIG. 1), a process for displaying an owned character list image is executed (step S33 in FIG. 1).

[0018] Icon P140 displays "My Team" and is associated with team processing that displays information (images) about the team, etc., that the user developed in the development part and performs various settings for the team. When an operation to select icon P140 is performed (step S41: YES in FIG. 1), team processing is executed, and the screen transitions to a team menu screen that displays information (images) about the team and options for configuring settings for the team (step S43 in FIG. 1). For example, "My Team" can display team information such as information about the team's members (characters developed in the development part) and the team's match results. A user can develop (own) multiple teams by performing the development part multiple times. In "My Team," the user can also set the team to be used in a match from among the multiple teams owned by the user and, for each owned team, set the order of the team members who will participate in the match. For example, the team menu screen displays a team menu image that displays information about the team's members, settings for the team to be used in a match (usage settings), and options for selecting order settings, etc.

[0019] Icon P150 displays "lottery" and is associated with a lottery process in which a character to be acquired by the user is determined by lottery. When an operation to select icon P150 is performed (step S51: YES in FIG. 1), the screen transitions to a lottery screen for conducting a lottery (step S53 in FIG. 1). In the lottery process, at least one character is selected by lottery from a plurality of predetermined types of characters, and the selected character is added as a character owned by the user. For example, the lottery is conducted in exchange for consuming game value (or in-game coins, medals, points, tickets, items, etc. acquired as the game progresses). Note that in-game coins, points, tickets, items, etc. may be acquired by the user as the game progresses, or may be acquired by paying a fee.

[0020] Icon P160 displays "Shop" and is associated with a purchase process for purchasing (obtaining) items, etc. by consuming game value such as coins, medals, points, etc. When an operation for selecting icon P160 is performed (step S61 in FIG. 1: YES), the screen transitions to a purchase screen for purchasing (obtaining) items, etc. (step S63 in FIG. 1).

[0021] If no operation to select an icon is performed (steps S11, S21, S31, S41, S51, S61 in FIG. 1: NO), the home screen will remain displayed, and the game will end when the conditions for ending the game are met (for example, when an operation to end the game is performed) (step S71 in FIG. 1: YES).

[0022] 3 is a diagram showing an example of a character list screen. The illustrated character list screen G200 is a screen that displays a list of owned characters when an operation to select the icon P130 is performed. On the character list screen G200, character images of the characters owned by the user are displayed side by side in a character list R201. When one of the character images displayed in the character list R201 is selected and an operation is performed on the icon P201 displaying "Confirm," detailed information about the character of the selected character image is displayed. Note that when an operation is performed on the icon P202 displaying "Back," the character list screen G200 transitions to the home screen G100 (returns).

[0023] FIG. 4 is a diagram showing an example of a character detail screen. The illustrated character detail screen G210 is a screen on which a character detail image showing detailed information about a character selected on the character list screen G200 shown in FIG. 3 is displayed. Here, the "Fielder Ability" tab is selected, and therefore information about fielder ability from the detailed information is displayed. In the illustrated example, a character image R210, a character name (character name) R220, a fielding position R230, basic information R240, ability parameters R250, and special abilities R260 are displayed. The basic information R240 displays the character's performance (batting average, number of home runs, RBIs), form (batting form), and information indicating the character's dominant hand (for example, "right-handed pitcher, left-handed batter").

[0024] The ability parameters R250 displays the character's basic abilities, such as trajectory, hitting, power, running ability, arm strength, defensive ability, and catching ability. The parameters are expressed as a numerical value indicating each ability and an alphabet (for example, S, A, B, C, D, E, F, G) indicating the rank (level) of the ability corresponding to the numerical value. "S" indicates the highest rank of ability, followed by A, B, C, D, E, and F, in descending order, and "G" indicates the lowest rank of ability.

[0025] The higher the value of the trajectory parameter, the higher the ball will fly. The higher the value of the contact parameter, the higher the contact ability (the ability to hit the ball thrown by the pitcher with the bat). The higher the value of the power parameter, the higher the power (the ability to hit the ball thrown by the pitcher with the bat and make it fly farther). The higher the value of the running ability parameter, the faster the runner. The higher the value of the shoulder strength parameter, the faster the throw. The higher the value of the defensive ability parameter, the better the defense. The higher the value of the catching parameter, the better the catching (less likely to make errors).

[0026] The special abilities R260 display the special abilities possessed by the character. In the example shown, "power hitter," "wide-angle batting," and "steal bases" are displayed as the special abilities possessed by the character. "Power hitter" is a special ability that enhances the ability to hit the ball farther when hitting it with a bat after it has been thrown by the pitcher. "Wide-angle batting" is a special ability that enhances the ability to hit the ball to the side. "Steal bases" is a special ability that makes it easier to successfully steal bases.

[0027] By switching tabs using the right (R) arrow icon P210 or the left (L) arrow icon P211, you can switch the display from "Fielder Ability" to "Player Ability," "Pitcher Ability," "Defense / Use," and "Profile." "Player Ability" refers to the character's abilities as a player. For fielders, information based on "Fielder Ability" is displayed, while for pitchers, information based on "Pitcher Ability" is displayed. For pitchers, "Pitcher Ability" displays information about the pitcher (pitching form, suitability as a starter / closer, basic ability parameters (pitch speed, control, stamina, etc.), acquired special abilities, etc.). "Defense / Use" displays defensive position, basic ability parameters (running speed, arm strength, defensive ability, etc.), and usage. "Profile" displays the character's profile information set in the game, such as their name, birthday, age, and number of years as a professional. Furthermore, when an operation is performed on the icon P220 displaying "Back," the screen transitions from the character detail screen G210 to the character list screen G200 (Back).

[0028] [2. Development Part] Next, the training part will be explained in detail. The training part updates data associated with a team consisting of multiple characters (for example, ability parameters of the characters included in the team) to strengthen the team's fighting power (abilities), and is broadly divided into three steps: "setting the training target," "training," and "reflecting the training results." Hereinafter, the team to be trained (related data updated) in the training part will be referred to as the "training target team," and the characters included in that team will be referred to as the "training target characters."

[0029] FIG. 5 is a diagram showing the process flow of the training part. First, in "Setting the Training Target," the high school (scenario) of the training target team to be trained is selected, and multiple training target characters are set as members of the training target team (step S100). After setting the members (training target characters), the system proceeds to "Training" of the training target team. In "Training," one turn including a manager menu (an opportunity to give instructions to train the training target team from the manager's perspective) is repeatedly executed until a termination condition is met (step S110). An example of the termination condition is the end of the training period. When the termination condition is met (step S140: YES), the system proceeds to "Reflecting the Training Result," where the training result of the training target team (hereinafter referred to as the "trained team," and the training target characters included in the trained team are referred to as the "trained characters") is saved, completing the training part. Thereafter, the saved trained team can be used to play against trained teams of other users. Each of the steps of "Setting the Training Target," "Training," and "Reflecting the Training Result" is described in detail below.

[0030] [2-1. Setting up training targets] First, the user selects the high school (scenario) of the team to be developed. Note that initially, there may be only one high school, but later, the user may be able to select from multiple high schools. 6 is a diagram showing an example of a high school selection screen. Here, it is assumed that a scenario related to a baseball team at a certain high school is executed in the development part, and multiple high schools (High School A, High School B, High School C, High School D, and High School E) are displayed as options. The illustrated high school selection screen G300 displays icons P311, P312, P313, P314, and P315, which function as operators for selecting each of the multiple high schools (High School A, High School B, High School C, High School D, and High School E). For example, when an operation to select icon P311 is performed, it is determined that High School A (the scenario related to High School A) has been selected.

[0031] When a high school (scenario) is selected, characters to be developed (e.g., eight people, hereinafter also referred to as "high school characters") that are set as characters pre-associated with that high school are set as members of the development team. In addition to the high school characters, the development team includes development characters (e.g., four people, hereinafter also referred to as "optional characters") that are set based on multiple characters selected by the user from among the characters owned by the user, and multiple other development characters (e.g., 15 people, hereinafter also referred to as "extra characters"). For example, the extra characters are set by randomly selecting from multiple predetermined extra characters based on probability information, etc. A team consisting of the high school characters, optional characters, and extra characters is set as the development team in the development part.

[0032] Each character, including high school characters, optional characters, and extra characters, has a parameter for their school year, and their school year changes as the training period in the training part progresses. Here, as an example of training a high school baseball team, the training period in the training part is set to a period of two and a half years in the game (members (characters) who join the team as first-year students graduate in the fall of their third year). The training period for characters set as members in the training part differs depending on their school year and the time of joining and graduating.

[0033] 7 is a diagram showing the training period and the increase or decrease in the number of members (characters to be trained) in the training part. As shown in the figure, the training period of the characters to be trained set as members is classified into the following (a) to (d) depending on the school year and the time of joining and graduating from the club. (a) Join the club as a first-year student at the start of the development period and graduate in the fall of the third year of the development period. (b) Since he / she is a second-year student at the start of the development period, he / she will graduate in the fall of the second year of the development period. (c) Since he is a third-year student at the start of the development period, he will graduate in the fall of the first year of the development period. (d) Join the club as a first-year student in the spring of the second year of the development period and finish in the fall of the third year of the development period. (e) Join the club as a first-year student in the spring of the third year of the development period and finish in the fall of the third year of the development period.

[0034] At the start of the training part, the user can only select characters with first-year attributes from among the characters owned by the user, and an optional character (character to be trained) is set based on the selected character. Furthermore, at each stage of the training period, in the spring of the second year and the spring of the third year, the user is given the opportunity to re-select a character with first-year attributes from among the characters owned by the user at each stage. Upon the end of the training period, a team (trained team) including members who are enrolled at the end of the training period (trained characters) and members who graduated during the training period (trained characters) is saved as the training result. Note that, instead of parameters for the grade level that change as the training period progresses in the training part, the characters owned by the user may have fixed parameters that do not change as the training period progresses (for example, a parameter indicating that the character is selectable at the start of the training part, a parameter indicating that the character is selectable in the spring of the second year of the training period, and a parameter indicating that the character is selectable in the spring of the third year of the training period).

[0035] [2-2. Development] The "training" phase consists of a turn (see Figure 5), which includes three steps: "morning event," "management menu," and "afternoon event." This can be repeated up to 120 times. Note that "morning event" and "afternoon event" do not necessarily occur every turn; they may or may not occur every turn. Figure 8 shows the turns during the training period. A member (character to be trained) joins the team as a first-year student at the start of the training phase (joining the training team) and graduates (ends training) in the fall of their third year. The 120 turns represent two and a half years in the game. One turn corresponds to one week in the game, and four turns correspond to one month in the game, for a total of 4 (weeks) x 12 (months) x 2.5 (years) = 120 turns. The 120 turns include a turn in which a match is played. Losing a match may end the training phase prematurely.

[0036] [2-2-1. Training (Events)] Events ("morning events" and "afternoon events") occur in addition to the predetermined scenarios for each high school. Events include high school-specific (scenario-specific) events, high school-wide (scenario-wide) events, and events involving event characters (hereafter referred to as "event characters"). An event character is a character associated with an event. Each of the high school characters, optional characters, and extra characters set as characters to be developed in the development team described above also possesses the characteristics of an event character. Events occur as the development section progresses, depending on the fulfillment of the conditions for occurrence set for each event (i.e., regardless of the user's will). As a result of an event, various parameters, such as the ability parameters of the members (development characters), change. There are multiple different types of events for each of the high school-specific (scenario-specific) events, high school-wide (scenario-wide) events, and event character events, and the content of each event differs depending on the type of event.

[0037] FIG. 9 is a diagram showing an example of an event screen when an event occurs. The illustrated event screen G400 shows an example of a "morning event" for the first turn of the training period (first week of April, first year). The event screen G400 displays information R410 indicating the current turn, an event image R420 corresponding to the content of the event, and text information R430 such as lines from characters appearing in the event and words corresponding to the event content. Each event functions as the smallest story element constituting the scenario in the training part, and the story is expressed by displaying an event image R420 related to the above-mentioned characters, the character's lines, and text information R430 such as words corresponding to the event content. Note that some events require the user to select options, and the outcome of the event may vary depending on the result of that selection.

[0038] Events are divided into scenario events (events specific to a high school (scenario-specific) or events common to all high schools (scenario-wide)) and event character events (events by event characters). Scenario events occur when predetermined conditions for the scenario applied to the training part are met. For example, a scenario event may have a predetermined event occurrence schedule, and the condition for the occurrence may be reaching a specific number of turns. Figure 10 is a diagram showing an example of an event occurrence schedule. For example, the timing of event occurrence is set as follows: Event X in the morning of the second week of April in the first year, Event Y in the afternoon of the fourth week of April in the first year, ... Event Z in the afternoon of the third week of September in the third year. When the set turn is reached, the set event occurs.

[0039] An event character event occurs when a predetermined occurrence condition for each type of event is met. For example, an event character event is associated with an event character (character to be trained) included in a training team, and occurs when a specific parameter of the event character (character to be trained) reaches a specific value. The occurrence condition for an event character event may also include reaching a specific number of turns. For example, an event character event may occur when a specific number of turns is reached and a specific parameter reaches a specific value.

[0040] [2-2-2. Development (Manager Menu)] In the manager menu, the user selects the action (item) for the user's role as manager each turn. For example, the options include "Practice," "Construction," "Mission," "Manager Skills," and "Instruction." The options are as follows: "Practice" instructs the training team to practice; "Construction" consumes dedicated points to construct buildings and level up the buildings that have been constructed; "Mission" allows the user to check the development status (level of growth) of each character (event character) to be trained, and the occurrence status of events corresponding to each character (event character) to be trained; "Manager Skills" consumes manager points to improve managerial ability (coaching skill); and "Instruction" consumes items to improve the abilities of the character (event character) to be trained.

[0041] FIG. 11 is a diagram showing an example of a manager menu screen G500. The illustrated manager menu screen G500 displays information R510 indicating the current time (current turn) in the training part (here, "first week of July, year 1"), information R520 indicating the period until the turn in which a game against another team will be played (here, "two weeks until the game"), a schedule R530 for the upcoming turn, and the current strength R540 (training status) of the training team. The strength displays letters (e.g., S, A, B, C, D, E, F, G) and a radar chart indicating the rank (level) of the abilities of the entire training team, such as batting power, defensive ability, mobility, pitching speed, control, and curveballs. The rank of each ability is determined according to the training status (ability parameters, etc.) of each member (training character) of the training team. Furthermore, the strength display displays letters (here, "A++") indicating the rank (level) of the overall strength of the entire training team, which is the sum of the ranks of each ability.

[0042] The manager menu screen G500 also displays icons P510, P520, P530, P540, and P550, which function as controls for selecting the content (items) of actions the user will take as a manager. Icon P510 displays "Practice" and is associated with a practice process for instructing the training team to practice. Icon P520 displays "Construction" and is associated with a construction process for constructing buildings by consuming dedicated points and leveling up constructed buildings. Icon P530 displays "Mission" and is associated with a mission process for checking the mission completion status (event occurrence status) of each training target character (event character). Icon P540 displays "Manager Skill" and is associated with a manager skill process for consuming manager points to improve managerial ability (coaching skill). Icon P550 displays "Teach" and is associated with a teaching process for consuming items to improve the abilities of the training target character.

[0043] Note that the steps in the turn only progress when "Practice" is selected, and when the practice process ends, if an afternoon event occurs, the afternoon event will occur and then the current turn will end, and if no afternoon event occurs, the current turn will end. Since the steps in the turn do not progress with selections other than "Practice," you can select any number of times within a single turn. Note that after selecting "Practice," you may be able to cancel the selection of "Practice" and return to a state where you can select other options until you select specific practice content and practice is carried out (the practice process is executed).

[0044] [2-2-2(1). Development (Manager's Menu: Training)] When an icon P510 ("Practice") is selected on the manager menu screen G500 and a practice item (practice content) is instructed (selected), practice processing is executed. In the practice processing, a practice effect according to the practice content instructed (selected) by the user for the training team is obtained by the members (training characters) of the training team. The practice effect is the updating of data associated with the training character (various parameters associated with the training character). For example, as a practice effect, ability parameters indicating the abilities of the training character are updated.

[0045] FIG. 12 is a diagram illustrating an example of character data. The character data (various parameters associated with the character being trained) includes overall data indicating "overall" abilities, basic ability data indicating "basic abilities," and special ability data indicating "special abilities." The overall data includes "experience points" that increase (or decrease) depending on "practice" and "events," and a "level" ability parameter determined depending on the "experience points." The basic ability data includes, for example, pitcher-related abilities, such as "practice points" and "rank" ability parameters for control, stamina, and pitch speed. "Practice points" increase (or decrease) depending on "practice" and "events." "Rank" is represented by an alphabet (e.g., S, A, B, C, D, E, F, G), and increases each time the "practice point" reaches a predetermined value. The "practice point" is reset each time the "rank" increases. The special ability data includes a parameter indicating whether the character being trained has acquired each special ability (presence or absence of acquisition). The parameters of each special ability change from "none" to "yes" through "events" or "teachings."

[0046] For example, "practice" updates the "experience points" and "experience point" parameters of the character to be trained. The practice content specified by the user is prepared in advance so that it can be selected from a plurality of practice items. FIG. 13 is a diagram showing an example of a practice menu screen. The illustrated practice menu screen G600 displays a practice menu image including options for practice items and information indicating the effects of practice. The illustrated practice menu screen G600 is an example of a screen for specifying "pitcher practice." By operating the right (R) arrow icon P610 or the left (L) arrow icon P611, it is possible to switch to another practice such as "fielder practice."

[0047] The practice menu screen G600 displays a practice menu R610 for selecting a practice item to instruct the development team. Here, the practice menu R610 displays icons P631, P632, P633, and P634, which function as controls for selecting a practice item such as "pitcher practice." Icon P631 displays "pitcher speed practice" and is associated with a pitcher speed practice process in which a practice effect is obtained by instructing pitcher speed practice. Icon P632 displays "control practice" and is associated with a control practice process in which a practice effect is obtained by instructing control practice. Icon P633 displays "stamina practice" and is associated with a stamina practice process in which a practice effect is obtained by instructing stamina practice. Icon P632 displays "breaking ball practice" and is associated with a breaking ball practice process in which a practice effect is obtained by instructing breaking ball practice.

[0048] Each practice item icon is associated with an increase in "experience points" as a practice effect, an increase in "practice value" according to the practice content, and one or more characters to be trained (character images). The characters to be trained associated with each practice item are randomly selected from among the members (characters to be trained) of the training team. Note that icons for each practice item may include icons to which no characters to be trained are associated. The number of icons (options) for practice items is less than the total number of characters to be trained included in the training team. By the practice process corresponding to an icon (practice item), the parameter values ​​(experience points and practice value) of the character to be trained associated with the icon are increased based on the experience points and practice value associated with the icon. This increases the ability of the character to be trained and increases the fighting power of the training team. Note that for practice items to which no characters to be trained are associated, the increase in experience points and practice value associated with the practice item is not reflected on any of the characters to be trained.

[0049] Specifically, the "experience points" and "practice values" corresponding to the selected practice item (e.g., "control practice") are multiplied by a value plus alpha and added to the "experience points" and "practice values" of the characters to be trained associated with the practice item (this is called "direct instruction"). On the other hand, for practice items that were not selected (e.g., "pitch speed practice," "stamina practice," and "curve ball practice"), the "experience points" and "practice values" corresponding to each practice item are also added to the "experience points" and "practice values" of the characters to be trained associated with each practice item (no plus alpha is added). In this way, both the characters to be trained associated with the selected practice item and the characters to be trained associated with the non-selected practice items can benefit from the practice effect, but only the characters to be trained associated with the selected practice item have the original set value (a value preset for each practice item) plus a value plus alpha added.

[0050] In the illustrated practice menu screen G600, icon P632 ("Control Practice") is provisionally selected. A provisional selection indicates that the selection has not been finalized and that it is possible to change to the selection of another icon. When an operation to select and confirm is performed from the provisionally selected state, the provisionally selected icon is finalized, and the practice process for the practice item corresponding to that icon is executed. The operation to select and confirm is, for example, an operation on icon P623 on which "Confirm" is displayed. Note that in the case of an operation on a touch panel, the icon may be provisionally selected by a first touch operation on the icon, and the selection of the icon may be finalized by performing a second touch operation on the icon in the provisionally selected state.

[0051] The "experience points" and "practice values" corresponding to the provisionally selected practice item are displayed with a +alpha added value. The "experience points: +232" and "practice values: +82" displayed corresponding to the illustrated icon P632 ("control practice") are values ​​with a +alpha added to the original settings. On the other hand, the "experience points" and "practice values" corresponding to practice items that are not selected are displayed with the original settings without the +alpha added value. For example, the "experience points: +93" and "practice values: +40" displayed corresponding to the icon P631 ("pitch speed practice") are the original settings without the +alpha added value. If the provisionally selected icon is changed from icon P632 ("control practice") to icon P631 ("pitch speed practice"), the "experience points" and "practice values" displayed corresponding to icon P632 ("control practice") are changed to the original settings without the +alpha added value, and the "experience points" and "practice values" displayed corresponding to icon P631 ("pitch speed practice") are changed to the original settings with the +alpha added value.

[0052] The training effect of the above-mentioned "practice" (the "experience points" and "practice values" corresponding to the practice items are added to each character to be trained that corresponds to that practice item) updates data such as parameters that indicate the abilities of the character to be trained. The increase in the "experience points" and "practice values" for each practice item is an example of an "update condition" when data such as parameters that indicate the abilities of the character to be trained is updated by the training effect of "practice." This update condition is not limited to the increase in the "experience points" and "practice values," but may be an increase (amount of increase) of other parameters, or the acquisition of some special ability.

[0053] FIG. 14 is a schematic diagram illustrating changes in update conditions according to a tentative selection. Here, three practice items, Practice A, Practice B, and Practice C, are taken as examples of options, and parameter increments are associated with them as update conditions. In (1), none of the options are tentatively selected, and the update condition for Practice A is "+80," the update condition for Practice B is "+45," and the update condition for Practice C is "+60." These update conditions are the original setting values ​​for each practice item. In (2), Practice A is tentatively selected, so only the update condition for Practice A is changed to a +alpha value ("+80+30"). In (3), the tentative selection is changed from Practice A to Practice B, so the update condition for Practice A returns to the original setting value ("+80"), and only the update condition for Practice B is changed to a +alpha value ("+45+15"). In (4), the provisional selection has been changed from Practice B to Practice C, so the update condition for Practice B is returned to the original setting value ("+45"), and only the update condition for Practice C is changed to a value with +alpha ("+60+20"). Note that the updated update condition may be displayed as a total value after +alpha is applied, as shown in FIG. 13, or the original setting and the +alpha value may be displayed, as shown in FIG. 14.

[0054] Although the example has been described in which the update conditions (parameter increments) of the provisionally selected practice items are increased (added by an alpha) relative to the original set values, the update conditions (parameter increments) of the provisionally selected practice items may remain unchanged, while the update conditions (parameter increments) of the practice items that are not provisionally selected may be decreased relative to the original set values.Furthermore, the update conditions (parameter increments) of the provisionally selected practice items may be increased relative to the original set values, and the update conditions (parameter increments) of the practice items that are not provisionally selected may be decreased relative to the original set values.

[0055] The original set values ​​of "experience points" and "practice points" are determined based on the character to be trained associated with the corresponding practice item and the manager skill (manager ability parameter) corresponding to the practice item. However, in addition to (or independently of) this, they may also be determined based on other factors, such as values ​​based on items acquired during the game or manager skill. Manager skill is one of the parameters associated with a character who plays the role of manager among the members (characters to be trained) of the training team. The update conditions are not limited to the increase in "experience points" and "practice points," but may also be the decrease in these values, or may be conditions indicating addition, deletion, or modification of other data (parameters) associated with the character to be trained.

[0056] Returning to FIG. 13, on the practice menu screen G600, the practice target list R620 displays a list of characters to be trained that are associated with the provisionally selected practice item so that the user can select from them. For a character to be trained selected in this practice target list R620, the mission completion status (event occurrence status) and ability details can be confirmed. When an operation is performed on the icon P620 displaying "Mission Details," the occurrence status of an event corresponding to the character to be trained (event character) selected in the practice target list R620 is displayed. When an operation is performed on the icon P621 displaying "Ability Details," the ability parameters and the like of the character to be trained selected in the practice target list R620 are displayed. When an operation is performed on the icon P622 displaying "Back," the practice menu screen G600 transitions to the manager menu screen G500 (back).

[0057] [2-2-2(2). Development (Manager Menu: Construction)] In "Construction," you can use manager points to build various buildings (for example, training facilities) or level up the buildings you have built. The type of building and construction level affect training effectiveness and managerial skills. Note that "Construction" is a menu specific to the high school (scenario), and may or may not be available depending on the high school. High schools that do not have "Construction" may have a menu that replaces it.

[0058] [2-2-2(3). Training (Manager Menu: Mission)] In "Mission," you can check the mission achievement status (event occurrence status). In other words, you can check how many possible events have occurred. The reason it's called a "Mission" is that in order to further improve the abilities of the characters (event characters) included in the training team in the training part, it is necessary to generate more events, and therefore generating events can be considered a mission imposed on the user in the training part.

[0059] 15 is a diagram showing an example of a mission screen. The illustrated mission screen G700 displays an event occurrence status R710 and detailed event information R720. As mentioned above, events are divided into scenario events and event character events. In the illustrated example, the "Event Character" tab is selected, so the event occurrence status R710 displays the occurrence status of the event character event.

[0060] The event occurrence status R710 displays an event character list R711 and an event list R712. The event character list R711 displays multiple character images of event characters (characters to be developed). Each character image is selectable, and the selected character image displays the character name (here, "Character B1") and is displayed in a manner that makes it distinguishable from other character images. The event list R712 displays a list of event character events associated with the event character indicated by the character image selected in the event character list R711. For example, event character events are initially in a locked state (in the illustration, events #5 and #6) in which events cannot occur, and are associated with a lock symbol. When the event character's level exceeds a certain level, the locked state transitions to an unlocked state (in the illustration, events #2 and #4), and the lock symbol is no longer displayed. The unlocked state is a state in which an event can occur. An unlocked event occurs when a predetermined occurrence condition for that event is further met (for example, a specific parameter of the event character reaches a specific value). Additionally, "Achieved!" is displayed for events that have already occurred (event #1 and event #3 in the illustration).

[0061] The event list R712 also displays detailed information about a selected event character event from the event character events displayed in the event character list R711. In the illustration, event #2 is selected, so explanatory information R721 about the contents of event #2, the conditions R722 for the occurrence of event #2, and reward information R723 that can be obtained from event #2 are displayed.

[0062] Furthermore, if you switch the tab from "Event Character" to "Scenario" by operating the right (R) arrow icon P710 or the left (L) arrow icon P711, the content displayed in the event occurrence status R710 will change from the occurrence status of an event character event to the occurrence status of a scenario event.

[0063] [2-2-2(4). Training (Manager Menu: Manager Skills)] In "Manager Skills," you can improve (acquire) manager skills (coaching skills as a manager) by spending manager points. For example, manager skills include skills for teaching fastball pitchers, skills for teaching finesse pitchers, and skills for teaching batting. As manager skills improve (acquire), the effectiveness of practice items corresponding to the manager skill type in the "Practice" menu improves.

[0064] FIG. 16 is a diagram showing an example of a manager skill screen. The manager skill screen G800 shown in the figure displays a skill list R810 for selecting a manager skill. The skill list R810 displays a number of pre-set manager skills. Manager skills can also be in a locked or unlocked state. Unlocked manager skills (skills #1, #3, #5, #6, #7, and #8 in the figure) are selectable. Locked manager skills (skills #2 and #4 in the figure) are grayed out and cannot be selected. For example, when the manager's level exceeds a certain level, the locked state changes to an unlocked state and the skill becomes selectable. Each manager skill also displays the number of manager points consumed in exchange for improving (acquiring) that can be achieved. A manager skill for which the available manager points are insufficient (skill #9 in the figure) is grayed out and cannot be selected, without displaying a lock symbol.

[0065] From the multiple manager skills displayed in the skill list R810, select the manager skill you want to improve (acquire), and by operating the icon P820 displaying "Confirm," you can improve (acquire) the selected manager skill by consuming manager points. If you operate the icon P821 displaying "Back," you will transition (return) from the manager skill screen G800 to the manager menu screen G500.

[0066] [2-2-2(5). Development (Manager Menu: Teaching)] In "Teaching," you can improve the abilities of any player (character being trained) by consuming items. Items are classified into five types: "Level Experience Points," "Tips" for fielders and pitchers, and "Practice Points." "Level Experience Points" increase the "Experience Points" (and "Level" depending on the "Experience Points") of the character being trained. "Tips" are items that grant special abilities to the character being trained. "Practice Points" increase the "Practice Points" of the character being trained. "Tips" (special abilities) have ranks (e.g., S, A, B, C, D, E, F, G), and their effects change in stages.

[0067] FIG. 17 is a diagram showing an example of a teaching screen. The teaching screen G900 shown in the figure displays a teaching image for selecting an item to be taught. In the teaching screen G900, the items to be "taught" are displayed by type in the teaching item list R901 by switching tabs. In the example shown in the figure, the "Fielder Tips" tab is selected, and "Tips" (special abilities) items for fielders and the number of items possessed are displayed. Teaching is possible for the number of items possessed. By switching tabs using the right (R) arrow icon P901 or the left (L) arrow icon P902, item lists for "Pitcher Tips" ("Tips" for pitchers), "Fielder Practice Values" ("Practice Values" for fielders), "Pitcher Practice Values" ("Practice Values" for pitchers), and "Level Experience Points" can be displayed in the teaching item list R901.

[0068] In the illustrated example, "Chance," an item for "Knack" (special ability) for fielders, is selected. "Chance" is a special ability that increases the ability parameters of basic abilities when a chance occurs, making players stronger in chance situations. By operating the icon P903 displaying "Confirm," the screen transitions to a teaching character selection screen, where the player can select which character to train to grant the selected "Chance." Note that, if the icon P904 displaying "Back" is operated, the screen transitions from the teaching screen G900 to the manager menu screen G500 (back).

[0069] FIG. 18 is a diagram showing an example of a teaching character selection screen. The illustrated teaching character selection screen G910 displays an image for selecting a character to be trained to which the item selected on the teaching screen G900 is to be imparted. In the teaching character selection screen G910, a character selection list R911 displays multiple character images as options. The character images to be displayed may be determined according to the type of selected item. For example, in the case of an item for a fielder, a fielder character to be trained may be prioritized, and in the case of an item for a pitcher, a pitcher character to be trained may be prioritized. Also, in the case of an item for a fielder, only character images of the fielder may be displayed, and in the case of an item for a pitcher, only character images of the pitcher may be displayed. In the illustrated example, "character B1" is selected. By operating the icon P911 displaying "OK," the special ability related to "chance" selected as the item to be taught is imparted to the selected "character B1." When an operation is performed on the icon P912 displaying "Back", the screen transitions from the teaching character selection screen G910 to the teaching screen G900 (Back).

[0070] [2-3. Reflecting the results of training] When the training part ends and the "training" of the training target team is completed, the training target team, consisting of the members (trained characters) enrolled in the training target team at the time of completion and members (trained characters) who graduated during the training period, is saved as a trained team. The saved data of the trained team and the trained characters included in the trained team is updated data that reflects the training results of the "training" in the training part. Multiple trained teams can be saved for each high school (scenario). Figure 19 is a diagram showing an example of the training status for each high school. In the illustrated example, three trained teams are saved as a result of completing the training part three times at High School A (scenario related to High School A), there is no training part at High School B (scenario related to High School B), and four trained teams are saved as a result of completing the training part four times at High School C (scenario related to High School C). The saved trained teams can be used to play against other users' trained teams. If multiple trained teams are saved, one team (trained team) selected from them can be used in a match.

[0071] [3. Setting up the teams for the match] One of the trained teams for each high school (scenario) developed in the training part can be designated for use in the match part. By designating the team (trained team) to be used in each match before playing the match part, it is convenient because it is not necessary to select the team (trained team) to be used in each match. Here, the setting for designating the team (trained team) to be used in a match before playing the match part is referred to as the "usage setting." Because matches in the match part are conducted asynchronously, the team (trained team) set for use by the matched user will be used in the match, allowing the user's intention to be reflected in the selection of the team (trained team) to be used in the match. Furthermore, a default team is prepared and configured for use for each high school before the training part is implemented. Therefore, for high schools with no training history (no history of implementing the training part), the default team can be used in matches. However, the default team is generally at a disadvantage in terms of ability compared to the trained team developed in the training part.

[0072] FIG. 20 is a diagram showing an example of how to set up teams for use in a match. The illustrated example corresponds to the example of the training status for each high school (scenario) shown in FIG. 19 and shows teams that can be set up for use. High School A (scenario related to High School A) has three trained teams (teams #1, #2, and #3) that were developed through the training part, so any of these three teams can be set up for use. High School B (scenario related to High School B) has no training history through the training part, so only the default team can be set up for use. For high schools (scenarios) that only have a default team, the default team may be set up for use in advance. High School C (scenario related to High School C) has four trained teams (teams #1, #2, #3, and #4) that were developed through the training part, so any of these four teams can be set up for use. In the illustrated example, Team #2 is set up for use as the team (trained team) to be used in a match at High School A (scenario related to High School A), the default team at High School B (scenario related to High School B), and Team #3 at High School C (scenario related to High School C). In addition, for each team, the team members (trained characters) are divided into an order consisting of members who will play in the match and the rest. The order is divided into a starting order and a bench (reserve). Members (trained characters) can be freely replaced at any time.

[0073] FIG. 21 is a diagram showing an example of a usage setting screen for setting the usage of a competition team. The usage setting screen G1000 shown in the figure is displayed when an operation to select icon P140 ("My Team") on the home screen G100 shown in FIG. 2 is performed and then an operation to select "Usage Settings" is performed on the team menu screen that is displayed. The usage setting screen G1000 displays "Current Team" information R1010 indicating the team currently set for usage (trained team), and "Replacement Team" information R1020 indicating the team to be newly set for usage in place of the team currently set for usage. In the example shown in the figure, the "Current Team" information R1010 indicates that team #1 from A High School (a scenario related to A High School) is set for usage. Meanwhile, the "Replacement Team" information R1020 displays teams #2 and #3 from the same A High School (a scenario related to A High School) as replacement candidates. Note that if there is only one replacement candidate team, only that one team is displayed as a candidate; if there is no other replacement candidate (if there is only one team from that high school (scenario)), no candidates are displayed.

[0074] When an operation is performed to select a new team (trained team) to be set as a usage setting from among the teams (trained teams) displayed in the "Team to Replace" information R1020, and an operation is performed on the icon P1010 displaying "Swap," the team displayed in the "Current Team" information R1010 and the team displayed in the "Team to Replace" information R1020 are swapped. Then, when an operation is performed on the icon P1011 displaying "OK," the change in usage setting is confirmed. On the other hand, when an operation is performed on the icon P1012 displaying "Cancel," the team displayed in the "Current Team" information R1010 and the team displayed in the "Team to Replace" information R1020 are returned to their original state before the swap.

[0075] Additionally, the high school selection screen R1030 displays icons corresponding to each high school (scenario), and by selecting one of these icons, the high school for which usage settings are to be performed can be switched. Note that when an operation is performed on the icon P1013 displaying "Back," the usage settings screen G1000 transitions to the team menu screen (Back).

[0076] 22 is a diagram showing an example of an order setting screen for setting the order of a team (trained team). The illustrated order setting screen G1100 displays an order member list R1110 and an off-bench member list R1120. The order member list R1110 distinguishes between the nine regular (starting order) members (trained characters) and the nine bench members (trained characters). The off-bench member list R1120 displays five off-bench members (trained characters) who are not on the order.

[0077] For example, if you want to change a regular member, select the regular member you want to change in the order member list R1110 and operate the icon P1110 marked "Change." This allows you to select the member you want to change from the list of bench members. Then, select the member you want to change from the list of bench members and operate the icon P1111 marked "OK." The selected regular member will be swapped with the selected bench member. Also, if you want to add a member not on the bench to the order, select the member not on the bench you want to add to the order in the not on the bench member list R1120 and operate the icon P1110 marked "Change." This allows you to select a member to remove from the order instead from the order member list R1110. Then, select the member you want to remove from the order from the order member list R1110 and operate the icon P1111 marked "OK." The selected order member will be swapped with the not on the bench member. In this way, in a trained team, members (trained characters) can be freely swapped between regular (starting order) members, bench members, and off-bench members at any time. However, members cannot be swapped across teams (training teams), and members (trained characters) cannot be moved (swapped) from one team (trained team) to another team (trained team).

[0078] [4. Matchup (matching opponent teams)] In the match part, when a user instructs a match against another team (for example, by operating icon P120 ("Match") on the home screen G100 shown in FIG. 2), a match with an opponent is performed. In the match, teams (trained teams) of users with similar overall strength are matched. The overall strength is calculated as the sum of the overall strengths (total strength) of teams set for use in matches for each high school (scenario). For example, in the example shown in FIG. 20, the sum of the overall strength (total strength) of Team #2 from High School A, the overall strength (total strength) of the default team from High School B, and the overall strength (total strength) of Team #3 from High School C is used as the user's overall strength for matching. For example, when a user instructs a match, multiple other users with overall strengths similar to the user's overall strength (within a range of the user's overall strength ± a predetermined value) are extracted as candidates for the user's opponent. The user can arbitrarily select an opponent from the extracted multiple other users, and a match will be held between the user's team and the opponent's team. The overall strength (total combat power) of a team is calculated (e.g., summed) based on, for example, the ability parameter values ​​of the members (each trained character) included in the team. The overall strength (total combat power) of a team is preferably calculated based on the ability parameter values ​​of all members (trained characters) included in the team, but may also be calculated based on the ability parameter values ​​of only the members (trained characters) included in a specific group, such as order members. Once the opponent user is determined through matching, a match is played between the determined opponent user and the teams set up to use at the same high school (scenario). The high school (scenario) to which the teams used in the match belong is determined in advance, regardless of the user's selection. Therefore, even if another user has an overall strength similar to that of the user, the overall strength of the teams set up to use at the determined high school (scenario) is not necessarily similar. Therefore, in order to gain an advantage in the match regardless of which high school is determined for the match, it is necessary to train strong teams in the training part at all high schools.

[0079] [5. Game System Configuration] Next, the configuration of the game system 1 according to this embodiment will be described. 23 is a block diagram showing an example of the configuration of a game system 1 according to this embodiment. The game system 1 is made up of a plurality of terminal devices 10-1, 10-2, ..., 10-n (n is a natural number) and a server device 30, and these devices are connected via a communication network NW. Because the terminal devices 10-1, 10-2, ..., 10-n have the same configuration, they will be described simply as terminal device 10 unless otherwise distinguished.

[0080] The terminal device 10 functions as a game device by executing a game control program. For example, the terminal device 10 is a computer device used by a user, and may be a game console, a PC (Personal Computer), a tablet PC, a mobile phone such as a smartphone or a feature phone, or the like.

[0081] The server device 30 manages game data and game control programs required to execute the game control programs on the terminal devices 10. For example, the server device 30 is a computer device managed by a game management company and can be considered a system composed of multiple server machines, storage, network switches, routers, firewalls, etc. The game data managed by the server device 30 is used when the game control programs are executed on the terminal devices 10, or is transmitted to the terminal devices 10 in advance for use. The game data also includes advertising data (information about other games) displayed during the game. For example, images displayed on the screen of the terminal devices 10 are part of the game data. The game control programs managed by the server device 30 include some game control programs. Game control programs include not only those downloaded to the terminal devices 10 before the game starts, but also those downloaded to the terminal devices 10 after the game starts. Note that the game control programs downloaded to the terminal devices 10 before the game starts may be managed not by the server device 30 but by a server device that distributes programs running on the terminal devices 10.

[0082] [5-1. Hardware configuration of game terminal] Next, the configuration of the terminal device 10 according to this embodiment will be described in detail. FIG. 24 is a diagram showing an example of the hardware configuration of a terminal device 10 according to this embodiment. The terminal device 10 includes, for example, a communication unit 11, an input unit 12, a display unit 13, an audio output unit 14, a storage unit 15, and a CPU (Central Processing Unit) 16. A general-purpose smartphone can be used as the terminal device 10, and no special hardware is required to execute the game control program as long as the CPU's processing power is not an issue. In other words, as long as a program appropriately created to match the hardware configuration of the terminal device 10 on which the game control program is executed is used, some of the hardware configuration may differ from that of this embodiment.

[0083] The communication unit 11 is a device that performs communication in accordance with the communication standards of a communication network NW, such as a wireless LAN, a wired LAN, or a mobile communication (LTE), that allows the terminal device 10 and the server device 30 to communicate with each other.

[0084] The input unit 12 is a device capable of receiving interactive information while a game is being played. The interactive information is, for example, information about a user's operation on the terminal device 10. Examples of the input unit 12 include physical devices that are mechanically operated, such as buttons, keyboards, and levers, pointing devices using a GUI (mouse or touch panel), and recognition devices that use voice or gestures (microphone, camera). The input unit 12 may be configured integrally with the terminal device 10, or may be configured as a separate entity connected by wire or wirelessly. The input unit 12 outputs an operation signal input based on the operation.

[0085] The display unit 13 is a display that displays information such as images and text, and is configured to include, for example, a liquid crystal display panel, an organic EL (ElectroLuminescence) display panel, etc. The display unit 13 may be configured as a separate unit from the terminal device 10, and may be, for example, a television, an external monitor, or a head-mounted display (HMD).

[0086] The audio output unit 14 includes, for example, a speaker, an audio output terminal for outputting audio to headphones, and the like.

[0087] The storage unit 15 includes, for example, a hard disk drive (HDD), a solid state drive (SSD), an electrically erasable programmable read-only memory (EEPROM), a read-only memory (ROM), a random access memory (RAM), etc., and stores various types of information, images, programs, etc. used for processing by the terminal device 10. Note that the storage unit 15 is not limited to being built into the terminal device 10, and may be an external storage device connected via a digital input / output port such as a USB.

[0088] The CPU 16 executes various programs stored in the storage unit 15 and controls each unit of the terminal device 10. The CPU 16 is an example of a processor that executes processing in the terminal device 10.

[0089] The terminal device 10 may be configured to include a camera, a gyro sensor, and a GPS (Global Positioning System) chip, none of which are shown.

[0090] [5-2. Functional configuration of game terminal] Fig. 25 is a diagram showing an example of the functional configuration of the terminal device 10 according to this embodiment. In this diagram, a data storage unit 150 and a control unit 160 are shown as the functional configuration of the terminal device 10. The data storage unit 150 is a functional configuration corresponding to the storage unit 15 shown in Fig. 24. The control unit 160 is a functional configuration realized by the CPU 16 executing a game control program stored in the storage unit 15.

[0091] The data storage unit 150 is configured to store data necessary for executing game processing, and includes, for example, a character data storage unit 151, a user data storage unit 152, an owned character data storage unit 153, a high school data storage unit 154, a development data storage unit 155, a team data storage unit 156, and a team member data storage unit 157.

[0092] The character data storage unit 151 stores data for multiple characters available in the game. FIG. 26 is a diagram illustrating an example of character data stored in the character data storage unit 151. The character data D151 is associated with a character ID, a character name, data indicating the character's abilities, and the like. The character ID is identification information for identifying each character. The character name is the character's name. The data indicating the character's abilities includes overall data indicating the character's "overall" abilities, basic ability data indicating the character's "basic abilities," and special ability data indicating the character's "special abilities," as described with reference to FIG. 12. The overall data includes the ability parameters "level" and "experience value." The basic ability data includes the ability parameters "rank" and "practice value" corresponding to "control," "stamina," "ball speed," and the like. The special ability data includes parameters indicating the presence or absence of special abilities corresponding to "special ability #1," "special ability #2," "special ability #3," and the like. Note that these data are merely examples, and the character data D151 may also be associated with various character-related data, such as the character image of each character, their defensive position, and their form.

[0093] The user data storage unit 152 stores user data of users who use the terminal device 10. The user data is associated with a user ID that identifies the user, a user name that indicates the user's name in the game, etc. The user data is also associated with data such as coins, medals, points, tickets, or items that the user has acquired.

[0094] The owned character data storage unit 153 stores character data of owned characters that the user has acquired by lottery or the like from among multiple characters available in the game. For example, the lottery process is performed by the server device 30, and the character data of the owned characters is added by acquiring the lottery results (data of the selected characters) from the server device 30. FIG. 27 is a diagram showing an example of owned character data stored in the owned character data storage unit 153. The illustrated owned character data D153 is associated with a user ID, an owned ID, a character ID, a character name, and the like. The owned ID is identification information that identifies an event related to the ownership of an owned character (assigned to the user) in character data management. For example, when a user acquires a character, a new owned ID is issued, and the character ID, character name, and the like of the acquired character are associated and stored. There are cases where users own the same character, in which case the character ID and character name are the same but the owned ID is different. This owned character data is transmitted to the server device 30, and the owned character data of a plurality of users is managed in the server device 30 in association with each user (each user ID).

[0095] The high school data storage unit 154 stores high school data (scenario data) for high schools (scenarios) prepared in the game. FIG. 28 is a diagram showing an example of high school data stored in the high school data storage unit 154. The illustrated high school data D154 is associated with a high school ID (scenario ID), a high school name (scenario name), high school characters, a default team ID, and the like. The high school ID (scenario ID) is identification information for identifying the high school (scenario). The high school name (scenario name) is the name of the high school (scenario). The high school characters are associated with character IDs of high school characters that are preset for each high school among multiple characters prepared in the game. The default team ID is identification information for identifying a default team that is preset for each high school. Note that high school data may be limited to a limited number of high schools at the start of the game, and more may be added as the game progresses. In this case, the added high school data is obtained from the server device 30 and stored in the high school data storage unit 154. Alternatively, high school data added later may also be stored in high school data storage unit 154, with the high schools selectable by the user limited at the start of the game and the number of selectable high schools increased as the game progresses. The game service may be operated so that high school data (scenario data) and related data are sequentially provided to users at the convenience of the game service operator, independent of the user's progress in the game. In this case, the additional content (high school data and related data) will be available to all users of the game at the same time, regardless of the user's progress in the game.

[0096] The development data storage unit 155 stores development data related to the development status of the development target team being developed in the development part. FIG. 29 is a diagram showing an example of development data stored in the development data storage unit 155. The illustrated development data D155 associates the high school ID (scenario ID) and team ID (ID of the development target team) of the development target team being developed, member IDs (member IDs of each development target character included in the development target team), character data (overall data, basic ability data, special ability data, etc.) of the belonging members (development target characters included in the development target team), school year, and graduation flag. The member ID is identification information that identifies the members (development target characters) belonging to this team (development target team). The character data of the belonging members is character data of the high school characters, optional characters, and extra characters belonging to this team. During the training part, when the user selects a high school (scenario) for the training part, a team ID is issued and associated with the high school ID. Furthermore, the character data of the members (trained characters) of the training team are copied from the character data D151 stored in the character data storage unit 151 and associated with the team ID, generating training data D155 for the new training team. Furthermore, if a member joins the team during the training period, a member ID for the new member is issued, and the character data for the new member is copied from the character data D151 and added to the training data. The grade indicates the grade of the member and changes as the training part progresses. As mentioned above, instead of a variable parameter indicating grade, a fixed parameter may be used that is independent of the progression of the training period. The graduation flag is flag information indicating whether or not the member has graduated from the team. Its initial value is "0" and changes to "1" upon graduation. In the training part, the data (ability parameters, etc.) of this training data D155 is updated, and the data of the character data D151 stored in the character data storage unit 151 is not updated.

[0097] The team data storage unit 156 stores team data for teams (trained teams) held for each high school (scenario). This team data includes both trained teams trained by the user and default teams set for each high school. FIG. 30 is a diagram illustrating an example of team data stored in the team data storage unit 156. The illustrated team data D156 is associated with a high school ID, a high school name, a team ID, a team name, an option flag, a use flag, and team strength (abilities), such as overall strength, batting ability, defensive ability, mobility, pitch speed, control, and curveballs. The option flag is flag information indicating whether a team is available for use. A team that is available for use is set to "1," and a team that is not available for use is set to "0." Basically, a trained team and a default team for a high school with no training history are set to "1," and a default team for a high school with a training history is set to "0." The use flag is flag information indicating whether a team is available for use. A team that is available for use is set to "1," and a team that is not available for use is set to "0." The team data D156 also includes information about the team other than the above information (for example, the team's match results, etc.) This team data is transmitted to the server device 30, and the team data of multiple users is managed in the server device 30 in association with each user (each user ID).

[0098] The team member data storage unit 157 stores team member data including character data of the members (trained characters) of each team (trained team). FIG. 31 is a diagram showing an example of team member data stored in the team member data storage unit 157. The illustrated team member data D157 stores information about the members of the team included in the team data D156 (see FIG. 30). For example, the team member data D157 associates, for each team ID, a member ID, character data (overall data, basic ability data, special ability data, etc.) of the members (characters), and an order flag. Here, the character data (overall data, basic ability data, special ability data, etc.) of the members (trained characters) of the trained team are copies of the character data in the training data D155 of the trained team whose training part has been completed. In other words, the team member data D157 holds updated and confirmed character data whose training has been completed as character data of the members (trained characters) of the trained team. Meanwhile, the character data (overall data, basic ability data, special ability data, etc.) of the members (characters) of the default team stores character data preset for the default team. The order flag is flag information that is set according to the team order setting. For example, the order flag is set to "1" for regular (starting order) members, "2" for bench members, and "0" for members not on the bench. This team member data is transmitted to the server device 30, and the team member data of multiple users is managed in the server device 30 in association with each user (each user ID).

[0099] Returning to FIG. 25, the control unit 160 includes an operation reception unit 161, a display control unit 162, a training part processing unit 163, a use team setting unit 164, an order setting unit 165, and a battle part processing unit 166.

[0100] The operation acceptance unit 161 accepts operations made to the input unit 12. The operation acceptance unit 161 acquires an operation signal input to the input unit 12 based on a user's operation on the various game screens described above. For example, the operation acceptance unit 161 accepts an operation to provisionally select one of a plurality of options and an operation to select and confirm the provisionally selected option based on a user's operation. Specifically, for example, on the practice menu screen G600 shown in FIG. 13, the operation acceptance unit 161 accepts an operation to provisionally select the icon P632 based on an operation on the icon P632 ("control practice"). Furthermore, for example, on the practice menu screen G600 shown in FIG. 13, when the icon P632 ("control practice") is provisionally selected, the operation acceptance unit 161 accepts an operation to select and confirm the icon P632 based on an operation on the icon P623 on which "Confirm" is displayed.

[0101] The display control unit 162 causes the display unit 13 to display images corresponding to the various game screens described above. For example, the display control unit 162 presents to the user the update conditions set for each of the multiple options on the practice menu screen G600 shown in FIG. 13 by displaying them in a manner recognizable to the user before the user makes a selection (see, for example, icons P631, P632, P633, and P634 in FIG. 13). Furthermore, when any option is provisionally selected based on a user operation, the display control unit 162 presents to the user the update conditions obtained by changing the update condition set for at least one of the options by displaying them in a manner recognizable to the user. For example, as shown in FIG. 13, the display control unit 162 displays the update condition set for the option provisionally selected based on a user operation (e.g., icon P632) as the update condition changed by adding a positive alpha value, and displays the update conditions set for the options not provisionally selected without changing them.

[0102] The training part processing unit 163 executes the processing of the training part. For example, the training part processing unit 163 includes a selection unit 1631, an update instruction unit 1632, an update unit 1633, a training providing unit 1634, a data management unit 1635, and a training character setting unit 1636.

[0103] The selection unit 1631 allows the user to select a high school for the development target team to be developed in the development part. For example, the selection unit 1631 selects a high school selected from multiple high school options on the high school selection screen G300 shown in Fig. 6 as the high school for the development target team to be developed in the development part. Note that selecting a high school in the development part corresponds to selecting a scenario in the development part.

[0104] The update instruction unit 1632 instructs updating of data associated with multiple characters (training target characters) included in a team (training target team). For example, the update instruction unit 1632 instructs updating of data for a character associated with an option selected by the user from multiple options (e.g., icons P631, P632, P633, and P634 of each practice item on the practice menu screen G600 shown in FIG. 13 ) including an option associated with any of the multiple characters included in the team. Specifically, the update instruction unit 1632 instructs each of the characters associated with the option selected by the user to update based on the update condition set for that option, based on the update condition set for that option. In other words, the update instruction unit 1632 instructs characters associated with the same option to update based on the same update condition set for that option. Here, for example, the update condition is set based on the character associated with the corresponding option.

[0105] Furthermore, the update instruction unit 1632 instructs each character (character to be developed) associated with the option selected by the user to update based on update conditions obtained by changing at least one of the update conditions set for the option selected by the user and the update conditions set for the option not selected by the user, and also instructs each character (character to be developed) associated with the option not selected by the user to update. Here, the above-mentioned "change of at least one update condition" is a change that makes the option selected by the user more advantageous than the option not selected by the user. For example, the update instruction unit 1632 instructs each character associated with the option selected based on the user's operation to update their data using a value that is the original update condition (original setting value) plus alpha. On the other hand, the update instruction unit 1632 instructs each character associated with the option not selected to update their data using the original update condition (original setting value).

[0106] The update unit 1633 updates data associated with a team (development target team) in the development part. For example, the update unit 1633 updates data associated with a development target team corresponding to a high school (scenario) selected by a user. The data associated with a development target team includes overall data, basic ability data, and special ability data of characters (development target characters) included in the development target team, as well as team data (total strength and data on each ability) that changes in accordance with the character data. Specifically, the update unit 1633 updates data (development data D155 in FIG. 29) associated with each of two or more characters (development target characters) included in the development target team in response to a single instruction (for example, one turn) from the update instruction unit 1632.

[0107] The update unit 1633 updates the data associated with the development target team during the development period (predetermined period). Specifically, the update unit 1633 updates the data associated with the characters (development target characters) included in the development target team as the development part progresses within the development period (predetermined period). The update unit 1633 also updates the data associated with the development target characters set as characters included in the development target team based on the data associated with the user (i.e., the owned characters). During the development part, the data associated with the user (i.e., the owned characters) themselves are not updated.

[0108] The development providing unit 1634 provides the user with a single opportunity to give an instruction (for example, one turn) by the update instruction unit 1632 multiple times, up to a predetermined number of times (for example, 120 turns).

[0109] The data management unit 1635 manages the saving, updating, etc. of various data stored in the data storage unit 150. For example, the data management unit 1635 manages multiple trained teams updated in the training part. Specifically, the data management unit 1635 stores and manages the team data of the multiple trained teams updated in the training part and the team member data in which the data associated with the characters (trained characters) included in the trained teams has been updated in the team data storage unit 156 and the team member data storage unit 157, respectively. Note that the data stored by the data management unit 1635 in the team data storage unit 156 and the team member data storage unit 157 is data of trained teams whose updates have been completed upon completion of the training part. The data management unit 1635 manages each of the multiple trained teams by high school (scenario). Note that the data of the trained teams whose updates have been completed and which is managed by the data management unit 1635 will not be updated again.

[0110] Furthermore, the data management unit 1635 manages default teams for each high school (scenario) in advance, as teams to be used in matches in the match part, before the training of the training target team (data update) is performed in the training part. For example, the data management unit 1635 stores and manages the team data and team member data of the default team in the team data storage unit 156 and the team member data storage unit 157, respectively, in the same way as the team data and team member data of the trained teams, respectively.

[0111] Furthermore, the data management unit 1635 associates data indicating characters with users in exchange for the consumption of game value (such as in-game coins or tickets obtained through billing or game progress), and stores and manages the data in the possessed character data storage unit 153. For example, the data management unit 1635 acquires data indicating the selected event character from the server device 30 in accordance with the result of a lottery process performed in the server device 30.

[0112] In the training part, the training character setting unit 1636 sets high school characters determined according to the high school (scenario) selected by the user and optional characters set based on data selected by the user from data associated with the user (characters owned by the user) as members (training target characters) included in the training target team. In addition, the training character setting unit 1636 sets extra characters in addition to the high school characters and optional characters as members (training target characters) included in the training target team. The training character setting unit 1636 stores the set data as training data (see FIG. 29) in the training data storage unit 155 via the data management unit 1635.

[0113] The development character setting unit 1636 also includes an adding unit 1637 and a canceling unit 1638. When a character (development target character) joins the team during the development period in the development part, the adding unit 1637 adds the character to the development data D155 (see FIG. 29) as a development target character included in the development target team as a development target (a target for update). When a development target character graduates from the team during the development period in the development part, the canceling unit 1638 excludes the graduating development target character included in the development target team as a development target (a target for update) from the development targets (a target for update) (changes the graduation flag from "0" to "1") (see FIG. 29). Note that excluding a graduating development target character included in the development target team from the development targets (a target for update) simply means that the character is no longer a development target (a target for update) temporarily, but does not mean that the character is no longer associated with the development target team.

[0114] The characters to be trained included in the training team may include, at the start of the training part, a plurality of characters (characters who are first-year, second-year, and third-year students at the start of the training part) whose initial state data differs due to the different periods (training periods) updated by the training part. Preferably, the initial character data of each character to be trained is set so that characters to be trained who are second-year students at the start of the training part generally have higher ability parameters than characters to be trained who are first-year students at the start of the training part, and characters to be trained who are third-year students at the start of the training part generally have higher ability parameters than characters to be trained who are second-year students at the start of the training part.

[0115] The usage team setting unit 164, based on a user's operation, pre-sets (sets for use) a team (trained team) that can be used as an opponent of another user in a match part executed by the other user from among a plurality of teams (trained teams) owned by the user. For example, the usage team setting unit 164 pre-sets (sets for use) a team that can be used as an opponent of another user from among a plurality of teams (trained teams) for each of different high schools (scenarios) based on a user's operation. Specifically, the usage team setting unit 164 sets the usage setting of a team for each high school based on a user's operation on the usage setting screen G1000 shown in FIG. 21, and sets the usage flag of the team data D156 (see FIG. 30) stored in the team data storage unit 156 via the data management unit 1635. A team that is set for use at the same high school as the team used by the other user is selected as the opponent of the other user in the match part executed by the other user.

[0116] The order setting unit 165 sets the order (regular and bench characters) of the team (trained team) to be used in the battle part from among the multiple characters (trained characters) included in the trained team based on a user operation. For example, the order setting unit 165 sets the order based on a user operation on the order setting screen G1100 shown in FIG. 22, and sets the order flag (see FIG. 31) of the team member data D157 stored in the team member data storage unit 157 via the data management unit 1635.

[0117] Here, the order of a trained team may include any of high school characters whose data has been updated in the training part, optional characters, and extra characters. Note that the order setting unit 165 may limit the number of trained characters that can be set as an order included in a team used in the battle part depending on the type of trained character (high school character / optional character / extra character). For example, the number of trained characters that can be set as high school characters in an order may be limited to a preset number (or a preset ratio of the total number of affiliated members).

[0118] The battle part processing unit 166 executes the processing of the battle part. The battle part processing unit 166 includes a team selection unit 1661, an opponent determination unit 1662, a battle processing unit 1663, and an item processing unit 1664.

[0119] The team selection unit 1661 selects one team (trained team) to be used in the match from among multiple teams (trained teams) managed by the data management unit 1635, based on a user operation. For example, the team selection unit 1661 may first select a high school (scenario) to be used in the match based on a user operation, and then, if the selected high school has multiple teams that can be selected as teams to be used in the match, select the team to be used in the match based on the user operation. Teams that can be selected as teams to be used in the match are teams whose selection flags are set to "1" in the team data D156 stored in the team data storage unit 156. Note that, after selecting a high school to be used in the match based on a user operation, the team selection unit 1661 may refer to the team data D156 and select a team to be used in the match from teams set for use in the selected high school (teams whose use flags are set to "1"). Also, the high school to be used in the match may be automatically determined without being selected by the user. In this case, the team (trained team) to be used in the match may be selected on the premise that the high school (scenario) to be used in the match has been determined in advance.

[0120] The opponent determination unit 1662 matches opponents for a match in the match part. For example, the opponent determination unit 1662 determines a user to be an opponent from among a plurality of other users based on the teams (trained teams) set for use for each high school (scenario) by the use team setting unit 164. Specifically, for example, the opponent determination unit 1662 refers to the team data D156 (FIG. 30) and determines, based on a value obtained by integrating the abilities of the teams set for use for each high school (for example, the total value of the overall strength), a user from among the plurality of other users whose total value is relatively close to the user to be the opponent. Furthermore, the opponent determination unit 1662 selects a team from the same high school as the opponent. In other words, the opponent determination unit 1662 selects, as the opponent team, a team set for use at the same high school as the team of the user determined as the opponent. Note that data of other users is acquired from the server device 30 via the communication unit 11.

[0121] Note that the matching of opponents for the match in the battle part may be performed by the server device 30. In this case, the opponent determination unit 1662 acquires the results of the opponent matching from the server device 30 via the communication unit 11.

[0122] The match processing unit 1663 performs match processing using the managed team (trained team) in the match part based on the data that has been updated in the training part. For example, the match processing unit 1663 performs match processing using at least some (e.g., characters in an order setting) of the multiple characters (trained characters) included in the team selected as the team to be used in the match. In addition, the match processing unit 1663 performs match processing between the team selected as the team to be used in the match and the opponent team determined by the opponent determination unit 1662 based on the respective data (ability parameters, etc.), and outputs information based on the match result (win or loss, etc.).

[0123] When the user is instructed to use an item owned by the user based on an operation at the start of a match in the battle part, the item processing unit 1664 temporarily changes data associated with the team (trained characters) used in the battle part based on the type of item used. For example, in exchange for consuming a specific item (enhancement item), the item processing unit 1664 improves the value of ability parameters associated with the team (trained team) used in the battle part or the value of ability parameters associated with the characters (trained characters) included in that team, for that match only.

[0124] 6. Game Processing Operation Next, with reference to FIGS. 32 to 39, the operation of the game processing executed by the CPU 16 of the terminal device 10 based on the game control program will be described.

[0125] [6-1. Training part processing operation] 32 is a flowchart showing an example of the training part process according to this embodiment. In this figure, the processes corresponding to those in FIG. 5 are given the same reference numerals.

[0126] The CPU 16 executes a process for setting a development target (step S100). This will be described in detail with reference to Fig. 33. Fig. 33 is a flowchart showing an example of the process for setting a development target according to this embodiment.

[0127] The CPU 16 executes a process for prompting the user to select a high school (scenario) for the team (step S101). This team is a team to be trained in the training part (training target team). For example, the CPU 16 transitions the display screen of the display unit 13 to a high school selection screen G300 shown in FIG. 6. The CPU 16 determines whether or not any of the icons P311, P312, P313, P314, and P315 for selecting each of the multiple high schools displayed on the high school selection screen G300 has been selected (step S103). If the CPU 16 determines that no high school (icon) has been selected (step S103: NO), it continues the determination process of step S103.

[0128] On the other hand, when the CPU 16 determines that a high school (icon) has been selected (step S103: YES), it executes a process of setting a high school character determined according to the selected high school and an optional character set based on data selected by the user from data associated with the user (characters owned by the user) as belonging members (development target characters) to be included in the development target team (step S105). The CPU 16 also executes a process of setting an extra character as belonging members (development target characters) to be included in the development target team (step S107). The components included in the development target team may include, at the start of the development part, multiple characters (characters who are in their first, second, and third years at the start of the development part) whose initial state data differs due to different periods (development periods) updated by the development part. The CPU 16 generates development data (see development data D155 in FIG. 29) of the development target team including the high school character, the optional character, and the extra character as development data for the development target team of the selected high school.

[0129] Returning to FIG. 32, the CPU 16 executes one turn of "development" processing (step S110). In the one turn processing, the CPU 16 executes processing for issuing an instruction to update data associated with multiple characters (development target characters) included in the development target team, and processing for updating data associated with the development target team in response to the instruction. For example, the CPU 16 executes processing for updating data associated with each of two or more characters (development target characters) included in the development target team in response to one instruction (one turn). Furthermore, the CPU 16 updates data associated with characters (development target characters) included in the development target team in accordance with the progress of the development part within the development period (predetermined period). For example, the CPU 16 executes processing for updating data associated with development target characters set as characters (optional characters) included in the development target team based on data associated with the user (characters selected by the user from owned characters).

[0130] The CPU 16 determines whether or not the end condition for the development part has been satisfied (step S140). The processing of step S140 includes the processing of steps S141 and S143. For example, the CPU 16 determines whether or not a match played in a specific turn during the development period has been lost, as the end condition for the development part (step S141). If the CPU 16 determines that the match has not been lost (step S141: NO), it determines that the end condition for the development part has not been satisfied. On the other hand, if the CPU 16 determines that the match has been lost (step S141: YES), it determines that the end condition for the development part has been satisfied, reflects the development results (saves the development target team, which includes the members (development target characters) currently enrolled in the development target team and the members (development target characters) who have graduated during the development period, as a development-completed team), and ends the processing of the development part (step S150).

[0131] Furthermore, the CPU 16 determines whether a predetermined number of turn processes (e.g., 120 turns) have been completed as a termination condition for the training part (step S143). If the CPU 16 determines that the predetermined number of turn processes (e.g., 120 turns) have not been completed (step S143: NO), the CPU 16 determines that the termination condition for the training part has not been met. On the other hand, if the CPU 16 determines that the predetermined number of turn processes (e.g., 120 turns) have been completed (step S143: YES), the CPU 16 reflects the training results (saves the training target team, which includes members (training target characters) currently enrolled in the training target team and members (training target characters) who have graduated during the training period, as a trained team), and terminates the processing of the training part (step S150).

[0132] In this way, the CPU 16 executes the process of step S110 and step S140 (step S143) to provide the user with one instruction opportunity (one turn) multiple times, up to a predetermined number of times (for example, 120 turns). That is, the CPU 16 repeatedly executes the process of updating the data associated with the development target team for a predetermined period (development period) up to a predetermined number of times (for example, 120 turns).

[0133] The order of the processing of step S141 and the processing of step S143 may be reversed, or they may be processed in parallel. Furthermore, the conditions for ending the training part may include interruption at the user's discretion. For example, if the CPU 16 receives an instruction to interrupt training by a user operation during the training period, it may end the processing of the training part without reflecting the training results.

[0134] When the CPU 16 determines that the conditions for ending the training part are not satisfied (step S141: NO or step S143: NO), it determines whether or not it is time to change the training target (step S145). The timings for changing the training target are spring (first week of April) in the second and third years, and autumn (fourth week of September) in the first, second, and third years. When the CPU 16 determines that it is not time to change the training target (step S145: NO), it returns to step S110 and executes the processing for the next turn. On the other hand, when the CPU 16 determines that it is time to change the training target (step S145: YES), it executes processing to change the training target (training target change processing) (step S147). This training target change processing will be described later with reference to FIG. 36.

[0135] In the process of reflecting the training results in step S150, the CPU 16 executes a process of managing multiple trained teams that have completed updating in the training part. For example, the CPU 16 executes a process of managing data on trained teams that have completed updating in response to the end of the training part. This managed data on trained teams that have completed updating will not be updated again after the end of the training part. The CPU 16 also executes a process of managing each of the multiple trained teams by high school (scenario). The CPU 16 also executes a process of managing multiple trained teams in which data associated with characters (trained characters) included in the trained team has been updated.

[0136] Furthermore, the CPU 16 executes a process of managing a default team for each high school (scenario) in advance in association with the team to be used in a match in the match part, before updating (training) of the training target team in the training part.

[0137] The CPU 16 may execute a process of associating data representing a character with a user in exchange for consuming game value (in-game coins or tickets obtained through billing or as the game progresses). Specifically, the CPU 16 may associate data representing a character with a user and store and manage the data in the owned character data storage unit 153.

[0138] [One-turn processing operation] Next, the operation of the one turn process in step S110 of Fig. 32 will be described in detail with reference to Fig. 34. Fig. 34 is a flowchart showing an example of the one turn process according to this embodiment.

[0139] In a turn in which a morning event is set (see the event occurrence schedule in FIG. 10), the CPU 16 executes processing of the set event (step S111). Here, all events for which a predetermined occurrence condition is met, among scenario events (events specific to a high school (scenario specific) and events common to all high schools (scenario common)) and event character events (events by an event character), are set as targets for processing execution. For example, the CPU 16 transitions to an event screen corresponding to the set event (e.g., event screen G400 in FIG. 9) and sequentially displays multiple event images according to the story of the event. At this time, as a result of the processed event, various parameters, such as ability parameters of the characters to be trained included in the training team, are changed. If multiple events occur, the results of the multiple events are reflected respectively. When the event processing is completed, the CPU 16 transitions the display screen of the display unit 13 to the manager menu screen G500 (see FIG. 11) (step S113). Note that in a turn in which a morning event is not set, the CPU 16 proceeds to the processing of step S113 without performing event processing.

[0140] The CPU 16 determines whether or not an operation to select one of the menu items ("Practice," "Construction," "Mission," "Manager Skills," or "Teaching") has been accepted on the manager menu screen G500, based on an operation signal from the input unit 12. Specifically, in step S115, the CPU 16 determines whether or not an operation to select the icon P520 ("Construction") has been accepted. If the CPU 16 determines that an operation to select the icon P520 ("Construction") has been accepted (step S115: YES), the CPU 16 executes the construction process for "Construction" described above (step S117). When the construction process is completed, the CPU 16 returns to the manager menu screen G500 (see FIG. 11) (step S113).

[0141] On the other hand, if the CPU 16 determines that an operation to select the icon P520 ("Construction") has not been accepted (step S115: NO), it determines in step S119 whether or not an operation to select the icon P530 ("Mission") has been accepted. If the CPU 16 determines that an operation to select the icon P530 ("Mission") has been accepted (step S119: YES), it executes the mission process for the "Mission" described above (step S121). For example, the CPU 16 transitions the display screen of the display unit 13 to the mission screen G700 (see FIG. 15). When the mission process ends, the CPU 16 returns to the supervisor menu screen G500 (see FIG. 11) (step S113).

[0142] On the other hand, if the CPU 16 determines that an operation to select the icon P530 ("Mission") has not been accepted (step S119: NO), it determines in step S123 whether or not an operation to select the icon P540 ("Manager Skill") has been accepted. If the CPU 16 determines that an operation to select the icon P540 ("Manager Skill") has been accepted (step S123: YES), it executes the manager skill process for the "Manager Skill" described above (step S125). For example, the CPU 16 transitions the display screen of the display unit 13 to the manager skill screen G800 (see FIG. 16). When the manager skill process ends, the CPU 16 returns to the manager menu screen G500 (see FIG. 11) (step S113).

[0143] On the other hand, when the CPU 16 determines that an operation to select the icon P540 ("Supervisor Skill") has not been accepted (step S123: NO), it determines in step S127 whether or not an operation to select the icon P550 ("Teaching") has been accepted. When the CPU 16 determines that an operation to select the icon P550 ("Teaching") has been accepted (step S127: YES), it executes the teaching process for "Teaching" described above (step S129). For example, the CPU 16 transitions the display screen of the display unit 13 to a teaching screen G900 (see FIG. 16). When the teaching process ends, the CPU 16 returns to the supervisor menu screen G500 (see FIG. 11) (step S113).

[0144] On the other hand, when the CPU 16 determines that an operation to select the icon P550 ("Teach") has not been accepted (step S127: NO), it determines in step S131 whether or not an operation to select the icon P510 ("Practice") has been accepted. When the CPU 16 determines that an operation to select the icon P510 ("Practice") has been accepted (step S131: YES), it executes the practice process related to "Practice" described above (step S133). For example, the CPU 16 transitions the display screen of the display unit 13 to the practice menu screen G600 (see FIG. 13). On the other hand, when the CPU 16 determines that an operation to select the icon P510 ("Practice") has not been accepted (step S131: NO), it returns to or continues with the manager menu screen G500 (see FIG. 11) (step S113).

[0145] When the practice process is completed, the CPU 16 executes the process for the set event in the turn in which the afternoon event is set (see the event occurrence schedule in FIG. 10) in the same manner as the process for the morning event (step S135). When the event process is completed, the CPU 16 ends the one-turn process. Note that, when the practice process is completed, the CPU 16 ends the one-turn process without performing the event process in the turn in which the afternoon event is not set.

[0146] The order of the determination processes in steps S115, S119, S123, S127, and S131 may be reversed, or they may be performed in parallel.

[0147] [Practice processing operation] Next, the details of the operation of the practice process in step S133 in Fig. 34 will be described with reference to Fig. 35. Fig. 35 is a flowchart showing an example of the practice process according to this embodiment. The CPU 16 transitions the display v of the display unit 13 to the practice menu screen G600 (see FIG. 13), and executes a process of presenting the update conditions set for each of the multiple options (see, for example, icons P631, P632, P633, and P634 in FIG. 13) (step S1331) in a manner that allows the user to recognize them. That is, the CPU 16 displays the update conditions set for each of the multiple options on the display unit 13 in advance so that the user can recognize them before the user makes a selection.

[0148] The CPU 16 executes a process of accepting an operation to provisionally select one of a plurality of options (for example, icons P631, P632, P633, and P634 in FIG. 13) based on a user operation. The CPU 16 also determines whether or not one of the plurality of options has been provisionally selected based on the user operation (step S1333). If the CPU 16 determines that none of the options has been provisionally selected based on the user operation (step S1333: NO), it continues the determination process of step S1333.

[0149] On the other hand, when it is determined that any of the options has been provisionally selected based on the user's operation (step S1333: YES), the CPU 16 executes a process of presenting to the user each of the provisionally selected option and the non-provisionally selected options an updated update condition obtained by changing the update condition set for at least one of the options (step S1335). For example, as shown in Fig. 13, the update condition (original update condition) set for the option provisionally selected based on the user's operation (e.g., icon P632) is displayed as an update condition changed by adding an alpha value, and the update conditions (original update condition) set for the options not provisionally selected (e.g., icons P631, P633, P634) are displayed without being changed.

[0150] The CPU 16 executes a process of accepting an operation to select and confirm the provisionally selected option (e.g., icon P632) based on a user operation (step S1337). The CPU 16 also determines whether or not the provisionally selected option has been selected and confirmed based on the user operation. If it is determined that the provisionally selected option has not been selected and confirmed (step S1337: NO), the CPU 16 returns to the process of step S1333, executes a process of accepting an operation to provisionally select, and changes the display of the update conditions if another option has been provisionally selected (step S1335).

[0151] On the other hand, if it is determined that the provisionally selected option (e.g., icon P632) has been selected and confirmed (step S1337: YES), the CPU 16 instructs the character to be trained associated with the option to update its data (step S1339). That is, the CPU 16 instructs the character (character to be trained) associated with the option (e.g., icon P632) selected (selected and confirmed) by the user from among a plurality of options including an option associated with one of a plurality of characters (characters to be trained) included in the training team to update its data. For example, based on the update conditions set for each of the plurality of options, the CPU 16 instructs each of the characters (characters to be trained) associated with the option selected (selected and confirmed) by the user to update based on the update conditions (the same update conditions) set for the option. This update condition is an update condition changed to a value obtained by adding alpha to the (original update condition). On the other hand, the CPU 16 instructs each of the characters (characters to be developed) associated with options (for example, icons P631, P632, P633, P634) that have not been selected (selected) by the user to update their data under the original update conditions (original set values). In this way, the CPU 16 instructs each of the characters (characters to be developed) associated with the options selected by the user to update their data based on update conditions that have changed at least one of the update conditions set for the options selected by the user and the update conditions set for the options not selected by the user, and also instructs each of the characters (characters to be developed) associated with the options not selected by the user to update their data.

[0152] In response to the instruction in step S1339, CPU 16 executes a process of updating data associated with the development target team (for example, the overall data, basic ability data, and special ability data of the development target characters, and data of the development target team that changes in accordance with the data of the development target characters, etc.) (step S1341). For example, CPU 16 updates data (development data D155 in FIG. 29) associated with one or more characters (development target characters) associated with each option, based on an update condition set for each option.

[0153] [Operation of the training target change process] Next, the operation of the raising target change process in step S147 of Fig. 32 will be described in detail with reference to Fig. 36. Fig. 36 is a flowchart showing an example of the raising target change process according to this embodiment. This raising target change process is performed in the spring of the second and third years (first week of April) and in the autumn of the first, second, and third years (fourth week of September).

[0154] The CPU 16 executes a process of excluding (graduating from) a training target character included in a training target team as a target for update from the target for data update during the training period. Specifically, the CPU 16 refers to the training data D155 (see FIG. 29) and determines whether or not there is a training target character to be graduated (i.e., a training target character in the third year) at the timing of autumn (fourth week of September) of the first year, second year, and third year (step S1471). If there is a training target character to be graduated at the timing of autumn (fourth week of September) of the first year, second year, and third year (step S1471: YES), the CPU 16 changes the graduation flag of the training target character to be graduated in the training data D155 from "0" to "1" and excludes the training target character from the training target (target for update) (step S1473).

[0155] On the other hand, if it is not the autumn of the first, second, or third year (fourth week of September), or if there are no characters to be trained who are to graduate even in the autumn of the first, second, or third year (fourth week of September) (step S1471: NO), CPU16 performs processing from step S1475 onwards to add (join) characters to be trained that are included in the training team as targets for updating data during the training period (predetermined period).

[0156] In step S1475, the CPU 16 determines whether or not a character to be trained will be added (joined) in the spring of the second and third years (first week of April). For example, if there is a character to be trained to be added (joined) in the spring of the twelfth and third years (first week of April), it is possible to allow the number of characters to be trained equal to the number of people who have graduated to join the club. Note that it may be possible to allow a predetermined number of people to join the club regardless of the number of people who have graduated. If there is no character to be trained to be added (joined) in the spring of the second and third years (first week of April) (step S1475: NO), the CPU 16 ends the training target change process. On the other hand, if there is an addition (joining) of a character to be trained in the spring of the second and third years (first week of April) (step S1475: YES), the CPU 16 refers to the owned character data D153 (see Figure 27) and displays on the display unit 13 a list of owned characters to allow the user to select a character that will serve as the source data for the character to be trained to join from among the characters owned by the user (step S1477).

[0157] The CPU 16 sets a character to be added to the team based on a character selected by the user from among the characters owned by the user (step S1479). The CPU 16 adds data of the character to be added to the team based on the selected character to the development data D155 (see FIG. 29), and adds the character to be added to the development team as a character to be developed (step S1481).

[0158] The order of the process for graduating (steps S1471 to S1473) and the process for joining (steps S1475 to S1481) may be reversed, or they may be processed in parallel.

[0159] [6-2. Battle part processing operation] Next, the operation of the battle part process according to this embodiment will be described in detail. FIG. 37 is a flowchart showing an example of the battle part process according to this embodiment. The CPU 16 refers to the team data D156 and causes the display unit 13 to display options for high schools (scenario) for the teams (trained teams) to be used in the match (step S200). This causes the CPU 16 to prompt the user to select a high school. The screen on which the options for high schools are displayed may be the same as the high school selection screen G300 shown in FIG. 6.

[0160] When any of the high school (scenario) options is selected, the CPU 16 selects the selected high school based on a user operation as the high school to be used in the match (step S210). The CPU 16 references the team data D156 and causes the display unit 13 to display options for teams (trained teams) associated with the selected high school (step S220). This allows the CPU 16 to prompt the user to select a high school team. When any of the team options is selected, the CPU 16 selects the team selected based on a user operation as one of the multiple teams to be used in the match (step S230).

[0161] If the selected high school (scenario) has only one team (trained team) available for use in the match, CPU 16 may omit the process of step S220 and select that one team as the team to be used in the match. Also, if the selected high school has a team set for use in the match, CPU 16 may omit the process of step S220 and select the team set for use as the team to be used in the match.

[0162] The CPU 16 determines whether or not an order change request has been made based on the user's operation (step S240). If the CPU 16 determines that an order change request has been made (step S240: YES), it executes the order setting process of step S250. If the CPU 16 determines that an order change request has not been made (step S240: NO), it proceeds to the process of step S260 without executing the order setting process of step S250.

[0163] In the order setting process of step S250, the CPU 16 executes a process of setting (setting in the order) characters to be used in the battle part from among a plurality of characters (characters to be trained) included in the selected trained team based on a user operation (step S250). For example, the CPU 16 transitions the display screen of the display unit 13 to an order setting screen G1100 shown in Fig. 22. Furthermore, the CPU 16 sets the order based on the user operation on the order setting screen G1100, and sets the order flag (see Fig. 31) of the team member data D157 stored in the team member data storage unit 157.

[0164] The CPU 16 may set any of high school characters, optional characters, and extra characters as characters to be used in the battle part. For example, the CPU 16 may limit the number of trained characters that can be set as an order included in a team to be used in the battle part according to the type of trained character (high school character / optional character / extra character). For example, the number of trained characters that can be set as high school characters in an order may be limited to a preset number (or a preset ratio of the total number of affiliated members). When the order setting process is completed, the process proceeds to step S260.

[0165] In step S260, the CPU 16 executes a process of determining an opponent for the team (trained team) selected in step S230 (step S260). For example, the CPU 16 determines a user from among a plurality of other users to be an opponent based on the teams set for use for each high school (scenario). Specifically, for example, the CPU 16 refers to the team data D156 (FIG. 30) and determines, based on a value obtained by integrating the abilities of the teams set for use for each high school (for example, the total value of the overall strength), a user from among the plurality of other users whose total value is relatively close to the total value as the opponent. Furthermore, the CPU 16 selects, as an opponent for the team selected in step S230, a team set for use in advance by another user from the same high school as the team selected in step S230. In other words, the CPU 16 selects, from among the teams of the users determined as opponents, a team set for use in advance from the same high school as the team selected in step S230 as the opponent team. Note that the data of the other users is acquired from the server device 30 via the communication unit 11.

[0166] The process of determining the opponent may be performed by the server device 30. In this case, the CPU 16 acquires the result of determining the opponent from the server device 30 via the communication unit 11.

[0167] Once the opponents have been determined, the CPU 16 executes a match process between the team (trained team) selected in step S230 and the team (trained team) determined in step S260 (step S270). For example, the CPU 16 executes the match process using the above team based on data updated in the training part. The CPU 16 also executes the match process using at least some (for example, characters in an order setting) of the multiple characters (trained characters) included in the above team.

[0168] When the match ends, the CPU 16 outputs information based on the match result (win or loss, etc.) and updates the data (step S280). For example, the CPU 16 displays information based on the match result (win or loss, etc.) on the display unit 13. The CPU 16 also updates the team data based on the match result (win or loss, etc.).

[0169] The order setting (order change) processing in steps S240 and S250 may be executed during the battle processing in step S270.

[0170] [6-3. Usage setting process] Next, the operation of the usage setting process according to this embodiment will be described. FIG. 38 is a flowchart showing an example of the usage setting process according to this embodiment. The CPU 16 transitions the display screen of the display unit 13 to the usage setting screen D1000 (see FIG. 21), and presents the high school (scenario) and team (trained team) for which usage setting is to be performed (step S4301).

[0171] On the usage setting screen D1000, based on an operation of selecting one of the icons corresponding to each high school (scenario) displayed in high school selection R1030, CPU 16 displays options of teams (trained teams) that can be set as available at the selected high school (step S4303). For example, on the usage setting screen D1000, CPU 16 displays options of teams that can be set as available at the selected high school in "current team" information R1010 and "replacement team" information R1020.

[0172] Based on the user's operation, the CPU 16 executes a process of setting (setting for use) in advance, from among a plurality of teams (trained teams), a team that can be used as an opponent of the other user in the battle part executed by the other user (step S4305). For example, the CPU 16 sets the use setting of a team for each high school based on the user's operation on the use setting screen G1000 described above with reference to Fig. 21, and sets the use flag of the team data D156 (see Fig. 30).

[0173] Note that order setting processing may also be possible in this usage setting processing. For example, CPU 16 may execute order setting for a team (trained team) set for usage in the processing of steps S4307 and S4309. The processing of steps S4307 and S4309 is similar to the processing of steps S240 and S250 shown in FIG. 37, and therefore description thereof will be omitted.

[0174] The CPU 16 determines whether the conditions for terminating the usage settings are met based on the user's operation (step S4311). If the CPU 16 determines that the termination conditions are not met (step S4311: NO), the CPU 16 continues the usage setting process. On the other hand, if the CPU 16 determines that the termination conditions are met (step S4311: YES), the CPU 16 terminates the usage settings. For example, if an operation is performed on the icon P1013 displaying "Back" on the usage setting screen D1000 (step S4311: YES), the CPU 16 terminates the usage settings.

[0175] [6-4. Strengthening Item Processing Operation] Next, the operation of the strengthening item process that temporarily (only for that match) changes data associated with a team (trained team) in the match part will be described. FIG. 39 is a flowchart showing an example of the enhancement item processing according to this embodiment. During the battle process, the CPU 16 selects a character in the battle based on a predetermined user operation (step S2711). Furthermore, the CPU 16 refers to the user data D152, presents (displays) a list of items associated with the user to the user, and selects an item (enhancement item) based on a predetermined user operation (step S2713).

[0176] The CPU 16 executes a process to temporarily change data associated with the team (trained team) to be used in the battle part (step S2715). For example, the CPU 16 temporarily improves the ability parameters of the selected trained character based on the strengthening conditions associated with the selected item (strengthening item). At this time, the CPU 16 does not change the data of the team member data D157, but retains the changed data only for the battle process.

[0177] The CPU 16 determines whether the battle has ended (step S2717). If the CPU 16 determines that the battle has not ended (step S2717: NO), it continues the determination process of step S2717. On the other hand, if the CPU 16 determines that the battle has ended (step S2717: YES), it clears the held change data and ends the enhancement item process (step S2719).

[0178] Note that the data that is temporarily changed using an enhancement item is not limited to the ability parameters of a character, but may be special ability data of a character or ability parameters of a team. Furthermore, the use of one item may impart the same effect to all of the trained characters included in a team (trained team) used in a match.

[0179] [7. Modifications] Although the embodiments of the present invention have been described above in detail with reference to the drawings, the specific configurations are not limited to the above-described embodiments, and the present invention also includes designs that do not deviate from the gist of the present invention. For example, the configurations or processes described in the above-described embodiments can be combined in any manner.

[0180] Although the above embodiment has been described primarily with reference to an example in which the present invention is applied to a baseball game, the present invention can also be applied to games other than baseball games. For example, the present invention can also be applied to sports games other than baseball games, such as soccer games, basketball games, and ice hockey games. The present invention can also be applied to games other than sports games. In sports games, the collective is primarily a team, but is not limited to a team and may be a group, organization, squad, division, region, or country. Furthermore, the components included in the collective are not limited to characters such as people (or animals or objects (e.g., vehicles)) but may also be parts, items, etc. For example, the present invention can be applied to a game in which data associated with multiple parts, which are components included in a tank, is updated (e.g., strengthened) in the first part, thereby updating (e.g., strengthening) data associated with the tank, which is a collective including the multiple parts, and then, in the second part, a battle process is performed against an opponent (e.g., an enemy tank) using the tank whose data was updated in the first part. Furthermore, the second part is not limited to a game that performs a battle process, and may be any process that uses a group whose data has been updated in the first part. For example, the second part may be an adventure game, role-playing game, quiz game, challenge game, educational (intellectual training) game, or a combination of these, in which a group whose data has been updated in the first part (for example, a team) is used to perform a process of exploring, solving a mystery, playing a quiz, or taking on some kind of challenge (topic).

[0181] In the above embodiment, the team attribute is a high school, but this is not limiting. The attribute may be a university, a company, or a professional baseball league. Alternatively, the attribute may be a military, a region, a country, or the like.

[0182] In the above embodiment, for example, a program for implementing the functions of the control unit 160 is recorded on a computer-readable recording medium, and the program recorded on the recording medium is loaded into a computer system and executed to perform processing as the control unit 160. Here, "loading a program recorded on a recording medium into a computer system and executing it" includes installing the program into a computer system. The "computer system" here includes hardware such as an OS and peripheral devices. The "computer system" may also include multiple computer devices connected via a network, including communication lines such as the Internet, a WAN, a LAN, and a dedicated line. The "computer-readable recording medium" refers to portable media such as a floppy disk, a magneto-optical disk, a ROM, or a CD-ROM, or a storage device such as a hard disk built into a computer system. Thus, the recording medium storing the program may be a non-transitory recording medium such as a CD-ROM. The recording medium may also include internal or external recording media accessible from a distribution server to distribute the program. The program code stored on the distribution server's recording medium may be different from the program code executable by the terminal device 10. In other words, the format in which the program is stored on the distribution server does not matter as long as it can be downloaded from the distribution server and installed in a form that is executable on the terminal device 10. The program may be divided into multiple parts, each downloaded at a different time and then combined on the terminal device 10, or each of the divided programs may be distributed by a different distribution server. Furthermore, the term "computer-readable recording medium" also includes a storage medium that stores a program for a certain period of time, such as volatile memory (RAM) within a computer system that serves as a server or client when a program is transmitted over a network. The program may also be a program that realizes part of the above-described functions. Furthermore, the program may be a so-called differential file (differential program) that can realize the above-described functions in combination with a program already stored in the computer system.

[0183] Furthermore, some or all of the functions of the control unit 160 described above may be realized as an integrated circuit such as an LSI (Large Scale Integration). Each of the above functions may be individually implemented as a processor, or some or all of the functions may be integrated into a processor. Furthermore, the integrated circuit method is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor. Furthermore, if an integrated circuit technology that can replace LSI emerges due to advances in semiconductor technology, an integrated circuit based on that technology may be used.

[0184] Furthermore, some of the functions of the control unit 160 described above may be provided in the server device 30. For example, the server device 30 may include some or all of the training part processing unit 163, the available team setting unit 164, the order setting unit 165, and the battle part processing unit 166, and the terminal device 10 may acquire some or all of the processing results of the training part processing unit 163, the available team setting unit 164, the order setting unit 165, and the battle part processing unit 166 from the server device 30. For example, the game may be a so-called browser game in which the terminal device 10 acquires display images of game processing performed by the server device 30 and receives operations in the game processing and transmits them to the server device 30.

[0185] [8. Notes] From the above description, the present invention can be understood, for example, as follows: Note that, to facilitate understanding of the present invention, reference numerals in the accompanying drawings are conveniently placed in parentheses, but this does not mean that the present invention is limited to the illustrated embodiments.

[0186] (Appendix A1) A game program according to one embodiment of the present invention causes a computer to execute steps (S110, S1339) of instructing a computer to update data associated with multiple components (e.g., characters (characters to be developed)) included in a group (e.g., a team (team to be developed)), steps (S110, S1341) of updating data associated with each of two or more components included in the group in response to a single instruction (e.g., one turn) made in the instructing step, and steps (S110, S140, S143) of providing the user with a single opportunity to give an instruction in the instructing step multiple times, up to a predetermined number of times (e.g., 120 turns).

[0187] According to the configuration of Appendix A1, data of the constituent elements is updated (for example, strengthened or developed) in units of aggregates, so aggregates can be strengthened (developed) efficiently.

[0188] (Appendix A2) Also, one aspect of the present invention is a game program as described in Appendix A1, wherein in the instructing step (S110, S1339), the update is instructed for a component associated with an option selected by the user from among a plurality of options including options (e.g., practice item icons P631, P632, P633, P634) associated with one of a plurality of components (e.g., characters (characters to be developed)) included in the group (e.g., a team (team to be developed)).

[0189] According to the configuration of Appendix A2, the user can select practice items from a plurality of options, thereby efficiently strengthening (developing) the data or components of the group that the user wants to strengthen.

[0190] (Appendix A3) Also, one aspect of the present invention is a game program as described in Appendix A2, wherein in the instructing step (S110, S1339), based on update conditions set for each of the multiple options (e.g., the amount of increase in "experience points" and "practice points"), each of the components (e.g., characters (characters to be trained)) associated with the option selected by the user is instructed to update based on the update conditions set for that option.

[0191] According to the configuration of Appendix A3, the data of the components associated with the options selected by the user is updated based on the update conditions of the options. Therefore, even when updating data on a collection basis, it is possible to have variations in the update conditions and the components to be updated.

[0192] (Appendix A4) Another aspect of the present invention is the game program according to Appendix A3, wherein the update condition is set based on a component associated with the corresponding option.

[0193] According to the configuration of Appendix A4, it is possible to efficiently strengthen (develop) a group according to the type of component (for example, pitcher, fielder, etc.) and characteristics (for example, a pitcher who emphasizes control, etc.).

[0194] (Appendix A5) Also, one aspect of the present invention is a game program as described in Appendix A3 or Appendix A4, which causes the computer to execute a step (S1331) of presenting update conditions set for each of the plurality of options in a manner that is recognizable to the user.

[0195] According to the configuration of Appendix A5, the user can select a practice item from a plurality of options in consideration of the update conditions, and therefore can efficiently strengthen (develop) the group.

[0196] (Appendix A6) Furthermore, one aspect of the present invention is a game program as set forth in any one of Appendices A3 to A5, wherein in the instructing step (S110, S1339), the update is instructed for each of the components associated with the option selected by the user (e.g., a character (character to be developed)) based on update conditions that have been changed to at least one of the update conditions set for the option selected by the user and the update conditions set for the option not selected by the user, and the update is instructed for each of the components associated with the option not selected by the user, and the change in at least one of the update conditions is a change that makes the option selected by the user more advantageous than the option not selected by the user.

[0197] According to the configuration of Appendix A6, components associated with multiple options can be strengthened (developed) regardless of whether a selection is made or not, and components associated with a selected option can be further strengthened (developed), so that the group can be strengthened (developed) efficiently while respecting the user's wishes.

[0198] (Appendix A7) Also, one aspect of the present invention is a game program as described in Appendix A6, which causes the computer to execute the steps of accepting, based on a user's operation, an operation to provisionally select one of the plurality of options and an operation to select and confirm the provisionally selected option (S1333, S1337), and a step of presenting to the user in a recognizable manner the update conditions set for each of the plurality of options, and, when any option is provisionally selected based on the user's operation, presenting to the user in a recognizable manner the update conditions for each of the options, with the update conditions set for at least one of the options having been changed.

[0199] According to the configuration of Appendix A7, the user can determine which option (practice item) to select after checking the update conditions that will be changed by the selection.

[0200] (Appendix A8) Also, one aspect of the present invention is a game program described in any one of Appendices A1 to A7, which causes the computer to execute steps (S101, S103) of having a user select attributes (e.g., high school (scenario)) of the collection (e.g., team (team to be developed)), and a step (S105) of setting components (e.g., high school characters) determined according to the attributes of the collection selected by the user and components (e.g., arbitrary characters) determined according to data selected by the user from data associated with the user as multiple components included in the collection.

[0201] According to the configuration of Appendix A8, the aggregate whose data is updated in the first part (for example, the development part) can include components specific to the attribute selected by the user and components selected from the data associated with the user, so that an aggregate can be created that incorporates the characteristics of the attribute while also incorporating the user's intentions. Also, because some of the components included in the aggregate are selected from the components associated with the user, it is possible to motivate the user to enter a lottery to acquire the components.

[0202] (Appendix A9) Also, one aspect of the present invention is a game program described in any one of Appendices A1 to A8, which causes the computer to execute the steps of: managing a plurality of collections (e.g., teams (trained teams)) whose data associated with components has been updated by the updating step (S110, S1341); selecting one collection to be used in a battle from among the plurality of managed collections based on user operation (S210, S230); and performing a battle process using at least some of the plurality of components (e.g., characters (trained characters)) included in the selected collection (S270).

[0203] According to the configuration of appendix A9, multiple aggregates with updated (e.g., strengthened, developed) data of the components can be stored on an aggregate unit basis, and the components to be used in a battle can be selected from among them, so that the play using aggregates organized using the components with updated data can be diversified. Also, multiple aggregates can be efficiently strengthened (developed) on an aggregate unit basis.

[0204] (Appendix A10) Also, one aspect of the present invention is a game program as described in Appendix A9, wherein in the managing step (S150), data of the aggregate (e.g., a team (trained team)) for which the update has been completed is managed, and in the performing battle processing step (S270), battle processing using the managed aggregate is performed based on the data for which the update has been completed, and the data of the aggregate for which the update has been completed and managed by the managing step is not updated again.

[0205] According to the configuration of appendix A10, in the first part, while it is possible to collectively update the data of the components included in a collection (e.g., strengthening and development), it is not possible to update each individual component, which increases the difficulty of raising all the components included in a collection to a high level and creating a powerful collection, thereby increasing the motivation to play the first part. Also, once the data of a collection has been updated in the first part, it is no longer possible to update the data thereafter, so in order to create a stronger collection, it is necessary to repeatedly play the first part, which increases the motivation to play the first part. Also, in the first part, it is possible to efficiently strengthen (develop) multiple collections on a collection-by-collection basis.

[0206] (Appendix A11) A game processing method according to one embodiment of the present invention is a game processing method executed by a computer, and includes the steps of: instructing (S110, S1339) to update data associated with multiple components (e.g., characters (characters to be developed)) included in a group (e.g., a team (team to be developed)); updating (S110, S1341) data associated with each of two or more components included in the group in response to a single instruction (e.g., one turn) made in the instructing step; and providing the user with a single opportunity to give an instruction in the instructing step multiple times (e.g., up to a predetermined number of times (e.g., 120 turns) (S110, S140, S143).

[0207] According to the configuration of supplementary note A11, data of the constituent elements is updated (for example, strengthened or developed) in units of aggregates, so that aggregates can be strengthened (developed) efficiently.

[0208] (Appendix A12) A game device (10) according to one embodiment of the present invention is a game device that executes a game program, and includes an instruction unit (1632) that instructs updating of data associated with multiple components (e.g., characters (characters to be developed)) included in a group (e.g., a team (team to be developed)), an update unit (1633) that updates data associated with each of two or more components included in the group in response to a single instruction (e.g., one turn) from the instruction unit, and a provision unit (1634) that provides the user with a single opportunity to give an instruction from the instruction unit multiple times, up to a predetermined number of times (e.g., 120 turns).

[0209] According to the configuration of supplementary note A12, data of the constituent elements is updated (for example, strengthened or developed) in units of aggregates, so that aggregates can be strengthened (developed) efficiently.

[0210] (Appendix B1) A game program according to one embodiment of the present invention is a game program for a game including a first part (e.g., a training part) that updates data associated with a group (e.g., a team (training team)) consisting of a plurality of components (e.g., characters (training characters)), and a second part (e.g., a battle part) in which the groups (e.g., teams (trained teams)) updated by the first part compete against each other, and causes a computer to execute the steps of updating data associated with the group in the first part (S110, S1341), managing multiple groups updated in the first part (S150), and selecting, based on user operation, one group to be used in a battle in the second part from the multiple managed groups (S210, S213).

[0211] According to the configuration of Appendix B1, multiple aggregates can be maintained with the data of the components updated (e.g., strengthened, developed) on an aggregate-by-aggregate basis, and the aggregate to be used in a match can be selected from among them, thereby diversifying play using aggregates organized using developed components.

[0212] (Appendix B2) Also, one aspect of the present invention is a game program as described in Appendix B1, which causes the computer to execute a step (S4305) of pre-setting, based on a user's operation, a group (e.g., a team (trained team)) from among a plurality of groups that can be used as an opponent of another user in the second part executed by the other user.

[0213] According to the configuration of Appendix B2, in a battle process that is executed by another user asynchronously, the user can determine in advance the set to be used in the battle.

[0214] (Appendix B3) Also, one aspect of the present invention is a game program described in Appendix B2, in which the computer executes steps (S101, S103) in which the user selects an attribute (e.g., high school (scenario)) of the group (e.g., a team (trained team)), and in the updating step (S110, S1341), data associated with the group according to the selected attribute is updated, and in the managing step (S150), each of the multiple groups (e.g., teams (trained teams)) is managed by the attribute, and in the setting step (S4305), based on the user's operation, a group that can be used as an opponent of other users in the second part performed by other users is pre-set from among the multiple groups (e.g., teams (trained teams)) for each of the different attributes.

[0215] According to the configuration of Appendix B3, multiple collections are maintained with updated (e.g., strengthened, developed) data associated with the collection for each attribute, and the user can predetermine, for each attribute, which collection will be used in a battle in a battle process performed by another user from among the multiple collections.

[0216] (Appendix B4) Another aspect of the present invention is a game program as described in Appendix B3, which executes a step (S260) of determining a group previously set by another user having the same attributes as the selected group (e.g., a team (trained team)) as an opponent for the group selected in the selection steps (S101, S103).

[0217] According to the configuration of Appendix B4, by competing against a group of other users with the same attributes, the abilities of the group that the user has strengthened (developed) will affect the outcome of the match, thereby increasing motivation to play the first part.

[0218] (Appendix B5) Another aspect of the present invention is a game program according to appendix B4, In the determining step (S260), an opponent user is determined from among a plurality of other users based on the aggregate (for example, team (trained team)) set for each attribute in the setting step.

[0219] According to the configuration of Appendix B5, the opponent can be determined so that the difference in ability between the player and the opponent is not too large.

[0220] (Appendix B6) Furthermore, one aspect of the present invention is a game program described in any one of Appendices B3 to B5, wherein in the managing step (S150), a predetermined group (e.g., a default team) is associated with and managed in advance for each attribute as a group to be used in a match in the second part, before the group (e.g., a team (a team to be developed)) is updated by the first part.

[0221] According to the configuration of Appendix B6, even for high schools (scenario) that have no record of updating their collectives in the first part, it is possible to compete against other users.

[0222] (Appendix B7) Another aspect of the present invention is a game program described in any one of Appendices B1 to B6, wherein the components (e.g., characters (characters to be developed)) included in the group (e.g., team (team to be developed)) include, at the start of the first part, multiple components whose initial state data differs due to different periods (e.g., development periods) updated by the first part.

[0223] According to the configuration of Supplementary Note B7, at the start of the first part, components with different periods and data updated by the first part are included, so that the components included in the collection can be diversified.

[0224] (Appendix B8) A game processing method according to one embodiment of the present invention is a game processing method executed by a computer based on a game program of a game including a first part (e.g., a training part) that updates data associated with a group (e.g., a team (training team)) consisting of a plurality of components (e.g., characters (training characters)), and a second part (e.g., a battle part) in which the groups (e.g., teams (trained teams)) updated by the first part compete against each other, and includes the steps of updating data associated with the group in the first part (S110, S1341), managing multiple groups updated in the first part (S150), and selecting, based on user operation, one group to be used in a battle in the second part from the managed multiple groups (S210, S213).

[0225] According to the configuration of Appendix B8, multiple aggregates can be maintained with the data of the components updated (e.g., strengthened, developed) on an aggregate-by-aggregate basis, and the aggregate to be used in a match can be selected from among them, thereby diversifying play using aggregates organized using developed components.

[0226] (Appendix B9) A game device (10) according to one embodiment of the present invention is a game device that executes a game program for a game including a first part (e.g., a training part) that updates data associated with a group (e.g., a team (training team)) that includes a plurality of components (e.g., characters (training characters)), and a second part (e.g., a battle part) in which the groups (e.g., teams (trained teams)) updated by the first part compete against each other, and is equipped with an update unit (1633) that updates data associated with the group in the first part, a management unit (1635) that manages a plurality of the groups updated in the first part, and a selection unit (1661) that selects one group to be used in the battle in the second part from the plurality of managed groups based on user operation.

[0227] According to the configuration of Appendix B9, multiple aggregates can be maintained with the data of the components updated (e.g., strengthened, developed) on an aggregate-by-aggregate basis, and the aggregate to be used in a match can be selected from among them, thereby diversifying play using aggregates organized using developed components.

[0228] (Appendix C1) A game program according to one embodiment of the present invention is a game program for a game including a first part (e.g., a training part) that updates data associated with a group (e.g., a team (training team)) consisting of multiple components (e.g., characters (training characters)), and a second part (e.g., a battle part) that uses the group (e.g., a team (trained team)) updated by the first part, and causes a computer to execute the steps of updating data associated with the group in the first part (S110, S1341), managing data of the group (e.g., a team (trained team)) whose update has been completed in response to the end of the first part (S150), and performing processing using the managed group in the second part based on the updated data (S270), and the data of the group whose update has been completed and managed by the managing step is not updated again.

[0229] According to the configuration of Appendix C1, in the first part, while it is possible to collectively update the data of the components included in the collection (for example, strengthening or developing), it is not possible to update each individual component, which increases the difficulty of building a powerful collection by raising the level of all the components included in the collection, thereby increasing the motivation to play the first part. Also, once the data of a collection has been updated in the first part, it is no longer possible to update the data thereafter, so in order to build a stronger collection, it is necessary to repeatedly play the first part, which increases the motivation to play the first part.

[0230] (Appendix C2) Also, one aspect of the present invention is a game program as described in Appendix C1, in which, in the managing step (S150), a plurality of the groups (e.g., teams (trained teams)) are managed, and the computer executes steps (S210, S213) of selecting one group to be used in the second part from the plurality of managed groups based on user operation.

[0231] According to the configuration of Appendix C2, multiple groups whose data has been updated (e.g., strengthened or developed) in the first part can be managed, and the group to be used in a match can be selected from among them, thereby diversifying play using the developed groups.

[0232] (Appendix C3) Another aspect of the present invention is a game program described in Appendix C1 or Appendix C2, wherein in the updating step (S110, S1341), data associated with the group (e.g., a team (training target team)) is updated for a predetermined period (e.g., a training period).

[0233] According to the configuration of appendix C3, since the period (for example, the training period) for updating the data associated with the group is limited, the user can be motivated to strengthen the group as much as possible within the limited period in order to win against other users. Therefore, the motivation to play the first part can be increased.

[0234] (Appendix C4) Another aspect of the present invention is a game program described in Appendix C3, which causes the computer to execute a step (S1481) of adding, during the specified period in the first part, a component (e.g., a character (character to be developed)) included in the collection (e.g., a team (team to be developed)) as a target for the update, and a step (S1473) of excluding, during the specified period in the first part, a component included in the collection as a target for the update from the target for the update.

[0235] According to the configuration of Appendix C4, even during the period in which data associated with the collection is updated (for example, during the training period), the components to be updated can change, so that play in the training part can be diversified.

[0236] (Appendix C5) Also, one aspect of the present invention is a game program described in any one of Appendices C3 to C4, wherein in the updating step (S110, S1341), data associated with components (e.g., characters (characters to be developed)) included in the group (e.g., a team (team to be developed)) is updated in accordance with the progress of the first part within the specified period.

[0237] According to the configuration of Appendix C5, the constituent elements included in the assembly can be strengthened (developed) as the first part progresses.

[0238] (Appendix C6) Another aspect of the present invention is a game program described in any one of Appendices C1 to C5, wherein the components (e.g., characters (characters to be developed)) included in the group (e.g., team (team to be developed)) include, at the start of the first part, multiple components whose initial state data differs due to different periods (e.g., development periods) updated by the first part.

[0239] According to the configuration of Appendix C6, at the start of the first part, components with different periods and data updated by the first part are included, so that the components included in the collection can be diversified.

[0240] (Appendix C7) Also, one aspect of the present invention is a game program described in any one of Appendices C1 to C6, wherein in the step of performing the processing (S270), in the second part, processing is performed using at least some of the multiple components (e.g., characters (trained characters)) included in the collection (e.g., a team (trained team)), and the computer is caused to execute a step (S4305) of setting the components to be used in the second part from the multiple components included in the collection based on user operation.

[0241] According to the configuration of Appendix C7, the user can set the order of the components included in the group that will participate in the match. Therefore, in the second part, the user can play while considering the organization of the group.

[0242] (Appendix C8) Another aspect of the present invention is a game program as described in Appendix C7, which causes the computer to execute a step of associating data indicating a specific component (e.g., an event character) with a user in exchange for consuming game value (e.g., charges, or in-game coins, medals, points, tickets, or items obtained as the game progresses), and in the updating step (S110, S1341), updates data associated with the specific component selected as a component (e.g., a character (trained character)) to be included in the collection (e.g., a team (trained team)) based on the data associated with the user, and in the setting step (S4305), sets the specific component whose data has been updated in the updating step as a component (e.g., a character (trained character)) to be used in the second part based on user operation.

[0243] According to the configuration of Appendix C8, the event characters acquired in exchange for consuming game value can be strengthened (trained) in the training part and used in the battle part, which can also motivate users to acquire event characters.

[0244] (Appendix C9) Also, one aspect of the present invention is a game program as described in Appendix C8, wherein in the setting step (S4305), the specific component (e.g., an event character) to be set as a component (e.g., a character (trained character)) to be used in the second part is limited to a portion of the components included in the collection (e.g., a team (trained team)).

[0245] According to the configuration of Appendix C9, a limit is placed on the number of specific components used in the second part, so that the impact of the consumption of game value on the ability of the group can be prevented from becoming too great.

[0246] (Appendix C10) Also, one aspect of the present invention is a game program described in any one of Appendices C1 to C9, which causes the computer to execute a step (S2715) of temporarily changing data associated with the group (e.g., a team (trained team)) used in the second part.

[0247] The configuration of appendix C10 can diversify the play in the second part and provide motivation for obtaining strengthening items.

[0248] (Appendix C11) A game processing method according to one embodiment of the present invention is a game processing method executed by a computer based on a game program of a game including a first part (e.g., a training part) that updates data associated with a group (e.g., a team (training team)) consisting of multiple components (e.g., characters (training characters)), and a second part (e.g., a battle part) that uses the group (e.g., a team (trained team)) updated by the first part, and includes the steps of: in the first part, updating data associated with the group (S110, S1341); managing the data of the group whose update has been completed in response to the end of the first part (S150); and in the second part, performing processing using the managed group based on the updated data, and the data of the group whose update has been completed and managed by the managing step is not updated again.

[0249] According to the configuration of Appendix C11, in the first part, while it is possible to collectively update the data of the components included in the collection (for example, strengthening or developing), it is not possible to update each individual component, which increases the difficulty of building a powerful collection by raising the level of all the components included in the collection, thereby increasing the motivation to play the first part. Also, once the data update of a collection is completed in the first part, it is no longer possible to update the data thereafter, so in order to create a stronger collection, it is necessary to repeatedly play the first part, which increases the motivation to play the first part.

[0250] (Appendix C12) A game device (10) according to one embodiment of the present invention is a game device that executes a game program for a game including a first part (e.g., a training part) that updates data associated with a group (e.g., a team (training team)) that includes multiple components (e.g., characters (training characters)), and a second part (e.g., a battle part) that uses the group (e.g., a team (trained team)) updated by the first part, and is equipped with an update unit (1633) that updates data associated with the group (e.g., a team (trained team)) in the first part, a management unit (1635) that manages the data of the group whose update has been completed in response to the end of the first part, and a processing unit (1663) that performs processing using the managed group in the second part based on the updated data, and the data of the group whose update has been completed and that is managed by the management step is not updated again.

[0251] According to the configuration of appendix C12, in the first part, while it is possible to collectively update the data of the components included in the collection (for example, strengthening or developing), it is not possible to update each individual component, which increases the difficulty of building a powerful collection by raising the level of all the components included in the collection, thereby increasing the motivation to play the first part. Also, once the data update of a collection is completed in the first part, it is no longer possible to update the data thereafter, so in order to create a stronger collection, it is necessary to repeatedly play the first part, which increases the motivation to play the first part. [Explanation of symbols]

[0252] 1 Game system, 10 Terminal device, 30 Server device, 11 Communication unit, 12 Input unit, 13 Display unit, 14 Audio output unit, 15 Memory unit, 16 CPU, 150 Data memory unit, 151 Character data memory unit, 152 User data memory unit, 153 Owned character data memory unit, 154 High school data memory unit, 155 Development data memory unit, 156 Team data storage unit, 157 team member data storage unit, 160 control unit, 161 operation reception unit, 162 display control unit, 163 training part processing unit, 1631 selection unit, 1632 update instruction unit, 1633 update unit, 1634 training provision unit, 1635 data management unit, 1636 training character setting unit, 1637 addition unit, 1638 release unit, 164 use team setting unit, 165 order setting unit, 166 battle part processing unit, 1661 team selection unit, 1662 opponent determination unit, 1663 battle processing unit, 1664 item processing unit

Claims

[Claim 1] A game program for a game including a first part that updates data associated with a collection configured to include a plurality of components, and a second part that uses the collection updated by the first part, On the computer, In the first part, updating data associated with the collection; managing the data of the collection whose update has been completed in response to the completion of the first part; In the second part, a process using the managed aggregate is performed based on the updated data; Execute The data of the collection that has been managed in the managing step and for which the update has been completed will not be updated again. Game program.

Images