JP7790700B2 - Game system, game control device and program - Google Patents

Description

The present invention relates to a game system, a game control device, and a program.

Games that allow users to train characters and use them within the game have been known for some time. Games have also been proposed that allow users to convert characters that they have trained but not used into items (see, for example, Patent Document 1). Characters that users convert into items are no longer owned by the user.

Japanese Patent Application Laid-Open No. 2020-110678

In the above games, characters that have been trained are lost when they are converted into items, limiting the ways in which they can be used, which can lead to users becoming bored with the gameplay.

The object of the present invention is to provide a game system, game control device, and program that enhance the entertainment value of games.

A game system according to one aspect of the present invention is a game system that provides games including a first game, a second game, and a third game, and includes: a first game execution means that executes the first game, changing or setting parameters of a first object based on a user's operation and storing the changed or set first object in a storage device as an object that can be used in the second game and the third game; a second game execution means that executes the second game, in which at least one of the objects can be used as an auxiliary object for changing or setting parameters of a second object used in the second game; and a third game execution means that executes the third game, in which at least one of the objects can be used as an object to be controlled in the third game.

A game control device according to another aspect of the present invention is a game control device that provides games including a first game, a second game, and a third game, and includes: a first game execution means that executes the first game, changing or setting parameters of a first object based on a user's operation and storing the changed or set first object in a storage device as an object that can be used in the second game and the third game; a second game execution means that executes the second game, in which at least one of the objects can be used as an auxiliary object for changing or setting parameters of a second object used in the second game; and a third game execution means that executes the third game, in which at least one of the objects can be used as an object to be controlled in the third game.

1 is a schematic block diagram showing an example of the configuration of a game system according to an embodiment of the present invention. FIG. 2 is a schematic block diagram showing an example of the hardware configuration of a game terminal. FIG. 2 is a schematic block diagram illustrating an example of a hardware configuration of a server. FIG. 10 is a diagram showing an example of an event deck display screen. FIG. 10 is a diagram showing an example of an ability list screen of an original character. FIG. 10 is a diagram showing an example of a main screen of a first game mode. FIG. 10 is an explanatory diagram showing an example of a practice screen. FIG. 10 is a diagram illustrating an example of a home screen. FIG. 10 is a diagram showing an example of a map configuration of a second game mode. FIG. 10 is a diagram showing an example of a main screen of a second game mode. FIG. 10 is a diagram illustrating an example of a type of route. FIG. 10 is a diagram illustrating an example of a square information table. FIG. 10 is a diagram showing an example of an item type table for a second game mode. FIG. 10 is a diagram illustrating an example of a contract master table. FIG. 10 is a diagram illustrating an example of a skill table. FIG. 10 is a diagram illustrating an example of a contract selection screen. FIG. 10 is a diagram showing an example of a coach selection screen. FIG. 10 is a diagram showing an example of a player replacement screen in the second game mode. FIG. 10 is a diagram showing an example of an order formation screen for My Team. FIG. 10 is a diagram illustrating an example of an equipment setting screen. FIG. 2 is a schematic functional block diagram showing an example of the functional configuration of the game system. FIG. 10 is a diagram illustrating an example of a user information table. FIG. 10 is an explanatory diagram illustrating an example of a character information table. FIG. 10 is a diagram showing an example of a possessed character table. FIG. 10 is a schematic functional block diagram showing an example of the functional configuration of a second game executing section. FIG. 10 is a schematic functional block diagram showing another example of the functional configuration of the game system. 10 is a flowchart illustrating an example of processing in a first game mode. 10 is a flowchart illustrating an example of processing in a second game mode. 10 is a flowchart illustrating an example of processing in a second game mode. 10 is a flowchart illustrating an example of processing in a second game mode. 10 is a flowchart illustrating an example of processing in a second game mode. 10 is a flowchart illustrating an example of processing in a second game mode. 10 is a flowchart illustrating an example of processing in a third game mode. FIG. 2 is a diagram illustrating an example of map data.

An example of an embodiment of the present invention will be described below with reference to the drawings.

[1. Game System Configuration]
1 is a schematic block diagram showing an example configuration of a game system 1 according to an embodiment of the present invention. This game system 1 includes a plurality of game terminals 10-n (n is a positive integer, 10-1, 10-2, ...) and a server 30. The game terminals 10-n and the server 30 in the game system 1 are connected to each other via a network N such as the Internet so that data can be communicated between them. Here, since the multiple game terminals 10-n have the same configuration, when no particular distinction is needed, they will be simply referred to as "game terminal 10" in the following description.

The network N in this embodiment is not limited to the Internet, but may be, for example, a dedicated line, a public line (telephone line, mobile communication line, etc.), a wired LAN (Local Area Network), a wireless LAN, or a combination of these with the Internet, as long as it can connect the game terminals 10-n and the server 30 within the game system 1 to each other so that they can communicate with each other.

The gaming terminal 10 operated by a user is a computer used by the user to play a game. Examples of gaming terminals 10 include home gaming consoles (stationary or portable), personal computers, smartphones, mobile phone terminals, PHS (Personal Handy-phone System) terminals, personal digital assistants (PDAs), tablet computers, multi-function television sets (so-called smart TVs), and commercial gaming machines installed in gaming facilities, etc.

The server 30 is, for example, a server computer. The server 30 associates information about users' games with user IDs that uniquely identify each user, and stores and manages this information in, for example, a database DB. The database DB may be built within the server 30, or may be built in a server computer separate from the server 30.

Game system 1 allows for computer battles (also called CPU battles) and online battles. In online battles, for example, user A operating game terminal 10-1 and user B operating game terminal 10-2 can play a competitive game via network N. In the case of online battles, for example, game terminals 10-1 and 10-2 matched by server 30 can directly communicate with each other via a P2P (Peer to Peer) connection or the like to compete. Alternatively, data can be exchanged between game terminals 10-1 and 10-2 via server 30. Either method of online battle may be used.

Communication between game terminal 10-n and server 30 can be achieved, for example, by using HTTP (Hyper Text Transfer Protocol), which runs on TCP/IP (Transmission Control Protocol/Internet Protocol), as the base protocol, and implementing the application protocol specified by this system at a higher level.

On the other hand, communication between game terminal 10-1 and game terminal 10-2 connected via P2P or the like can be achieved, for example, by UDP (User Datagram Protocol), a communications protocol on the transport layer of the OSI reference model that is primarily implemented on the IP protocol. UDP is a communications method that sends data to the other terminal device without confirming data delivery or correcting errors, so it has the advantage of low data reliability but high data transfer speed. It is of course also possible to use existing protocols other than UDP for communication between game terminal 10-1 and game terminal 10-2, or to use new protocols that will be defined in the future.

Furthermore, for example, a game terminal 10-n that has short-range wireless communication capabilities using a specific frequency band (e.g., the 2.4 GHz frequency band) can communicate directly with multiple game terminals 10-n to play competitive games, etc.

(Game device hardware configuration)
FIG. 2 is a schematic block diagram showing an example of the hardware configuration of game terminal 10. Game terminal 10 mainly includes a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM (Random Access Memory) 13, an auxiliary storage device 14, a communication unit 15, an operation unit 16, an image processing unit 17, and a sound processing unit 18, which are interconnected via a bus line 19 including an address bus, a data bus, a control bus, etc. Note that interface circuits are interposed between bus line 19 and each component as needed, but are not shown here. Game terminal 10 also includes a display unit 20 and an audio output unit 21.

The CPU 11 interprets and executes commands from the game program, controlling the entire game terminal 10. The ROM 12 stores programs and data necessary for basic operational control of the game terminal 10. The RAM 13 stores various programs and data and provides a working area for the CPU 11.

The auxiliary storage device 14 is a storage device that stores game programs, various data, etc. The auxiliary storage device 14 can be, for example, a non-volatile semiconductor memory, a hard disk drive, a solid state drive, etc.

The communication unit 15 is equipped with a communication interface (not shown) and has a communication control function for communicating data when a game is being played. Here, communication control functions for data communication include, for example, an Internet connection function, a wireless LAN (Local Area Network) connection function, and a short-range wireless communication function using a specific frequency band (e.g., the 2.4 GHz frequency band). The communication unit 15 transmits a connection signal for connecting the game terminal 10 to the network N based on commands from the CPU 11, and also receives information sent from the communication partner and supplies it to the CPU 11.

The operation unit 16 allows the user to input various operation commands into the game terminal 10. Examples of the operation unit 16 include a position input unit with a touch interface (a component of a touch panel), physical buttons, a controller, an analog stick, a keyboard, a pointing device, etc. The operation unit 16 may also be configured to accept voice input by identifying voice input from an audio input unit such as a microphone.

The image processing unit 17 drives the display unit 20 based on image display commands from the CPU 11 to display a game screen. Various known display devices, such as a liquid crystal display or an organic EL (Electro-Luminescence) display, can be used for the display unit 20. The display unit 20 can also be a touch panel that combines a display device such as a liquid crystal display with a position input unit equipped with a touch interface. When the display unit 20 is configured as a touch panel, the image processing unit 17 includes a touch input detection unit (not shown). When a pointer such as a finger or pen touches the screen, this touch input detection unit detects the coordinates of the contact position on the screen and supplies a coordinate signal to the CPU 11. This allows the contact position on the screen of the display unit 20 to be recognized by the CPU 11. The display unit 20 does not need to be integrated with the game device 10; for example, it could be a television monitor or the like externally connected to the game device 10.

The sound processing unit 18 generates an analog audio signal based on sound generation instructions from the CPU 11 and outputs it to the audio output unit 21.

(Server hardware configuration)
3 is a schematic block diagram showing an example of the hardware configuration of the server 30. The server 30 mainly comprises a CPU 31, a ROM 32, a RAM 33, an auxiliary storage device 34, and a communication unit 35, which are interconnected via a bus line 36 including an address bus, a data bus, a control bus, etc. Note that, although an interface circuit is interposed between the bus line 36 and each component as needed, the interface circuit is not shown here.

The CPU 31 interprets and executes commands from the system software and application software, and controls the entire server 30. The ROM 32 stores programs and other data necessary for basic operational control of the server 30. The RAM 13 stores various programs and data, and provides a working area for the CPU 31. The auxiliary storage device 34 is a storage device that stores programs, various data, and other data. The auxiliary storage device 34 can be, for example, a hard disk drive or a solid state drive.

The communication unit 35 has a communication interface (not shown) and controls communication with each game terminal 10-n via the network N. The communication unit 35 also controls communication with other servers (not shown) connected to the network N. For example, if the server 30 is configured as a system incorporated into a social networking service (SNS), the communication unit 35 of the server 30 controls communication with the SNS server. Furthermore, for example, the server 30 controls communication with a video distribution server that distributes game videos played by users to spectators. The server 30 can also be equipped with a video distribution function.

Server 30 can be configured as a single computer, or it can be configured as a functionally distributed system in which the functions of server 30 are distributed across multiple servers. Alternatively, a load-distribution system can be configured by providing multiple servers 30 on network N for redundancy (multiplexing). Server 30 can also be configured as a cloud server that uses cloud computing technology.

Programs and data are supplied to the game terminal 10 or server 30 from a remote location via the network N and stored in RAM 13, auxiliary storage device 14, RAM 33, or auxiliary storage device 34. The game terminal 10 or server 30 may also be provided with components (such as an optical disc drive or memory card slot) for reading programs and data stored on an information storage medium (such as an optical disc or memory card). The programs and data may then be supplied to the game terminal 10 or server 30 via the information storage medium.

In the following, we will assume that the game terminal 10 is a smartphone or tablet computer equipped with a touch panel.

[2. Overview of an example game]
An example of a game is outlined below.
The game system 1 can run a variety of games, regardless of the game format or genre, including sports games (games based on baseball, soccer, tennis, American football, etc.), racing games, fighting games, combat games, digital card games, etc. Note that the games may be run by the game terminal 10 communicating data with the server 30 or another game terminal 10, or may be run by the game terminal 10 alone.

For example, in a baseball game, various game modes, including training and competition, are executed based on one or more objects (e.g., game characters, game cards, game items, etc.). Below, a baseball game themed around baseball will be described as an example of a game executed on game system 1, and other games will also be mentioned as necessary.

In this embodiment, the baseball game can include at least a first game, a second game, and a third game, each with different game content. In this embodiment, a first game mode in which player characters are trained is described as an example of the first game. A second game mode in which team training is performed is described as an example of the second game. A third game mode in which a user competes against other users is described as an example of the third game.

The baseball game of this embodiment may include various other game modes in addition to the first through third games. FIG. 8 shows an example of a home screen G500 for the game of this embodiment. A display area A501 displays a mode selection part P5011 for selecting one of the multiple game modes included in the game. FIG. 8 shows an example in which one game mode can be selected from the first through fifth game modes. The mode selection part P5011 in the center is the currently selected game mode, and in the example of FIG. 8, the second game mode is selected. Swiping the display area A501 left or right switches the selected game mode. The fourth game mode is, for example, a challenge mode in which players can obtain items, points, and the like by completing various presented challenges. The fifth game mode is, for example, an event mode in which players can compete in limited-time events. Various other game modes may also be included.

The first game mode is a character development mode in which the user develops a game character and creates their own original game character. The original character (an example of a first object, an example of an object to be used) created by the user in the first game mode can be used in both the second game mode and the third game mode.

The second game mode is a team development mode in which players develop their team while selectively moving along routes. Original characters created by users in the first game mode can be used as auxiliary objects for changing or setting parameters for player characters (an example of a second object) used in the second game mode.

The third game mode is a battle mode in which a team formed using original characters created by the user in the first game mode battles against an opposing team. The original characters created by the user in the first game mode can be used as objects that can be directly controlled by the user in the third game mode.

Below, we will explain in more detail the first game mode (character development mode), second game mode (team development mode), and third game mode (battle mode).

(2-1. First game mode)
The first game mode will be described in detail below.
In the first game mode, the original character to be trained practices baseball at a high school and is trained as a pitcher or fielder through various events. Note that the first game mode of this embodiment provides multiple scenarios, and the high school the original character attends varies depending on the scenario. In the game of this embodiment, the user selects one of the scenarios to determine the high school the original character attends.

Once a scenario is selected, the user first decides on basic information for their original character. Basic information includes name, position, dominant hand, batting form, and, for pitchers, pitching form. Positions can be selected from pitcher, catcher, first baseman, second baseman, third baseman, shortstop, and outfielder. In the following, positions other than pitcher will be described as fielders.

Once the basic information for the original character has been determined, the event deck is then set up. An event deck is a deck used to set up event characters that will be teammates with the original character as they practice together at the high school they attend. An event character is a character that affects the development of the original character (has a beneficial effect on the user) when an event occurs during the original character's development process, and the user selects event characters to set in the event deck from among their own event characters. Event characters can be obtained as a reward for winning in battle mode or by lottery.

Event characters acquired by a user in the game are associated with the user ID and stored in a storage device (database DB, auxiliary storage device 14, auxiliary storage device 34, etc.) as characters owned by the user, and are managed by game system 1. There is a limit to the number of event characters that each user can own. The basic limit is 50, but this limit can be extended by meeting certain conditions. For example, by spending a certain amount of in-game currency, the limit can be extended by 5. However, there is a set maximum limit, and there is a limit to the number of event characters a user can own. Users can sell event characters they own. When event characters are sold, they are converted into points or in-game currency that can be used in the game.

In addition, users can select one base character and one or more strengthening material characters from among the event characters they own, and strengthen the base character by combining the strengthening material characters with the base character. This strengthening process can increase the level of the event character selected as the base character. On the other hand, event characters used as strengthening material characters will no longer be owned by the user.

By selling or strengthening event characters as described above, the user can adjust the number of event characters they own to within a limit. When an event character owned by a user is sold or used as an strengthening material, the event character is no longer associated with the user's user ID as a character owned by the user. However, information about the event characters owned by the user is stored in a storage device (database DB, auxiliary storage device 14, auxiliary storage device 34, etc.) as the user's ownership history, and information management continues. The game system 1 manages a list of event characters currently owned by the user and event characters owned by the user in the past as encyclopedia information. The user can check the encyclopedia information on the screen at any time by performing a specified operation. Each event character is associated with a name and a rarity (degree of rarity) described below, and event characters with the same name but different rarities exist. Multiple event characters with the same name but different rarities are each managed with different character identification information. Therefore, if the user's ownership history includes event characters with the same name but different rarities, each of those event characters will be included in the encyclopedia information.

Before starting a scenario in the first game mode, it is recommended that the user first raise the level of the event character using the strengthening process described above. This is because the higher the event character's level, the higher the increase in the original character's abilities through practice and the original character's initial evaluation will be, allowing for an advantage in developing the original character.

Figure 4 shows an example of the event deck display screen G100. When setting up an event deck, the display screen G100 shown in Figure 4 is displayed. The deck name is displayed in the display area A110. The user can pre-register the combination of event characters in the event deck before starting the scenario in the first game mode. The change button B1101 is a button for changing the deck name.

The selected event character is displayed in display area A112. For example, up to six event characters can be set in the event deck. Note that event characters are selected from the event characters owned by the user, but some of these can also be selected from the event characters owned by other users (for example, other users associated with the user).

Display area A111 displays the rarity of each event character. Rarity indicates how difficult it is to obtain, and there are six types of rarity: "Normal (N)", "Powerful Normal (PN)", "Rare (R)", "Powerful Rare (PR)", "Super Rare (SR)", and "Powerful Super Rare (PSR)". The rarity increases in order of N, PN, R, PR, SR, and PSR, and the higher the rarity, the greater the benefit when developing an original character, such as when an event occurs. In addition, display area A113 displays the level of the event character.

In addition, each event character may have a favorite practice associated with them, and when they practice that event character's favorite practice together with an original character, the original character may learn tips about their abilities from the event character, or a special practice event may occur.

Display area A114 displays a list of the event character's favorite exercises. Exercise types include "batting," "muscle strength," "base running," "arm strength," "pitch speed," "control," "stamina," "curve ball," "defense," and "mentality." When an event character is set in the event deck, the number of event characters who will become favorite exercises is displayed in display area A115. The example shown in Figure 4 indicates that one event character is set as a favorite exercise for batting, two event characters are set as favorite exercises for strength, one event character is set as a favorite exercise for base running, one event character is set as favorite exercise for arm strength, and one event character is set as favorite exercise for mental strength. Note that one event character may have more than one favorite exercise.

Once the event characters have been set in the event deck as described above, the next step is to select items that can be used in the first game mode. Items can be obtained as rewards for winning in battle mode or by lottery; for example, the user can use up to two items in the first game mode. Types of items include items that increase the event occurrence rate, items that restore stamina, and items that reduce the occurrence of injuries.

Game items include items that can be used in the first game mode, items that can be used in the second game mode (such as contract items) described below, and items that can be used in the third game mode (such as equipment items) described below. The game system 1 manages items for each game mode. There may also be items that can be used in common across all game modes (for example, items that restore points required to play each mode).

Once the selection of game items has been completed as described above, the scenario will begin. Before explaining the contents of the scenario, we will explain the ability values of the original character being trained. Figure 5 shows an example of the ability list screen G200 when an original character is trained as a fielder. An image of the original character is displayed in the display area A210.

Display area A211 displays the name of the original character. Display area A212 displays the position number of the original character. If the position is catcher, the number 2 is displayed, if it is first baseman, 3 if it is second baseman, 4 if it is third baseman, 6 if it is shortstop, 7 if it is left fielder, 8 if it is center fielder, and 9 if it is right fielder.

Display area A213 displays the original character's batting form and dominant hand. Display area A214 displays the original character's position. It is also possible to train an original character to be able to play defense in multiple positions, in which case multiple positions can be displayed.

Display areas A215 to A221 display the player's basic abilities as a fielder. The basic abilities displayed in display areas A216 to A221 are displayed using an eight-level evaluation rank system: S, A, B, C, D, E, F, and G. An ability score of 90 or higher is S, 80 to 89 is A, 70 to 79 is B, 60 to 69 is C, 50 to 59 is D, 40 to 49 is E, 20 to 39 is F, and 19 or lower is G.

Display area A215 displays basic abilities related to "trajectory," which are expressed as an evaluation rank from 1 to 4. The higher the number, the higher the trajectory of the ball when batting, and the more likely it is to hit a home run. Display area A216 displays basic abilities related to "contact," and the higher the "contact" ability, the easier it is to make contact with the ball and score a hit. Display area A217 displays basic abilities related to "power," and the higher the "power" ability, the more likely it is to hit a long hit. Display area A218 displays basic abilities related to "running ability," and the higher the "running ability," the faster the base running will be and the more likely it is to score an infield hit. Display area A219 displays basic abilities related to "shoulder strength," and the higher the "shoulder strength" ability, the faster the ball can be thrown defensively. Display area A220 displays basic abilities related to "defensive ability," and the higher the "defensive ability," the wider the defensive range. Display area A221 displays basic abilities related to "catching," and the higher the "catching" ability, the easier it is to catch the ball defensively and the less likely an error will occur.

Display area A222 displays a list of special abilities related to fielders possessed by the original character. In the example shown in Figure 5, the original character possesses five special abilities: "infield hit," "pinch hit," "inside hit," "throw," and "stable form." In other words, the original character is prone to infield hits, his ability value increases when he appears as a pinch hitter, he excels at "inside hit" when batting, he can throw accurately when defending, and he is in stable form.

In the example shown in Figure 5, the original character is a fielder, so the basic abilities and special abilities related to fielders are displayed. If the original character is a pitcher, the basic abilities and special abilities related to pitchers (e.g., pitch speed, control, stamina, etc.) are displayed.

Next, we will explain the details of the scenario content. As mentioned above, multiple scenarios are available in the first game mode, and we will first explain the content that these scenarios have in common. For example, each scenario consists of four sections, with sections 1 to 3 each consisting of 12 turns, and only section 4 consisting of 15 turns. The user can select practice content for each turn and let the original character rest. Note that since high school baseball preliminaries and high school baseball games at Koshien are included partway through section 4, if the team loses a game and is eliminated, section 4 may be forced to end.

In each turn of each section, multiple teammates appear in addition to the original character, and have a significant impact on the original character's development. Teammates include event characters set in the event deck, event characters predetermined for that scenario, and other default characters (non-event characters). Note that it is also possible to set the same character as a predetermined event character specific to that scenario in the event deck.

In addition, morning and afternoon events may occur with one turn in between, and the events that occur include scenario-specific scenario events, events involving event characters set in the event deck, and events involving predetermined event characters specific to the scenario. Scenario-specific scenario events mainly feature event characters that are predetermined for that scenario. Whether an event occurs in the morning or afternoon is predetermined based on the content of the scenario event and the event characters, and the conditions for each event to occur are determined by winning the event occurrence lottery. When these events occur, the original character is given a development effect that corresponds to the event that occurred. For example, when an event occurs, the experience points needed to increase the original character's ability scores or acquire special abilities can be earned.

Figure 6 shows an example of the main screen G300 for each turn. Display area A301 displays the current section and current turn (number of turns remaining in the current section). Display area A302 displays the original character's current school year, month, and week. Display area A303 displays the original character's current stamina gauge; if you choose to practice that turn, the stamina gauge will decrease, and if you take a rest or go on a date, the stamina gauge will increase. In addition, when menu button P304 is selected, a menu screen is displayed, allowing the user to check settings or pause the scenario.

Display area A305 displays the original character's name and current basic ability evaluation rank. An image P306 of the original character is also displayed near display area A304.

During each turn, the user can choose what to do that turn from multiple command options P307, P308, P311-P313. Note that if option P310 is selected, the turn will not be consumed. Option P309's content varies depending on the type of scenario, with some options consuming a turn and others not. The content of each option will be explained below.

If the "Rest" option P307 is selected, the player will not practice that turn, but will instead rest and recover their stamina. The amount of stamina recovered is determined by lottery. If the "Practice" option P308 is selected, the screen will transition to the practice screen G400 in Figure 7, which will be described later, and the user will then select one of several practice options. Details of the practice options will be described later. Option P309 is a scenario-specific option, and its content will vary depending on the selected scenario.

When the "Improve Ability" option P310 is selected, the user can increase the original character's abilities by using experience points gained through practice and events. In other words, if you want to improve the original character's basic abilities or acquire special abilities, select this option P410 to increase the original character's abilities. When the "Visit the Hospital" option P311 is selected, there is a set probability that the original character's illness will be cured. When the "Play" option P312 is selected, the original character's stamina will be restored, and there is a high probability that the original character's motivation parameter will be increased by one level. When the "Date" option P313 is selected, the original character's stamina will be restored.

Next, we will explain what happens when the "Practice" option P308 is selected. Figure 7 shows an example of the practice screen G400. Note that the example shown in Figure 7 shows a screen in which the "Strength" practice is provisionally selected by the arrow P410. Display area A401 displays the unconsumed experience points earned by the original character. Here, experience points refer to the points needed to improve the aforementioned original character's abilities. Display area A401 does not include experience points consumed by improving the original character's basic abilities or acquiring special abilities. There are five types of experience points: "Strength," "Agility," "Technique," "Curveball," and "Spirit." The type and value of experience points earned vary depending on the practice content. As shown in Figure 7, when "Strength" practice is selected, experience points for "Strength" and experience points for "Spirit" are earned. Furthermore, display area A402 displays the amount of experience points gained when that practice is selected, allowing the user to select the practice content while referring to the amount of experience points gained.

Display area A405 displays the teammates who will be participating in the practice. Teammates are randomly selected from the scenario-specific, predetermined event characters mentioned above, event characters set in the event deck, other default characters, scouts, and managers; the more teammates who participate, the more experience points you will gain. Display area A406 displays the teammate's name and their evaluation value (or relationship level) toward your original character in a gauge. Your original character's evaluation value can be increased by events involving that teammate occurring or by practicing with them. The higher your original character's evaluation value, the more you will acquire tips on special abilities and the greater the increase in experience points. Note that acquiring tips on special abilities reduces the experience points required to acquire that special ability.

Display area A407 displays the favorite practice associated with that teammate. If the ultimately selected practice matches the favorite practice, the player will receive benefits that are advantageous for developing their original character, such as gaining more experience points. In addition, it is possible to practice with up to five teammates, and the teammate combinations corresponding to each practice (content) are drawn by lottery each turn.

In addition, if one of your teammates practicing with you has an event character whose favorite practice matches the selected practice and whose evaluation value relative to your original character is above a certain value, a special practice called special tag practice will be performed. When special tag practice is performed, you can gain more experience points than usual.

Display area A408 displays the injury rate when that practice is selected. The lower the current stamina, the higher the injury rate. The higher the injury rate, the higher the chance that the original character will be injured when practicing. If the character is injured, they will not gain experience points even if they practice.

Different practice content can be selected from options P411 to P416, and the user can perform that practice by, for example, pressing one of options P411 to P416 with a finger or other means. Also, the level of each practice is displayed for each option P411 to P416. The level increases by selecting the same practice multiple times, and the higher the practice level, the more experience points can be obtained.

When the "Strike" option P411 is selected, the experience points required to increase "Meat," one of the original character's basic abilities, are obtained. Specifically, experience points for "Strength," "Technique," and "Spirit," which are displayed in display area A401, are obtained. When the "Strength" option P412 is selected, experience points for "Strength" and "Spirit" are obtained.

When the "Base Running" option P413 is selected, the experience points required to increase "Running Ability," one of the original character's basic abilities, are obtained. Specifically, experience points for "Strength" and "Agility" are obtained. When the "Arm Strength" option P414 is selected, the experience points required to increase "Arm Strength," one of the original character's basic abilities, are obtained. Specifically, experience points for "Strength," "Agility," and "Technique" are obtained.

When the "Defense" option P415 is selected, the experience points needed to increase "Defense," one of the original character's basic abilities, are obtained. Specifically, experience points are obtained for "Agility," "Technique," and "Spirit." When the "Mental" option P416 is selected, the original character's physical strength is restored and experience points are obtained for "Technique" and "Spirit."

Note that the example shown in Figure 7 is for training an original character as a fielder; when training an original character as a pitcher, the practice options P411 to P416 are different, with combinations of "pitch speed," "control," "stamina," "curveball," "defense," and "mentality." The types of experience points are the same as when training an original character as a fielder. Similarly, when training an original character as a pitcher, the types and values of experience points gained vary depending on the practice. For example, if you select "control" practice, you will gain experience points for "technique" and "mentality."

As described above, the experience points gained as a result of practicing and events occurring during the first game mode can be reflected in improving the original character's basic abilities and acquiring special abilities, allowing the original character to be developed. However, the original character's basic abilities may also be improved and special abilities may be acquired based on the results of practicing and events, without the use of experience points.

The basic ability cap for original characters is 100, but if certain conditions are met (for example, if a specific event character is set in the event deck), it is possible to develop original characters with basic abilities that exceed the cap of 100. Basic abilities that exceed the cap are called cap-exceeding basic abilities.

Basically, the development of an original character is completed upon completion of one scenario. Once development is complete, the original character is assessed based on basic abilities, special abilities, etc., and an overall player strength value is calculated. A player rank is determined based on this value. The relationship between the range of overall player strength values and player rank is predetermined. For example, player ranks, from lowest to highest, are G, F, E, D, C, B, A, S, S1-S9, SS, SS1-SS9, PG, PG1-PG9, PF, PF1-PF9, PE, PE1-PE9, PD, PD1-PD9, PC, PC1-PC9, PB, PB1-PB9, PA, PA1-PA9, PS, and PS1-PS9.

The original character whose training has been completed in the first game mode is then associated with the user ID and registered as a character that the user can use in the second game mode and the third game mode. Hereinafter, an original character whose training has been completed and registered in the first game mode will be referred to as a "trained player." After the scenario ends, another trained player can be created by starting the scenario again from the beginning and training the original character. In other words, multiple trained players can be created by repeating the training in the first game mode.

(2-2. Second Game Mode)
The second game mode will now be described.
The second game mode is a team development mode in which players develop their team while selectively moving along paths within a map, and the outline of the second game mode is as follows.

(2-2-1. Overview of the second game mode)
When starting the second game mode, each user is assigned an initial team. The order (members) of the initial team is a fixed order common to all users and is determined by the game management side. For example, the initial order of 25 initial player characters is composed of player characters with relatively low abilities among the player characters provided by the game system 1. Therefore, each user starts with a weak team.

In the second game mode, a map is used with multiple squares that make up a route. Each square is assigned an element for developing the team. The user decides how to develop their team and taps the square on the map where they want to go to develop their team. For example, there is a scout square where an event character can be scouted (acquired) as a member of their team. When this scout square is selected, the original character created by the user in the first game mode can be used as an auxiliary object for changing or setting the parameters of the scouted player character. By adding a scouted player character to the team, the team becomes more powerful and develops. In addition to the scout squares, there are various other squares, such as practice squares and match squares. The team develops through practice and matches. The objective of the second game mode is to develop the player characters on the team through the effects of each square on the map or the effects of items, described below, and build a stronger team. Another objective of the second game mode is to complete the map route the user wants to take. Details about the map and each square are provided below.

Within the map, players can obtain items that will give them an advantage in training in the second game mode. Each item has a cost, and the items that can be taken with them at the start of a stage in the second game mode are limited to the item cost the user possesses. The item cost increases the more the user plays the second game mode. As the item cost of the user increases, the number of "items that can be taken with them" that can be selected at the start of a stage in the second game mode increases, giving them an advantage in training their team. As a result, by repeating the stages in the second game mode, players will be able to clear more difficult stages and develop a stronger team. More details about items will be provided below.

Depending on the strength of the team that has been developed in the second game mode, special equipment items that can be used in the third game mode can be generated. By using these equipment items in the third game mode, the team rank of the user's team in the third game mode can be increased. More details about equipment items will be provided below.

(2-2-2. Teams in the second game mode)
The team to be trained in the second game mode will be described.
Each user starts with a team with a fixed initial order. The initial order consists of, for example, 25 initial player characters (8 starting fielders, 8 reserve fielders, 3 starting pitchers, 5 relief pitchers, and 1 closer). Each initial player character has an initial status and an increase value when its level increases.

Player characters acquired by the user through the effect of the scout squares on the map in the second game mode (hereinafter referred to as "scout players") are generally stronger than initial player characters, and the team grows by adding scout players to the team order. Hereinafter, the act of the user acquiring a player character through the effect of the scout squares may be referred to as "scouting." In this embodiment, event characters are used as scout players. Of all the event characters managed by the game system 1, a predetermined number of event characters are managed as characters that have the potential to become scout players.

For fielders, each player character on the user's team has ability parameters set for trajectory, hitting, power, running ability, arm strength, defensive ability, and catching. In addition, pitchers have ability parameters for pitch speed, control, stamina, and curveballs. A level system is used for the abilities of each player character, whereby abilities improve as the level increases. The level of each player character increases according to the "experience points" earned in the second game mode. Experience points can be increased through the effects of specific squares on the map (for example, comprehensive training squares or game squares, described below). In addition, each player character has a set increase value when leveling up (information on how much each ability value increases with each level increase). In addition, each player character has a set initial level and maximum level.

Initial player characters start at level "1." The maximum level of an initial player character is set to, for example, "20." On the other hand, in the case of scout players, parameters such as initial level, level increase value, and maximum level differ from those of initial player characters. In the case of scout players, parameters such as initial level are determined based on the contract item described below.

In addition, each player character on the user's team is assigned a parameter called a training value to enhance each ability. The training value can be increased by the effects of specific squares on the map (for example, the training squares described below). An upper limit may be set for the training value (for example, a maximum of 50). In addition, each player character on the user's team is assigned a parameter called a special ability.

The batting power of each player character is calculated based on the parameters of trajectory, hitting, power, and the batting value of special abilities. Furthermore, the defensive power of each player character is calculated based on the parameters of running ability, fielding, arm strength, catching, and the defensive value of special abilities. Furthermore, the mobility of each player character is calculated based on the mobility value parameters of running ability and special abilities. Furthermore, the pitching power of each player character is calculated based on the parameters of the pitcher's pitch speed, stamina, control, breaking balls, and the pitching power value of special abilities.

Users can change their team's batting order and positions to organize their lineup. If a player character is set to a position that differs from their appropriate position, a position inappropriate penalty will be incurred. For example, if a player character with the position "first baseman" is placed in a defensive position other than first base, the defensive strength value of the selected character will be lowered as a position inappropriate penalty, compared to when there is no position inappropriateness. As a result, the team's overall strength value will also be lower than when there is no position inappropriateness.

Team overall strength is calculated from the parameters of the team's members. Team overall strength is used, for example, to determine the outcome of a match at a checkpoint square (a square where the result of the square determines whether the game ends). Team overall strength is the sum of team batting strength, team defensive strength, team mobility, and team pitching strength. Team batting strength, team defensive strength, and team mobility are calculated based on the batting strength, defensive strength, and mobility of the team's members, but in this calculation, fielders are rated higher than pitchers, and the eight starting fielders are rated higher than the reserve fielders. Team pitching strength is calculated based on the pitching strength of the pitcher characters belonging to the team, but in this calculation, the pitcher character scheduled to take the mound in the next starting role is rated higher than the other pitcher characters.

However, once a starting pitcher character has started in a game, they are unable to play in a set number of games thereafter. That is, there is a rotation of multiple starting pitcher characters, and the pitcher character scheduled to pitch in the next starting role is different for each game. Therefore, the team pitching strength and overall team strength are recalculated each time a game is played, changing the pitcher character scheduled to pitch in the next starting role. In other words, even if the team's member composition is the same, the overall team strength will differ depending on the pitcher character scheduled to pitch in the next starting role.

The rank of the team's overall strength is also determined according to the value of the team's overall strength. For example, if it is 10,000 or less it is G rank, if it is 10,001 to 15,000 it is F rank, if it is 15,001 to 20,000 it is E rank, etc. The relationship between the range of the team's overall strength value and the rank is predetermined. For example, the ranks, from lowest to highest, are G, F, E, D, C, B, A, S, S1 to S9, SS, SS1 to SS9, PG, PG1 to PG9, PF, PF1 to PF9, PE, PE1 to PE9, PD, PD1 to PD9, etc.

(2-2-3. Map of the second game mode)
The team development game in the second game mode basically progresses by moving through squares arranged within a map (see FIG. 10 ). FIG. 9 shows an example of the map configuration of the entire second game mode. As shown in FIG. 9 , one stage is made up of multiple maps (map 1 to map n). For example, one stage is made up of five maps. Maps may also be referred to as "areas." In this embodiment, stages are also referred to as "quests." When one map within a stage is cleared, the game transitions to the next map. The user selects a carry-in item at the start of the stage and uses the same carry-in item throughout the stage. Note that newly acquired items within a stage can also be used in that stage. Note that carry-in items may be added during a stage if a predetermined condition is met (e.g., if the player wins a match). Team development is completed when one stage is completed. When one stage is cleared, the next stage is unlocked and can be played.

Furthermore, multiple stages (stage 1 to stage n) make up one story. This story is conceptually equivalent to the scenario of the first game mode. Multiple stories may be prepared in advance, allowing the user to select any story. Furthermore, to increase the variety of stories, the game device 10 may be able to download additional stories from the server 30. For example, new stories may be provided from the server 30 periodically (for example, once every three months) or irregularly.

Figure 10 shows an example of the main screen G600 of the second game mode, which displays a map of the current location. The current story name, stage name, and map name are displayed in display area A601 of the main screen G600. The story name may display a name or title corresponding to the content of the story (for example, XX High School Edition). Similarly, the stage name or map name may display a name or title corresponding to the content. Parts P602 and P603 are also displayed in display area A601. Part P602 indicates the number of items picked up within the current map. Part P603 is a menu button. When the menu button P603 is selected, a menu screen is displayed, allowing the user to check the mission or pause the game.

The main screen G600 also displays an order button P604 and an item button P605. When the order button P604 is selected, an order setting screen is displayed, allowing the user to check the team's current order and change the batting order and positions. When the item button P605 is selected, an item confirmation screen is displayed, allowing the user to check the items brought in at the start of the stage and the items acquired after the stage has started.

The main screen G600 also displays a part P606 that displays the current team overall strength value and rank. The display area A607 also displays the current team batting strength, team defensive strength, team mobility, and team pitching strength values.

Furthermore, the map display area A608 of the main screen G600 displays multiple squares P610 and routes P6121-P6125 that make up the map. The map display area A608 displayed on the main screen G600 is a partial area of the map, and the map size can be changed by sliding the slide bar P6141 of the map size change part P614. Furthermore, for example, by double-tapping the map size change part P614 (or by pressing a map confirmation button, not shown), it may be possible to check the map of the entire stage or the map of the entire story.

Each stage begins from the START square on the specified map. The user can move to the next square P610 by selecting the square P610 they want to move to from the current square P610. When they move to the next square P610, an effect occurs according to the type of square P610 they moved to.

A cursor object P611 is placed on the current square P610. When the user selects the square P610 to which they want to move, the cursor object P611 moves to the selected square P610. The cursor object P611 indicating the current position on the map may be a different object, such as an arrow. Alternatively, the current position may be indicated without using an object such as the cursor object P611, by displaying the current square differently from the other squares (for example, by changing the color, density, or shape).

The squares P610 that can be moved to are connected by one of the routes P6121 to P6125. Some squares P610 are connected to multiple other squares P610, in which case you can tap to select which square P610 you want to go to. There are also multiple types of routes P6121 to P6125. Figure 11 shows an example of the types of routes. In the example of map display area A608 in Figure 10, route P6121 is the "normal route," route P6122 is the "victory route," route P6123 is the "defeat route," route P6124 is the "one-way route," and route P6125 is the "locked route." Each route is managed by a route ID that uniquely identifies it.

A normal route is a route that can be traveled in either direction between connected squares. However, when using a normal route, the route previously used cannot be used (you cannot go back). A victory route is a route that forces you to move towards the end point if you win (or succeed) on a square that is connected to the starting point. A defeat route is a route that forces you to move towards the end point if you lose (or fail) on a square that is connected to the starting point. A one-way route is a one-way route that can only be traveled from the starting point to the end point. A locked route is a route that cannot be traveled at the moment, but can become usable when certain conditions are met.

When moving between squares P610, as long as the squares P610 are connected, movement is possible in accordance with the conditions of the routes P6121 to P6125, but is subject to the following restrictions: Only a certain number of squares (e.g., 20 squares) can be moved per map. In other words, the number of turns available per map is limited, with one turn consumed for each square moved. In this embodiment, a maximum of 20 turns is basically set per map. If the map cannot be cleared (reaching the goal square) before the number of turns reaches zero, the game will be forced to end at that point. The number of turns can be increased by bringing in items. Alternatively, for example, the number of turns can be increased by dividing a map into multiple small areas, and a certain number of turns (e.g., 7 turns) can be restored each time each small area is cleared. The number of turns can also be increased or decreased by effects on specific squares P610.

A parameter called a square level is set for squares P610 on the map, and the effect of the square associated with square P610 changes depending on the square level. There are nine square level settings, from "1" to "9" with the lowest level. The higher the square level, the stronger the effect associated with the square. Note that some squares P610 may cause negative effects (effects that are disadvantageous to the user in the game); in such cases, the higher the square level, the less disadvantageous the game may be, or the greater the disadvantage may be.

The mass level of each square P610 on the map is determined by lottery based on a predetermined probability when the game system 1 sets each map before progress on each map begins. Alternatively, before each stage begins, the game system 1 may determine the mass level of each square P610 for all maps included in the stage by lottery based on a predetermined probability.

The mass level may be displayed on each mass P610 so that the user can visually identify the mass level on the map. The display state of each mass P610 may also be changed (for example, by changing the color, density, or shape) depending on the mass level. Alternatively, the mass level may not be displayed on each mass P610 on the map, but when the user performs an operation to provisionally select each mass P610, information about the provisionally selected mass P610 may be displayed in the explanation frame P615 on the main screen G600, on a separate screen, or on a pop-up screen, allowing the user to confirm the mass level of the provisionally selected mass P610.

For maps within the same stage, the probability of drawing the square level is set so that the later the map appears, the higher the square level of square P610 will be, or the more likely it will be that the square level will be high. Also, the later the map appears in the stage, the higher the square level of square P610 will be, or the more likely it will be that the square level will be high.

There are multiple types of squares P610. Figure 12 shows an example of the square information table TBL101. The square information table TBL101 includes fields for "square type ID" and "square type." The square type ID is information that uniquely identifies the square type of each square P610. The square type is the square name that distinguishes each square P610 by type. As shown in Figure 12, squares P610 include types such as START squares, GOAL squares, END squares, blank squares, scout squares, fielder training squares, pitcher training squares, practice squares, special ability squares, match squares, event squares, negative event squares, miracle mass, treasure squares, turn count recovery squares, and turn count reduction squares.

The START square is the starting square of each map, and progression through each map begins from that START square. START squares have no effects, and do not receive any benefits from square levels. There is at least one GOAL square on each map, and reaching it allows you to move to the next map. GOAL squares have no effects, and do not receive any benefits from square levels. However, as described below, effects may be set on START squares or GOAL squares.

Each stage has at least one END square, which, when reached, marks the end of the game. Typically, each stage has multiple END squares. The patterns for reaching an END square include a first arrival pattern, in which the user reaches the END square by performing an operation to move to the END square; a second arrival pattern, in which the player is forced to reach the END square by winning a match on a match square; and a third arrival pattern, in which the player is forced to reach the END square by losing a match on a match square. Depending on the END square reached, the parameters of the player characters on the user's team improve, and the team grows. The END squares of the first or second arrival patterns are set to have a greater effect on improving the parameters of the team's player characters (i.e., a greater effect on team growth) than the END square of the third arrival pattern.

A blank square is a square where nothing happens (i.e. no effect occurs) when you land on it. Once you land on any square P610 in the map and an effect occurs corresponding to that square, the effect disappears and the square becomes a blank square.

Scout squares are squares where you can use contract items to acquire event characters as scout players. More details about these scout squares will be provided later.

Fielder training squares are squares that are associated with the effect of improving the training value of fielder player characters who belong to the user's team. Pitcher training squares are squares that improve the training value of pitcher player characters who belong to the user's team. When landing on a fielder training square or a pitcher training square, a predetermined number of training cards (for example, three) will appear. Multiple training cards of the same type may appear. The training card selected by the user from the multiple training cards that appear will improve the training value of the player character being trained. The number of player characters being trained is basically two on the team (selected randomly or selected by the user), and the number will vary depending on the effects of items brought in by the user (or acquired along the way). The number of training cards that appear is basically three, but the number may vary depending on the effects of items.

Training cards that appear in fielder training squares are, for example, cards for hitting (17%), power (17%), running speed (16%), shoulder strength (16%), fielding (16%), and catching (16%). Training cards that appear in pitcher training squares are, for example, cards for pitch speed (30%), control (30%), stamina (30%), and curveball (10%). The probability in parentheses is the appearance probability of each training card. The appearance probability of each training card may be changed depending on the effect of an item.

Each of the above training cards has a card level. There are nine card levels, from "1" to "9," with the lowest being the lowest. The higher the card level, the greater the training effect (i.e., the greater the training value). When the user selects a training card, the card level is displayed on each training card.

The square levels set for fielder training squares and pitcher training squares affect the card level of the training cards that appear. In other words, the higher the square level, the higher the card level of the training cards that appear. Alternatively, the card level lottery probability is set so that the higher the square level, the more likely it is that the training cards that appear will have a higher card level. Note that the card level of the training cards may also change depending on the effects of items.

Practice squares, also known as general practice squares, are squares that are associated with the effect of increasing the experience points of all fielder or pitcher player characters belonging to the user's team. When landing on a practice square, a predetermined number of practice cards (e.g., three) will appear. Multiple practice cards of the same type may appear. The practice cards that appear are general practice "fielder strengthening" (50%) and general practice "pitcher strengthening" (50%) cards. The probabilities in parentheses are the appearance probability of each practice card. The appearance probability of each practice card may be changed depending on the effects of items.

The practice card that the user selects from the multiple practice cards that appear will increase the experience points of the player character being practiced. If the user selects the "Fielder Strengthening" practice card for the general practice, the experience points of all fielder player characters on the user's team will increase. If the user selects the "Pitcher Strengthening" practice card for the general practice, the experience points of all pitcher player characters on the user's team will increase. The player character's level will increase in accordance with this increase in experience points, and as a result, the player character's abilities will improve.

Each of the above practice cards has a card level. There are nine levels of card levels, from "1" to "9" with the lowest being the lowest. The higher the card level, the greater the effect of practice (i.e., the greater the experience points gained). When the user selects a practice card, the card level is displayed on each practice card.

The square level set for a practice square affects the card level of the practice cards that appear. In other words, the higher the square level, the higher the card level of the practice cards that appear. Alternatively, the card level lottery probability is set so that the higher the square level, the more likely it is that the higher the card level of the practice cards that appear. Note that the card level of practice cards may also change depending on the effects of items.

Special ability squares are squares that are associated with the effect of allowing player characters belonging to the user's team to acquire special abilities (setting special abilities). When the player lands on a special ability square, a predetermined number of special ability cards (for example, three) will appear. Multiple special ability cards of the same type may appear. The default number of special ability cards that appear is three, but this number may vary depending on the effect of the item.

The special ability cards that appear are fielder special abilities (38%), pitcher special abilities (38%), fielder super special abilities (10%), pitcher super special abilities (10%), fielder true special abilities (2%), and pitcher true special abilities (2%). The probability in parentheses is the appearance probability of each special ability card. The appearance probability of each special ability card may be changed by the effects of items. In addition to normal special abilities, there are also the more powerful super special abilities and true special abilities. True special abilities are the most powerful.

Each of the special ability cards mentioned above has a card level set. There are nine card levels, from "1" to "9," with the lowest being the lowest. When a user selects a special ability card, the card level is displayed on each special ability card.

The target player character will learn the special ability associated with the special ability card selected by the user from the multiple special ability cards that appear. The number of player characters who will learn the special ability will vary depending on the card level. The higher the card level, the more player characters will be able to learn the special ability.

A match square is a square where a user's team plays a match against an opposing team. The opposing team may be another user's team, or a fixed team (one of several fixed teams) prepared by the management. In either case, the computer (CPU 11 or CPU 31) automatically controls the player characters of the opposing team to compete against the user's team. Some match squares also have boss battles set up. Boss battle match squares are positioned as checkpoint squares, and the result of that square determines whether the game ends or not. If a player is defeated on a boss battle match square, they are forced to move to the END square, and the game ends. Boss battle match squares have a different visual design (color, darkness, shape, etc.) from other match squares.

Experience points are awarded to the player characters of the user's team depending on the results of the match that is played when the player stops on a match square. The square level set for the match square affects the experience points that the player characters of the team can earn. For example, the experience points that each player character can earn vary depending on the square level, the outcome of the match, and the player character's performance in the match. And, for example, the higher the square level, the higher the multiplier of experience points that can be earned.

Event squares are squares that trigger events that confer advantageous effects in the game. Multiple events can occur on event squares, and each event square is associated with one of these events. The effect varies depending on the associated event. For example, there is an event that increases the experience points of all team members by a specified value, or an event that increases the training points of all team members by a specified value. When an event square is landed on, a scenario occurs that corresponds to the associated event. For example, this scenario may include multiple options (e.g., up to four) that the user can select, and the effect may differ depending on the option selected by the user. The square level set on an event square affects the effect of the event. In other words, the higher the square level, the greater the effect that is advantageous in the game. For example, the higher the square level, the greater the effect that is generated that improves the player character's parameters. Alternatively, the probability of improving parameters is set so that the higher the square level, the more likely it is that the player character's parameters will increase.

A negative event square is a square that causes an event that creates a disadvantage in the game. There are multiple events that can occur on negative event squares, and each negative event square is associated with one of these events. The effect varies depending on the associated event. For example, there are events that reduce the experience points of a certain number of team members by a certain value, reduce the training points of a certain number of team members by a certain value, remove certain special abilities of a certain number of team members, or consume a certain number of turns. The square level set on a negative event square affects the effect of the event. For example, the higher the square level of a negative event square, the less the disadvantageous effect in the game. Alternatively, the higher the square level, the greater the disadvantageous effect in the game.

Miracle Masses are rare and powerful squares that produce special effects that are more effective than event squares. There are multiple effects that can occur in Miracle Masses, and each Miracle Mass is associated with one of these effects. The square level set for a Miracle Mass affects the effect of the Miracle Mass. For example, the higher the square level, the greater the effect that will be advantageous in the game. For example, the higher the square level, the more the effect that will be produced will improve the player character's parameters.

A treasure square is a square from which a player can randomly acquire one of a number of treasure objects. The treasure object may be an object that can be used in the second game mode, or may be an object that can be used in other game modes. Alternatively, it may be an object that cannot be used in the game and is only for collection. For example, a treasure object may be a treasure map. When a user acquires a treasure map, a locked path that can only be unlocked with that treasure map is unlocked. For example, the higher the square level of the treasure square, the rarer the treasure that can be acquired.

A turn count recovery square is a square associated with the effect of increasing the number of turns within the target map by a predetermined number (e.g., 3). For example, the higher the square level of a turn count recovery square, the greater the number of turns that will be increased. Furthermore, a turn count reduction square is a square associated with the effect of decreasing the number of turns within the target map by a predetermined number (e.g., 2). For example, the higher the square level of a turn count reduction square, the fewer turns will be reduced. Alternatively, the higher the square level of a turn count reduction square, the greater the number of turns will be reduced.

Parts P6091 and P6092 are displayed on the left and right edges of the map display area A608 shown in Figure 10. Parts P6091 and P6092 indicate that there is map not displayed on the screen on the left and right sides of the map. The user can check the map areas not displayed on the screen by swiping the map display area A608 on the screen left or right. Note that if there are map areas not displayed on the screen above and below, parts similar to parts P6091 and P6092 will be displayed above and below.

The main screen G600 also displays an explanation frame P615. This explanation frame P615 displays information, lines, or explanatory text that is set in the current square and corresponds to that square. In Figure 10, the user is currently in a square where the next match square can be selected, so an example is shown in which the line "I've been sent a challenge, but I wonder what I should do..." is displayed. Furthermore, when the user provisionally selects the next square, the information, lines, or explanatory text that is set in the provisionally selected square is displayed in the explanation frame P615. The main screen G600 also displays a part P616 that indicates the current number of turns remaining.

Additionally, an item icon P613 may be displayed in a square P610 in the map display area A608. This item icon P613 indicates the presence of a square P610 in the map where an item that the user can acquire is set. For example, the item icon P613 is displayed so as to overlap with part of the square P610 in which the acquireable item is set, or in the vicinity of that square P610. When the player stops on a square P610 where the item icon P613 is displayed, the player can pick up the item set in that square P610. When an item is picked up, the number of items in the part P602, which indicates the number of items picked up in the current map, increases.

(2-2-4. Items for the second game mode)
Here, the items that can be used in the second game mode will be described.
As described above, landing on a specific square P610 allows a player to acquire an item. When constructing each map in a stage (setting the map), the game system 1 sets which square P610 on the map is associated with an acquireable item. The specific square P610 (the location of the square P610) on which the acquireable item is set may be fixed for each map. Alternatively, a lottery with a predetermined probability (for example, a random lottery) may be performed each time a map is constructed to determine the specific square P610 on which an item is set from among the multiple squares P610 on the map. The number of acquireable items set in one map may be fixed (for example, 10), or may not be fixed. For example, the number of acquireable items (i.e., the number of specific squares P610 from which an item can be acquired) may vary depending on the result of the lottery performed when constructing each map.

For each specific square P610 associated with an obtainable item, information about the type and rank range of the obtainable item is set. The "rank" indicates the "rarity" of the item, and the "rank" of an item may also be referred to as "rarity." There are 99 levels of item rank, from 1 to 99. When a ball lands on a specific square P610, the type and rank of the item are determined by lottery based on probability (for example, randomly) based on the information set in that square P610. Furthermore, other parameters of the item are determined based on the rank of the item determined by lottery. In other words, since parameters are set individually for each item in the second game mode each time it is obtained within the map, items with the same item name will have different parameters.

In this embodiment, the lottery for items found within a map is conducted between maps before moving on to the next map. In other words, the timing for determining each item found within a map is after the map is cleared and before the next map begins.

There is a set maximum number of items that can be acquired within a single stage (by exploring the multiple maps that make up the stage). In this embodiment, the maximum number is 40. This is not limited to this, and any maximum number can be set. After the maximum number of items has been acquired within a single stage, no items can be acquired even if the player lands on a specific square P610 that is associated with an acquireable item.

The maximum number of second game mode items that a user can possess is set. In this embodiment, the maximum number that can be possessed is 400, but this is not limited to this. Note that a user can adjust the number of items possessed by selling any item.

In the second game mode, items have their effects when brought in by the user at the start of a stage. Items that can be brought in at the start of a stage are limited to the item cost possessed by the user. However, there is an upper limit to the number of items that can be brought in (15 in this embodiment), and items that exceed this limit cannot be brought in, even if they are within the item cost.

In addition, items acquired within a map after a stage has started will also have an effect within that stage. Items acquired within a map after a stage has started will be valid within that stage, regardless of the item cost or the maximum number that can be brought in. However, since the validity of each item picked up within a map is determined between maps, the item can effectively only be used from the next map onwards. If the user's number of items acquired within a map exceeds the maximum number of 400, they will need to go to the item list screen at that point and sell any items they have in their possession to bring their number of items down to within the maximum.

Figure 13 shows an example of an item type table TBL102 for items in the second game mode. Item type table TBL102 includes fields for "Item Type ID," "Item Type," and "Effect Duration Type." Item type ID is information that uniquely identifies an item type. Item type is a name that distinguishes items by type. Item types include contract items, special training strengthening items, square strengthening items, match items, initial value increase items, and backpack items. Effect duration types include consumable items and permanent items. Contract items and match items are consumable items, while the others are permanent items. Consumable items are items that lose their effect within a stage when used on a scout square or match square within that stage. However, even if a consumable item loses its effect after use in a stage, the item is not lost; the user continues to possess the item and can use it in another stage to exert its effect. Permanent items are items whose effect lasts as long as the stage in which they are brought.

A training enhancement item has the effect of raising the level of a training card for any of the following abilities above normal: hitting, power, running ability, arm strength, defensive ability, catching, pitch speed, control, stamina, or breaking balls. The parameter for the amount (or rate) by which the card's level is raised is determined by lottery when the training enhancement item is acquired. A cell enhancement item also has the effect of raising the level of a specified cell above normal. The parameter for the amount (or rate) by which the cell's level is raised is determined by lottery when the cell enhancement item is acquired. For example, the rank of the item is determined by lottery when a training enhancement item or cell enhancement item is acquired, and the higher the rank, the higher the level of the training card or cell. Alternatively, the level lottery probability may be set so that the higher the determined rank, the more likely it is that the training card or cell will have a higher level.

Match items have the effect of improving the abilities of player characters during matches on match squares. Users can choose whether or not to use match items before a match. Match items can be used only once, and may be used multiple times within the same stage. The parameter for the number of times a match item can be used is determined by lottery when the match item is acquired. For example, the rank of the item can be determined by lottery when the match item is acquired, and the higher the rank, the more times it can be used. Alternatively, the probability of the number of times the item can be used can be set so that the higher the determined rank, the more likely it is to be used.

Initial value increase items have the effect of increasing the initial experience points of all initial player characters that make up the initial team at the start of the stage. The parameter for the amount of increase in initial experience points is determined by lottery when the initial value increase item is acquired. For example, the rank of the item is determined by lottery when the initial value increase item is acquired, and the higher the rank, the greater the amount of increase in initial experience points. Alternatively, the lottery probability may be set so that the higher the determined rank, the greater the increase in initial experience points is likely to be.

Backpack items have the effect of increasing the number of items that can be brought in at the start of a stage. The parameter for the number of items that can be brought in is determined by lottery when acquiring a backpack item. For example, the rank of the item can be determined by lottery when acquiring a backpack item, and the higher the rank, the more items that can be brought in. Alternatively, the item number lottery probability can be set so that the higher the determined rank, the more likely it is that the number of items that can be brought in will be increased.

(2-2-5. Scout Mass and Contract Items)
Scout squares in the map are squares associated with the effect of allowing players to scout player characters other than the initial player characters as members of their team. When the user stops on a scout square in the map, they can use a contract item that they brought with them at the start of the stage or a contract item that they acquired in the map after the stage started. Then, they can scout the player character corresponding to the contract item they used and have it join the user's team.

When a contract item lands on a scout square, it has the effect of allowing you to scout the player character associated with that contract item. In other words, a scout square is a square associated with an effect that allows you to use a contract item.

Figure 14 shows an example of the contract master table TBL103. The contract master table TBL103 includes the following fields: "Item ID," "Item Name," "Event Character," "Initial Level Reference Value," "Limit Level Reference Value," and "Skill." The item ID is identification information that uniquely identifies each contract item. The item name is the name of each contract item. The "Event Character" field indicates the event character (event character ID) associated with each contract item. In this embodiment, event characters are associated with contract items, and event characters can be acquired as scouted players.

In the first game mode, event characters are used to organize the event deck and are used as auxiliary objects for changing or setting the parameters of original characters. On the other hand, in the second game mode, event characters are used as main characters that make up the user's team and can also be controlled objects.

As shown in Figure 14, there are multiple contract items with different associated event characters. In other words, the event characters that can be scouted differ depending on the contract item. The event characters that can be associated with a contract item are a specific group of event characters from all the event characters managed by the game system 1. In this embodiment, the event character groups used depending on the story are fixed, such as specific event character group 1 used in story 1 (see Figure 9), specific event character group 2 used in story 2, etc. For example, each contract item used in story 1 is associated with one of the event characters from specific event character group 1.

The "abilities at level 1" and "ability increase values per level increase" of a scouted event character are determined based on the ability parameters of the event character. Therefore, the "abilities at level 1" and "ability increase values per level increase" of a scouted event character will vary depending on the event character. In this embodiment, the "abilities at level 1" of an event character used in the second game mode are weakened compared to its original abilities (abilities when used in the first game mode). For example, the "basic abilities at level 1" of an event character are calculated by multiplying the original basic ability value by a predetermined coefficient (e.g., 0.5). This takes into account the growth of the event character as the map progresses in the second game mode (i.e., game balance). In addition, the special abilities of a scouted event character are reduced from its original special abilities (special abilities when used in the first game mode). For example, special abilities of a certain rank or higher are deleted.

In addition, the "ability increase value per level increase" for a scouted event character is calculated by multiplying the value of each ability of that event character (hitting ability, power, running ability, arm strength, fielding ability, catching ability, pitch speed, control, stamina, curveball) by a predetermined coefficient (e.g., 0.01).

Note that when an event character associated with a contract item is scouted and joins the user's team, they do not necessarily start at level 1; rather, their level changes depending on the "initial level," one of the contract item's parameters. As described below, this may also change depending on the coach's settings.

The "Initial Level Reference Value," "Limit Level Reference Value," and "Skill" fields in the contract master table TBL103 indicate information about the parameters of a contract item. A contract item has two level parameters: an initial level and a limit level. The initial level and limit level of a contract item are the initial level and limit level set for an event character scouted by the contract item. In other words, the initial level indicates what level an event character associated with a contract item will start at when scouted and joins a user team. The limit level is the upper limit of the level of a scouted event character. After joining a user team, a scouted event character will level up through practice, matches, etc., but can only level up up to the limit level.

The "Initial Level Reference Value" field and "Limit Level" field store the initial level reference value and limit level reference value for each contract item. For example, the limit level when the rarity of the event character associated with a contract item is "Normal (N)" is set as the limit level reference value for that contract. The initial level and limit level of a contract item acquired by a user are determined based on the rank of that item, and the initial level reference value and limit level reference value are referenced at that time. For example, the rank of the item is determined by lottery when acquiring a contract item, and the initial level reference value and limit level reference value are changed so that the higher the rank, the higher the initial level and/or limit level. Alternatively, the level lottery probability can be set so that the higher the determined rank, the more likely it is that the initial level and/or limit level will be higher.

The "Skill" field of the contract master table TBL103 stores information about whether or not an item has skills set. If the "Skill" field is "Yes," this indicates that one or more skills are set for the item. Here, the skills set for an item are parameters for the effects added to the item.

Figure 15 shows an example of skill table TBL104. Skill table TBL104 includes fields for "Skill ID," "Skill Name," "Item Type ID," and "Effect." Skill ID is identification information that uniquely identifies each skill. Skill Name is the name of each skill. The "Item Type ID" field stores the item type ID to which each skill is applied. For example, the skill "Skilled Strike" is applied to the contract item (AK1). Skill parameters are applied not only to contract items but also to other items. Skill parameters are determined by lottery when an item is acquired. The number of skills set for an item may be one, or two or more. The number of skills may be fixed or may vary by lottery. For example, the rank of an item is determined by lottery when an item is acquired, and the higher the rank, the more skills the item will have. Alternatively, the skill number lottery probability may be set so that the higher the determined rank, the more skills the item will likely have.

The "Effect" field indicates the effect of each skill. For example, the skill "Proficient Hitting" is a skill that has the effect that when an event character associated with a contract item is scouted, they will start with a running training value of 20 from the beginning. Also, for example, the skill "Melee Training +" is a skill that has the effect that, after an event character associated with a contract item is scouted and joins the user team, their Melee training value will increase by a specified value each time Melee training is conducted. The skills "Number of Coaches +1" to "Number of Coaches +4" will be discussed later.

When the scout square is selected as the next square P610 to move to on the main screen G600 in FIG. 10 based on user operation, the screen transitions to the contract selection screen G700 shown in FIG. 16. The contract selection screen G700 includes a display area A701. Display area A701 displays a list of information P702 of currently valid contract items. If there is more contract item information P702 than can be displayed in display area A701, a scroll bar P703 is displayed, and the information P702 of the contract item that is not displayed can be displayed on the screen by scrolling the screen. The currently valid contract items displayed in display area A701 are contract items that the user brought in at the start of the stage and contract items that they acquired while progressing through the map after the start of the stage, but have not yet used.

Contract item information P702 includes parts P7021 to P7027. Part P7021 indicates the item name (for example, Player A's contract), part P7022 indicates the item's rank, and part P7023 indicates the cost. Part P7024 indicates the effect of the contract item. This part P7024 displays the name, initial level, and limit level parameters of the scouted event character associated with the contract item P702. In other words, the effect display field allows the user to know the event characters that can be scouted using the contract item, as well as the initial level and limit level of that event character if scouted. Part P7025 indicates the skills associated with the contract item. Part P7026 is a player details button. Tapping this player details button opens a screen displaying details such as the abilities of the scouted event character when they join a team. Part P7027 indicates the player rank of the scouted event character.

The user can select the contract item information P702 they want to use from the multiple contract item information P702 displayed in display area A701 (for example, by tapping on the contract item information P702 of their choice), thereby scouting the event character associated with the selected contract item.

The contract selection screen G700 includes part P704, which allows you to choose not to scout. By tapping this part P704, the scout square processing ends without scouting anyone. Even in this case, one turn will be consumed.

(2-2-6. Coach settings for development players)
If an event character associated with a contract item is scouted in Scout Mass, when the event character (scouted player) joins a team, one or more original characters (trained players) trained in the first game mode can be set as coaches for the scouted player. The number of coaches that can be set varies depending on the contract item, and can be, for example, one to four.

In this embodiment, the number of coaches that can be set varies depending on the skills set in the contract item. The skill "Number of coaches + 1" is a skill that has the effect of increasing the number of coaches by one. Similarly, the skill "Number of coaches + n" is a skill that has the effect of increasing the number of coaches by n. For example, the default number of coaches when no skills are set in the contract item is 0, but by setting skills, it is possible to set one coach for "Number of coaches + 1", two for "Number of coaches + 2", three for "Number of coaches + 3", and four for "Number of coaches + 4". The skills of the contract item are set to any of the skills "Number of coaches + 1" to "Number of coaches + 4".

For example, when an item is acquired, the item's rank is determined by lottery, and the higher the rank, the more likely a skill with a large number of coaches is selected. Alternatively, the skill lottery probability may be set so that the higher the determined rank, the more likely a skill with a large number of coaches is selected.

When a development player is associated with a scout player as a coach, the scout player's parameters are changed or set based on the parameters of the development player. The effects of setting this development player as a coach include effects based on the development player's rank (overall player strength), effects based on the development player's ability values, and effects based on the development player's special abilities. These effects are explained below.

First, we will explain the effect based on the development player's rank (total player strength). When a development player is associated with a scout player as a coach, the higher the development player's rank or total player strength, the more the scout player's initial experience points will increase. This effect is called an "experience point bonus." For example, a scout player's initial experience points are calculated by multiplying the development player's total player strength value by a specified coefficient. When multiple development players are associated with a scout player as coaches, the increase in initial experience points calculated for each development player is added together.

Next, we will explain the effects based on the ability values of development players. When a development player is associated with a scout player as a coach, and that development player has basic abilities that exceed the upper limit, the amount of basic ability value that exceeds the upper limit of "100" is added to the scout player's initial training value. This effect is called an "additional bonus." For example, if the development player's power ability value is 110, "10" will be added to the scout player's initial training value for power. When multiple development players are associated with a scout player as coaches, the increase in the initial training value calculated for each development player will be added together.

Next, we will explain the effects based on the special abilities of development players. When a development player is associated with a scout player as a coach, the scout player is given (referred to as being "transferred") the same special abilities as those possessed by the development player. This effect is called the "transferred special ability bonus." In this embodiment, the number of special abilities transferred is between 0 and 5, and the lottery probability is set so that the higher the player rank of the development player, the more special abilities will be transferred, or the easier it will be for this number to increase.

If a scout player is associated with multiple development players as coaches, the special abilities imparted by each development player will be imparted to the scout player. However, the following restrictions may be placed on the impartation of special abilities. If multiple development player coaches impart the same special ability to a scout player, only one special ability will be imparted. If multiple development players as coaches impart the same type of special ability that is in a higher- and lower-ranking relationship to a scout player, only the higher-ranking special ability will be imparted. For example, "Must Hit Low Balls" and "Low Ball Hitter" are both special abilities of the same type that increase the ball's speed when hitting low balls. "Must Hit Low Balls" is more effective, so "Must Hit Low Balls" is higher and "Low Ball Hitter" is lower. If two development player coaches impart "Must Hit Low Balls" and "Low Ball Hitter" respectively, the scout player will only be imparted with "Must Hit Low Balls." Additionally, if multiple development player coaches impart special abilities with conflicting effects, only one of the special abilities will be imparted. For example, if two development player coaches impart the conflicting special abilities of "low ball hitter" and "high ball hitter," respectively, only one of the special abilities (selected at random, for example) will be imparted. In this case, if one of the conflicting special abilities is superior (for example, the superior "low ball hitter" rather than "low ball hitter"), only the superior special ability will be imparted.

In this embodiment, only development players who play the same position as the scouted player can be set as coaches. Therefore, in the first game mode, you are required to evenly develop original characters for each position.

When a contract item is selected by user operation on the contract selection screen G700 shown in FIG. 16, the scouting of the event character associated with that contract item is confirmed, and then the screen transitions to a coach selection screen for selecting a coach. FIG. 17 shows an example of the coach selection screen G800.

Display area A801 of the coach selection screen G800 displays information about the scouted event character. That is, display area A801 displays the icon of the contract item used, the icon of the scouted event character, the player's name, position, initial level, maximum level, experience points (experience point bar), and information about each ability (trajectory, hitting, power, running ability, arm strength, defensive ability, and catching). Information about each ability includes rank, ability value, and training value. The value (+10) written in parentheses below the ability value indicates the training value.

Display area A802 of the coach selection screen G800 displays a list of information P803 about development players that can be selected as a coach. If there is more information P803 about development players than can be displayed in display area A802, the remaining information P803 can be displayed on the screen by scrolling the screen. The coach selection screen G800 also includes parts P804. Parts P804 are used to change the display order of the information P803 about multiple development players that is displayed in a list. When the user selects part P804, a screen for changing the order is displayed, allowing the user to specify the order. In the example of Figure 17, "Development Order" is specified. Other possible orders include order by experience point bonus, order by ability bonus, etc.

The development player information page 803 displays the development player's icon, player name, player rank, the aforementioned experience point bonus, additional bonuses for each ability, and special ability bonuses that can be taught. Additionally, by pressing and holding the development player information page 803, a detailed display screen for the development player can be opened.

By tapping on any of the development player information P803 from among the multiple development player information P803 in display area A802, the user can select the development player to assign to the coach. A selection mark P805 is displayed on the selected development player information P803, indicating that the player is currently selected. Selecting a development player to assign to the coach changes the scout player's initial level, experience points (experience point bar), and ability information (trajectory, hitting, power, running ability, arm strength, defensive ability, and catching) in display area A801. In other words, the coach's effectiveness according to the selected development player is reflected in the scout player's parameter information in display area A801. Here, the display state of the scout player's parameter information in display area A801 changes to make the changed parameter information easier for the user to understand. For example, the display color of the changed parameter information changes (e.g., from black to red). Alternatively, the display state of the information may be changed by displaying an object such as an up arrow near the changed parameter information or by displaying the improvement amount.

As mentioned above, the number of coaches that can be set varies depending on the contract item used. The user can select up to the maximum number of coaches that can be set, and can only select up to that number of development players.

Tapping the development player information P803 displaying the selection mark P805 again cancels the selection. Parts P806 to P808 are also displayed on the coach selection screen G800. Part P806 is an all-cancel button, and when the user taps part P806, they can cancel all current coach selections. Part P806 is an automatic button, and when the user taps part P807, the game system 1 automatically selects the development player best suited to the coach. For example, the game system 1 selects the development player to be set as the coach in order of the development player with the highest experience point bonus. Part P808 is a confirm button, and when the user taps part P808, the currently selected development player is confirmed as the coach.

After the development player to be set as a coach has been confirmed, the screen transitions to the player replacement screen G900, an example of which is shown in Figure 18. The player replacement screen G900 includes an area A901. This area A901 displays information about the scouted event character. That is, area A901 displays the scouted event character's icon, player name, position, initial level, maximum level, and information about each ability (trajectory, hitting, power, running ability, arm strength, defensive ability, and catching), as well as the icon of the set coach.

Area A903 of the player replacement screen G900 displays the current members of the user's team. The current members of the user's team are displayed divided into starting order members and reserve members. The user taps to select a member from the current team members they wish to remove from the team and replace with a scout player who has recently joined the team. A selection frame P904 is displayed for the member selected by the user to be removed. Figure 18 shows an example in which Player 1 has been selected as the member to be removed. When a member to be removed is selected in area A903, information about that member is displayed in area A902. That is, area A902 displays the icon of the player character to be removed from the team, the player's name, position, current level, maximum level, and information about each ability (trajectory, hitting, power, running ability, arm strength, defensive ability, and catching).

Furthermore, when a member to be removed is selected in area A903, the changes in team rank and overall team strength resulting from the player replacement are displayed in area A905. That is, the current team rank and overall team strength values are displayed on the left side of area A905, and the team rank and overall team strength values when the player is replaced are displayed on the right side.

Part P906 is also displayed on the player replacement screen G900. Part P906 is a confirmation button, and when the user taps part P906, it is confirmed that the currently selected member to be removed will be replaced with a scout player. Note that after part P906 is tapped on the player replacement screen G900, a final confirmation screen may be displayed, and the replacement of team members may be confirmed when the user taps the confirmation button on the final confirmation screen.

(2-2-7. Scouted player parameter changes based on Pokédex information)
When an event character associated with a contract item is scouted in a scout square based on a user's operation, the parameters of the event character (scouted player) when the event character joins a team also change depending on the picture book information associated with the user's user ID. As described above, information on event characters that a user has owned at least once is managed as picture book information in the game system 1. When an event character is scouted, the user's picture book information is referenced. If the user has owned an event character with the same name as the scouted event character at least once in the past, the parameters of the scouted event character are improved compared to when the user has never owned the event character. In this embodiment, if the user has a history of owning an event character with the same name as the scouted player, the parameters of the scouted player's limit level are improved. Note that as a variation, for example, if the user has a history of owning an event character with the same name as the scouted player, the initial level of the scouted player rather than the limit level may be improved, or both the initial level and the limit level may be improved.

The degree of improvement in the scout player's limit level also varies depending on the rarity (degree of scarcity) of the event character that the user has owned. In this embodiment, when the rarity is N, PN, R, or PR, the scout player's limit level is improved by "3 levels." When the rarity is SR, the scout player's limit level is improved by "7 levels." When the rarity is PSR, the scout player's limit level is improved by "10 levels." Effects based on this encyclopedia information (event character possession history information) are referred to as encyclopedia bonuses. As a variation, the degree of improvement in the scout player's parameters may also vary depending on parameters other than the rarity of the event character that the user has owned (for example, ability parameters).

If the user has a history of owning multiple event characters with different rarities that share the same name as a scout player, the effect of the Pokédex bonus will be determined based on the highest rarity among them. For example, if the user has previously owned three versions of an event character with the same name as a scout player - N, SR, and PSR - the PSR rarity will be applied, resulting in an effect of increasing the scout player's limit level by 10 levels. As a variation, the effects of all three rarities - N, SR, and PSR - in the user's ownership history - may be applied.

(2-2-8. Utilizing the team developed in the second game mode)
In the second game mode, team development is completed when a development end condition is met, such as when the player stops on the END square after moving through the map or when there are no more turns remaining before clearing the map. Information about the completed team is stored in association with the user ID. A team developed in the second game mode is referred to as a "development team." Furthermore, if the development team is the best team to date (e.g., the team with the highest overall team strength), the information about the development team can be registered and retained in association with the user ID. This best team status continues even after equipment items are generated in the "Baseball Equipment Crafting Journey" described below. The user can check the information about the development team registered as the best team at any time. Furthermore, after team development is completed in the second game mode, objects usable in the third game mode can be generated based on the development team's parameters. This is described below.

Using the development team, the user can play a game part (or game mode) called "Baseball Equipment Creation Journey." "Baseball Equipment Creation Journey" can be treated as part of the second game mode, or as a separate game mode. "Baseball Equipment Creation Journey" is a game in which the user creates equipment items called baseball equipment from the development team to be used in the third game mode.

In "Baseball Equipment Crafting Journey," multiple stages (or regions) are available to which players can selectively send their training teams. First, the user selects which stage to send their training team to. Each of the multiple stages has its own unique characteristics. For example, there is a first stage where the higher the batting ability of the training team, the more likely it is that higher-performance items will be generated (or the easier it will be to generate them). There is also a second stage where the higher the defensive or pitching ability of the training team, the more likely it is that higher-performance items will be generated (or the easier it will be to generate them). There is also a third stage where the higher the mobility of the training team, the more likely it is that higher-performance items will be generated (or the easier it will be to generate them). There is also a fourth stage where high-performance items can be generated (or the easier it will be to generate them) if the development team's overall abilities (batting ability, defensive ability, pitching ability, mobility) are improved in a balanced manner. These are just examples, and there may be stages with a variety of unique characteristics.

The game progresses in "Baseball Equipment Crafting Journey" as the development team plays up to 50 automatic matches against opposing teams. The opponents are, for example, multiple teams prepared by the game management side. The matches progress automatically as the CPU 11 or 31 of the game system 1 automatically controls the player characters of both teams based on the parameters of the development team and the opposing team. The user can watch the progress of the match, or skip and just look at the match results. Each time the development team wins a match, the opposing team's overall team strength increases, and multiple matches are played automatically until the development team loses a match.

When a development team wins a match, the parameters of the equipment item will improve based on the result. In other words, each time the development team wins a match, the performance of the equipment item will improve little by little. If the development team loses a match, equipment item creation will end at that point.

There are several types of equipment items, and the user can select which type of equipment item to create before sending the training team to the stage. Types of equipment items include bat items, glove items, cleats items, and wristband items. The bat item is an auxiliary object used to change or set the parameters of the baseball team used in the third game mode so that the evaluation value of the batting ability of the baseball team is increased. The glove item is an auxiliary object used to change or set the parameters of the baseball team used in the third game mode so that the evaluation value of the defensive ability and pitching ability of the baseball team is increased. The cleats item is an auxiliary object used to change or set the parameters of the baseball team used in the third game mode so that the evaluation value of the mobility ability of the baseball team is increased. The wristband item is an auxiliary object used to change or set the parameters of the baseball team used in the third game mode so that the evaluation value of all abilities of the baseball team is increased.

When equipment items created by a training team are set (equipped) on a team used in the third game mode, the parameter values used to calculate the team's team rank (or overall team strength) are adjusted, thereby increasing the team rank (or overall team strength).

Equipment items have item ranks based on their performance parameters; for example, in order of decreasing rank, there are white items, brown items, black items, bronze items, silver items, gold items, etc. The higher the item rank of an equipment item, the greater its effect on increasing team rank (or overall team strength).

(2-3. Third Game Mode)
The third game mode will now be described.
The third game mode is a mode in which the development players trained in the first game mode can be used as controllable objects. The user can organize their own baseball team by incorporating the development players trained in the first game mode into the order and compete against baseball teams of other users. The user's team used in the third game mode is referred to as "My Team." The user can increase the team rank and overall team strength of their My Team by repeatedly training in the first game mode to create stronger development players and organize their My Team. Furthermore, as described above, the user can further increase the team rank and overall team strength by setting equipment items created based on the development team trained in the second game mode to their My Team.

When playing the third game mode, users can earn points based on the content and results of the match. For example, users belong to one of multiple leagues with different league levels, and their ranking within the league is determined based on the points they earn, with the league they belong to changing based on their ranking. Users play the third game mode with the aim of achieving a higher ranking or belonging to a higher league level. Users can earn rewards based on their ranking and the league level they belong to.

Figure 19 is an example of the My Team order formation screen G1000. Area A1001 of the order formation screen G1000 displays the current order of My Team. The player characters included in My Team's order are displayed as starting order members and reserve members. To replace a member, drag part P1002, which lists the player's name, to part P1002, which lists the player's name of another member. To replace a member with a development player not included in My Team's current order, drag part P1002 to part P1003 to display the development players that can be replaced. Part P1004 is an automatic button, and when the user taps part P1004, the game system 1 automatically forms the optimal order for My Team. For example, from among multiple development players, the development player with the highest overall player ability for each position is automatically selected.

The My Team order formation screen G1000 includes Part P1005. This Part P1005 is an operation button for equipping My Team with equipment items created based on the development team developed in the second game mode. Tapping Part P1005 transitions to the equipment setting screen G1100, an example of which is shown in FIG. 20. Area A1001 of the equipment setting screen G1100 displays an image of one of the members of My Team, as an image to visually represent the equipment items that have been set for My Team. Note that the equipment items are set not only for the member displayed in area A1001, but for My Team as a whole.

The equipment setting screen G1100 includes parts P1102 to P1106. Part P1102 is a part that indicates the currently set bat item. Part P1103 is a part that indicates the currently set glove item. Part P1104 is a part that indicates the currently set spike item. Part P1105 is a part that indicates the currently set wristband item. Part P1106 is a button for changing each equipment item. For example, tapping part P1106 below part P1102 displays a list of bat items owned by the user, and the user can select one from the list and set it to their team.

In this embodiment, an example is shown in which one bat item, one glove item, one spike item, and one wristband item can be set as equipment items that can be equipped to My Team, but this is not limited to this. For example, it may be possible to set multiple equipment items of the same type. For example, two bat items and two glove items may be set. Also, the upper limit on the number of equipment items that can be equipped to My Team is set to four, but this is not limited to this.

Area A1107 on the equipment setting screen G1100 displays the current equipment effects of the equipment items set for My Team. For example, area A1107 displays the percentage increase in each of team batting power, team defensive power, team mobility, and team pitching power. Additionally, if equipment item settings are changed, area A1108 displays the changes in team rank and overall team power resulting from the change.

The equipment setting screen G1100 also includes a part P1109. The part P1109 is an automatic button, and when the user taps the part P1109, the game system 1 automatically selects the most suitable equipment item and sets it for the player's team. For example, from among multiple equipment items, the equipment item with the highest parameter improvement effect of each type is automatically selected.

Tapping part P1110 on the equipment setting screen G1100 will return to the My Team order formation screen G1000 in Figure 19. My Team order formation and equipment item settings can be made at any time before the start of a match in the third game mode. Normally, whenever a stronger development player is created in the first game mode, the stronger development player is swapped into the My Team order to increase My Team's rank and overall team strength. Also, whenever a more effective equipment item is created in the "Baseball Equipment Crafting Journey" in the second game mode, the more effective equipment item is set in My Team to increase My Team's rank and overall team strength.

Next, an example of a match in the third game mode will be described. When the user selects to start playing the third game mode, a screen is first displayed for selecting multiple (e.g., five) candidate opponent teams. The user selects an opponent from the multiple candidate opponent teams. Candidate opponent teams may be selected randomly from other users' teams, or may be selected from the teams of other users with a user rank similar to the user's.

Once the user has selected the opposing team, they then perform an operation to determine the condition parameters for each member of their My Team and the opposing team. Before determining these condition parameters, the user can also rearrange the My Team order or change the equipment items set for their My Team.

By performing the condition parameter determination operation, the condition parameters of each member of the user's team and the opposing team are determined by lottery. The user can then select a predetermined number of standard items for the third game mode from the standard items they possess to bring with them during the match. These standard items include, for example, a "lock-on bat" that supports the user's batting operations during the match, a "stamina drink" that increases the pitcher's stamina by a predetermined amount, and a "max condition drink" that puts all team members in top form.

These standard items for Game Mode 3 only have specific effects during the match in which they are brought in, and do not change the parameters of My Team's rank or overall team strength. In this respect, they differ significantly from the aforementioned equipment items that can be equipped to My Team. In other words, equipment items have the effect of increasing My Team's rank and overall team strength, and this effect continues as long as they are set in My Team. Furthermore, standard items for Game Mode 3 are consumable items that are deleted once brought into a match and used, and are no longer in the user's possession, whereas equipment items are not deleted even when used, but remain in the user's possession and are associated with the user ID.

After selecting the standard items you will bring into the match, the match will begin.
A match in the third game mode according to this embodiment has two parts: an "automatic progression part" and an "action part", as described below.

An automatic progression part is a part where the game progresses automatically. That is, during an automatic progression part, the game situation is updated without the user having to perform batting or baserunning operations when attacking, or pitching or fielding operations when defending. In other words, during an automatic progression part, the game progress is automatically generated (determined) by the computer based on parameters related to my team (e.g., ability parameters of my team's player characters, etc.) and parameters related to the opposing team (e.g., ability parameters of the opposing team's player characters, etc.). During an automatic progression part, the user will view the game progress automatically generated by the computer.

On the other hand, the action part is when the user performs batting and baserunning operations when attacking, and pitching and fielding operations when defending. That is, during the action part, the player character performs actions in response to the user's operations. In other words, the development players that make up My Team are the objects of control. For example, when attacking, the player character performs batting or baserunning operations in response to the user's operations (batting operations or baserunning operations), and when defending, the player character pitches or fields in response to the user's operations (pitching operations or fielding operations). In this way, during the action part, the game situation is updated based on the user's operations on the player character.

In the baseball game according to this embodiment, the game basically progresses in an automatic progression part, with only an overview of the game progress (game key points) displayed on the screen. Then, only when the game situation reaches a predetermined state during the automatic progression part does the game switch from the automatic progression part to an action part, providing the user with an opportunity to control the player characters.

The above-mentioned "predetermined situation" refers to, for example, a situation where my team has a chance to score (for example, a situation where my team is at bat and there is a runner on third or second base), a situation where my team is likely to create a chance to score (for example, a situation where my team is at bat and there are no outs or runners on base), or a situation where my team is in danger of conceding a run (for example, a situation where the opposing team is at bat and there is a runner on third or second base).

A predetermined number of operation opportunities are provided to the user during a single game. For example, three operation opportunities are provided to the user during a single game. In this case, for example, one operation opportunity is provided between the top of the first inning and the bottom of the third inning, one operation opportunity is provided between the top of the fourth inning and the bottom of the sixth inning, and one operation opportunity is provided between the top of the seventh inning and the bottom of the ninth inning. Note that the number of operation opportunities in a single game is not limited to the above example and may be two or less, or four or more. Furthermore, the number of operation opportunities in a single game does not have to be fixed and may vary from game to game. The timing of the occurrence of operation opportunities is also not limited to the above example. When the action part ends, the action part switches to the automatic progression part, and the game resumes automatic progression.

When the match ends, users will be awarded points based on the match content and results. League rankings reflecting the awarded points will also be displayed.

[3. Functional Configuration of Game System]
Fig. 21 is a schematic functional block diagram showing an example of the functional configuration of the game system 1. As shown in Fig. 21, the game system 1 includes a data storage unit 100. For example, the data storage unit 100 is realized by at least one of a database DB, a ROM 12, a RAM 13, an auxiliary storage device 14, a ROM 32, a RAM 33, and an auxiliary storage device 34. The data storage unit 100 stores data necessary to provide a game.

As a specific example of data stored in the data storage unit 100, the data necessary to provide the baseball game described above will be described. The data storage unit 100 stores user information table TBL111, character information table TBL112, possessed character table TBL113, map-related tables TBL101-TBL104, and map data DT105, among others. Note that the map-related tables (space information table TBL101, item type table TBL102, contract master table TBL103, and skill table TBL104) (see Figures 12-15) have already been described, so their description will be omitted here.

For example, various data for playing a game stored in the data storage unit 100 may be stored in a database (DB) or the auxiliary storage device 34 of the server 30, and when the gaming terminal 10 accesses the server 30, the necessary data may be downloaded to the RAM 13 or the auxiliary storage device 14 of the gaming terminal 10. Information about the results of a game played on the gaming terminal 10 or changes to the data may be transmitted from the gaming terminal 10 to the server 30 in real time or at a predetermined timing, and the data stored in the database (DB) or the auxiliary storage device 34 of the server 30 may be updated as appropriate. Also, for example, necessary data may be stored in the auxiliary storage device 14 of the gaming terminal 10 so that at least a portion of the game can be played offline on each user's gaming terminal 10 without logging in to the server 30.

Figure 22 shows an example of user information table TBL111. The example in Figure 22 shows user information table TBL101, which stores information for one user with user ID "U1." However, user information table TBL111 for all users registered in game system 1 is stored in the data storage unit 100 of game system 1 (e.g., database DB, auxiliary storage device 34, etc.).

User information table TBL111 includes fields such as "User ID," "User Name," "First Game Mode," "Second Game Mode," "Third Game Mode," and "Pokédex Information." The "User ID" field indicates identification information for uniquely identifying each user. The "User Name" field indicates the user's name. The "First Game Mode" to "Third Game Mode" fields store various information related to the current first to third game modes. For example, the "First Game Mode" field stores information such as the original character currently being developed, event deck information (such as the ID of the event character set in the event deck), the current turn, and items for the first game mode possessed by the user. For example, the "Second Game Mode" field stores information such as the current story ID, stage ID, map ID, and items for the second game mode possessed by the user. For example, the "Third Game Mode" field stores information such as the current league level, accumulated points, league ranking, standard items for the third game mode possessed by the user, and equipment items. The "Pokédex Information" field stores information about event characters that the user has owned at least once in the past (such as the event character's profile ID).

Note that although omitted from Figure 22, other fields are also included in user information table TBL111. For example, user information table TBL111 includes fields for various in-game points owned by the user, the user IDs of other users (comrades, friends, etc.) associated with the user's user ID, match history, etc.

Figure 23 shows an example of character information table TBL112. Character information table TBL112 is master data for managing all event characters used in the game provided by game system 1. Initial data for all event characters is stored in character information table TBL112 as reference parameters. For example, character information table TBL112 is stored and managed in the respective storage devices of server 30 and game terminal 10 (e.g., RAM 13, auxiliary storage device 14, RAM 33, auxiliary storage device 34, database DB, etc.). The character information tables TBL112 stored in server 30 and game terminal 10 are basically the same; for example, if the game operator changes character information table TBL112 on server 30, the changed information is distributed from server 30 to game terminal 10 via network N.

The character information table TBL112 includes fields such as "Original ID," "Profile ID," "Name," "Rarity," "Limit Level," "Position," "Ability," and "Event" for each event character.

An original ID is identification information assigned to each event character name (player name). A profile ID is identification information assigned according to the event character's rarity. Event characters with the same name are assigned the same original ID. Event characters with the same name but different rarities are assigned different profile IDs. For example, event characters with the same name but different rarities have only the first digit of their profile IDs that differ. The profile ID is the information that uniquely identifies an event character in the character information table TBL112.

The "Event" field stores information about the event associated with the event character. This information in the "Event" field is used when the event character is set in the event deck in the first game mode. Note that when an event character is used in the second game mode, the effect of triggering an event associated with that event character does not occur, so the information in the "Event" field is not referenced.

Note that, although omitted from Figure 23, other fields are also included in the character information table TBL112. For example, fields such as image information and initial evaluations of event characters are included in the character information table TBL112. The character information table TBL112 also stores information on all characters other than the original characters used in the game (such as the initial characters in the second game mode).

Figure 24 shows an example of the owned character table TBL113. The owned character table TBL113 is data showing information about characters owned by a user (i.e., characters associated with the user's user ID). The example in Figure 24 shows the user information table TBL101, which stores information for one user associated with user ID "U1," but the owned character table TBL113 for all users registered in the game system 1 is stored in the data storage unit 100.

In the owned character table TBL113, characters related to the first game mode and characters related to the second game mode are managed separately. Characters related to the first game mode include event characters acquired by the user through lottery or the like, and training players trained in the first game mode. Characters related to the second game mode include initial player characters assigned to the user at the start of a stage, and scout players scouted within the map after the stage has started.

Owned character table TBL113 includes fields such as "Character ID," "Profile ID," "Parameters," and "Coach." "Character ID" is identification information that uniquely identifies a character owned by a user. For example, a user may acquire multiple event characters with the same name and rarity through a lottery or other means. In this case, the profile IDs of the multiple event characters will all be the same, but each will be assigned a different character ID and associated with the user ID. The "Parameters" field stores information on various parameters for each character. Parameters that change after acquiring a character are also reflected in the "Parameters" field. The "Coach" field is a field exclusively for scouted players, and stores the character ID of a development player who is associated with the scouted player as their coach. Note that, although omitted from Figure 24, other fields are also included in owned character table TBL113. For example, there is a field that stores information on the contract item applied to each scouted player.

The game system 1, server 30, or game terminal 10 of this embodiment provides games including a first game, a second game, and a third game.

Here, the first game, second game, and third game may each be part of a single game, or they may be separate games. That is, the first game, second game, and third game may each be part of a game executed by a single game program, or the first game may be executed by the first game program, the second game may be executed by the second game program, and the third game may be executed by the third game program.

In the baseball game example mentioned above, the first game mode in which an original character is developed is an example of the first game, the second game mode in which a team is developed by progressing through maps is an example of the first game, and the third game mode in which a player competes against other users' teams using their own team, which includes players developed in the first game mode, is an example of the third game.

As shown in FIG. 21, the game system 1 includes a control unit 110. The control unit 110 is realized by the CPU 11 of the game terminal 10 or the CPU 31 of the server 30 executing a game program stored in a storage device (ROM 12, RAM 13, auxiliary storage device 14, ROM 32, RAM 33, auxiliary storage device 34, etc.). Some of the functions of the control unit 110 may be realized by the game terminal 10, and the remaining functions may be realized by the server 30. Alternatively, all of the functions of the control unit 110 may be realized by the server 30, or all of the functions of the control unit 110 may be realized by the game terminal 10.

The control unit 110 includes a first game execution unit 111 (an example of first game execution means), a second game execution unit 112 (an example of second game execution means), and a third game execution unit 113 (an example of third game execution means).

The first game execution unit 111 has a function of executing the first game by changing or setting the parameters of a first object based on user operation and storing the changed or set first object in a storage device as an object that can be used in the second game and the third game.

Here, a "user" refers to, for example, a person who plays a game provided by a game system. For example, user identification information is set for each user, and each user is identified (specified) by the user identification information. "User identification information" is information used to uniquely identify each user. For example, a user ID, a unique username, or an email address are examples of "user identification information."

An "object," such as the first object or the second or third object described below, is something that can be used in a game. For example, a game character, a game card, or a game item is an example of an "object." For example, a game character or game card representing a person such as an athlete, a living thing such as a racehorse, a fictional character or living thing such as a monster, or an inanimate object such as a robot is an example of an "object." Also, for example, an equipment item equipped to a character is an example of an "object." For example, an "object" may be a game character or game card that corresponds to a real person or living thing, or it does not have to correspond to a real person, etc.

An "object parameter" is a parameter set for an object. In other words, an "object parameter" is a parameter associated with an object. An "object parameter" may or may not be a numerical parameter. For example, a parameter indicating the overall ability or performance of an object (e.g., overall ability value, level, etc.) is an example of an "object parameter." For example, a parameter indicating the level of a specific ability or performance of an object (e.g., attack power, defense power, etc.) is an example of an "object parameter." For example, a parameter required to improve an object's ability or performance (e.g., experience points, etc.) is an example of an "object parameter." For example, a parameter indicating the quality of an object's condition (e.g., fatigue level, motivation, etc.) is an example of an "object parameter." For example, rarity, which indicates the rarity of an object, is an example of an "object parameter." For example, information about an object's special ability is an example of an "object parameter." For example, an object's body shape information (height, weight, leg length, hand size, etc.), gender information, etc. may also be included in "object parameters."

Furthermore, "changing parameters" means changing the parameters set for an object. For example, improving or decreasing the parameters set for an object is an example of "changing parameters." In the baseball game example mentioned above, improving the rank and value of the original character's abilities (trajectory, hitting, power, running ability, arm strength, defensive ability, or catching) through training in the first game mode is an example of "changing parameters."

Furthermore, "setting parameters" means, for example, setting parameters that have not yet been set for an object to that object. For example, adding a special ability that the object did not have to that object (for example, associating special ability information with the object) is an example of "setting parameters." In the baseball game example mentioned above, endowing an original character with a special ability through training in the first game mode is an example of "setting parameters."

A "first object" is an object such as a game character, game card, or game item whose parameters are changed or set based on user operations in the first game mode. Here, "user operations" refer to game-related operations performed by the user, such as operating physical buttons, touching the screen, or voice input operations. In the baseball game example mentioned above, an original character developed based on user operations is an example of a "first object."

A "first object whose parameters have been changed or set" refers to a first object whose parameters have been changed or set by playing the first game. In the baseball game example mentioned above, an original character (trained player) whose training has been completed by playing the first game mode is an example of a "first object whose parameters have been changed or set." A "first object whose parameters have been changed or set" is a usable object that can be used in the second game and the third game, which are different from the first game.

Here, an "object to be used" refers to an object that can be used by a user in a game. An "object to be used" may be an object that is used in a game and controlled by the user, or it may not be an object that is controlled. For example, an "object to be used" may be an auxiliary object that affects the parameters of the object to be controlled. An "object to be used" may be used in a variety of games regardless of game format or genre, such as sports games (games based on baseball, soccer, tennis, American football, basketball, ice hockey, volleyball, rugby, etc.), racing games, fighting games, combat games, digital card games, role-playing games, simulation games, adventure games, or training games.

The first game execution unit 111 stores the first object, whose parameters have been changed or set in the first game, in the storage device as an object that can be used in the second game and the third game. In the baseball game example described above, the first game execution unit 111 stores the "development player" (an example of a first object) that was developed in the first game mode in a storage device such as the database DB, auxiliary storage device 14, or auxiliary storage device 34 as an "object" that can be used in the second game mode and the third game mode.

The second game execution unit 112 has the function of executing the second game in which at least one of the use objects can be used as an auxiliary object for changing or setting parameters of a second object used in the second game.

Here, a "second object" refers to an object used in the second game, such as a game character, game card, or game item. A "second object" may be an object used not only in the second game, but also in other games, such as the first game. In the baseball game example mentioned above, an event character used as a scout player in the second game mode is an example of a "second object."

In the baseball game example above, an event character was used as the "second object" used in the second game, but a character other than an event character (for example, a character used only in the second game) may also be used as the "second object."

The aforementioned "auxiliary object" refers to an object used in an auxiliary role to influence the parameters of other objects used in the game. For example, an "auxiliary object" is a so-called "non-player character" that is not directly controlled by the user in the game, but influences the parameters of the "player character" that is the object of control. For example, an "auxiliary object" is associated with another object and changes or sets the parameters of that other object. For example, in a sports game, a character such as a coach or manager that is associated with a player character and improves the player character's parameters is an example of an "auxiliary object." Another example of an "auxiliary object" is an object such as an item that is equipped (associated) with a specific object and has the effect of improving or lowering the parameters of that specific object. Another example of an "auxiliary object" is an object that is set for a group of specific objects and has the effect of improving or lowering the parameters of the entire group. In the baseball game example mentioned above, an example of an "assistant object" would be a "development player" who is associated with a scouted player as a coach in the second game mode and who improves the scouted player's parameters (experience points, training points, etc.) and teaches the scouted player special abilities.

In the baseball game example mentioned above, the second game execution unit 112 executes a game in a second game mode in which a development player can be used as an auxiliary object for a coach to change or set the parameters of a scout player.

The third game execution unit 113 has the function of executing the third game in which at least one of the use objects can be used as an object to be operated in the third game.

Here, an "operable object" is an object that is the target of direct operation by the user within the game. For example, a so-called "player character," a character in the game that the user is responsible for controlling, is an example of an "operable object." An "operable object" can be the object of operation in various game formats, such as a fighting game, a role-playing game, or other formats. An "operable object" may be a single object or multiple objects. For example, in the case of a game in which a user controls one or more game characters to compete against an opponent, those one or more game characters are an example of an "operable object." For example, in the case of a game in which a user controls members of a group (e.g., a team) consisting of multiple game characters to compete against an opponent, the game characters included in that group are an example of an "operable object."

Furthermore, automatic control is performed without user operation until a predetermined situation occurs during the game, and an object that becomes the target of user operation when the predetermined situation occurs is also an example of an "object to be operated." Various situations that can arise during the game can be considered "predetermined situations." In the baseball game example mentioned above, in a match in the third game mode, player characters included in "My Team" are automatically controlled until a predetermined situation occurs (such as a chance to score or a situation where a run is about to be lost), and the user is given the opportunity to operate them when the predetermined situation occurs. In this case, the player characters included in "My Team" are an example of an "object to be operated."

In the example of the baseball game mentioned above, the third game execution unit 113 executes a game in the third game mode in which the development player to be used can be used as a player character included in the "My Team" in the third game mode.

The second game may also be a game that uses a group including multiple initial objects.

Here, a "group" is a group made up of two or more objects. A "group" can also be referred to as a team, group, squad, party, guild, etc. For example, in a baseball game, a baseball team made up of a predetermined number of player characters (e.g., 25 players) who can be on the bench and play in a game is an example of a "group." Also, in a soccer game, a soccer team made up of a predetermined number of player characters (e.g., 18 or 23 players) who can be on the bench and play in a game is an example of a "group."

An "initial object" is an object that is included in a group used in the second game from the start of the second game. In the example of a sports game, an example of an "initial object" would be a player character with a relatively low ability value that makes up the user's team at the start of the second game. For example, the player character that serves as the "initial object" may be fixed, or a different player character may be selected each time the second game is started.

Figure 25 is a schematic functional block diagram showing an example of the functional configuration of the second game execution unit 112. As shown in Figure 25, the second game execution unit 112 can be configured to include an joining unit 1121 (an example of joining means) that causes the second object to join the group when a predetermined condition is met during the second game.

Here, "satisfying a predetermined condition during the second game" means that the game situation becomes a predetermined situation while the second game is in progress. For example, if the user progresses through the second game by selecting a route from among multiple routes, moving to a specific position on the route (or a square or the like located at a specific position) is an example of "satisfying a predetermined condition during the second game." Furthermore, for example, winning a match during the second game or obtaining a predetermined item during the second game may also be considered "satisfying a predetermined condition during the second game."

Furthermore, "adding a second object to a group" means adding the second object as an object constituting a group used in the second game. For example, the second object that joins a group may replace an initial object in the group, or may simply be added to the group without such a replacement. For example, when a second object that joins a group replaces an initial object, an initial object selected by the user from among multiple initial objects may be replaced with the added second object, or a specific initial object may be automatically replaced with the added second object without user selection.

In the baseball game example described above, when the player stops on a scout square on the map while progressing through the map in the second game mode (see FIG. 10) (an example of a case where a predetermined condition is met during the second game), the joining unit 1121 joins an event character (an example of a second object) to the user's team (an example of a group). Note that, while the baseball game described above shows an example in which the user uses a contract item to scout an event character to join the team, as will be described later, it may also be possible to have a player character, such as an event character, join the team simply by stopping on a scout square without using a contract item.

Furthermore, the joining unit 1121 may be configured to have a function of joining the second object associated with the specific object to the group when the specified conditions are met and a valid specific object associated with the user identification information exists.

Here, a "valid specific object associated with user identification information" refers to a specific object possessed by the user and available for use by the user. Here, a "specific object" is an object associated with the second object. In the baseball game example mentioned above, the contract item associated with (or associated with) the event character is an example of a "specific object." In the baseball game mentioned above, of the contract items possessed by the user, the contract item brought in at the start of a stage and the contract item acquired during a stage are examples of "valid specific objects." Without being limited to this example, various conditions can be set for whether a specific object is valid. These conditions will be described later.

If there are multiple valid specific objects, the specific object to be used may be selectable by user operation. Alternatively, the joining unit 1121 may automatically select (for example, randomly select) the specific object to be used from the multiple specific objects, without user operation. Furthermore, if there are multiple valid specific objects, all or some (which may be two or more) of the specific objects may be used.

In the baseball game example mentioned above, if the player stops on a scout square on the map and a valid contract item that was brought in or acquired along the way is present, the joining unit 1121 will join the team with the event character associated with the contract item selected by the user.

As shown in FIG. 25, the second game executing section 112 can be configured to include an associating section 1122 and a parameter managing section 1123 .
The associating unit 1122 has a function of associating the use target with the second object when the second object associated with the specific object joins the group. Here, "associating" refers to storing one piece of information linked to another piece of information. "Associating the use target with the second object" refers to storing the identification information of the use target linked to the identification information of the second object. In the baseball game example described above, associating a development player trained in the first game mode as a coach with a scouted event character is an example of "associating the use target with the second object."

If there are multiple use objects, the user may be able to select the use object to be associated by operation. Alternatively, the associating unit 1122 may automatically select (for example, randomly select) the use object to be associated from among the multiple use objects, without relying on user operation. Furthermore, if there are multiple use objects, all or some (which may be two or more) of the use objects may be associated with the second object.

In the baseball game example mentioned above, when an event character associated with a contract item joins a team, the association unit 1122 associates the character ID of one or more development players selected by the user as coaches with the character ID of the event character. In the baseball game example mentioned above, the number of development players that the user can select as coaches varies depending on the contract item used (for example, 1 to 4), but the number may be fixed, or may be determined by lottery each time (for example, randomly determined from a predetermined number range).

The parameter management unit 1123 has the function of changing or setting the parameters of the second object based on the parameters to be used associated with the second object.

Here, "changing or setting the parameters of a second object based on the parameters of a user object associated with the second object" means changing or setting at least one parameter of the second object based on at least one parameter of the user object when the user object is associated with the second object. In the baseball game example mentioned above, the parameter management unit 1123 changes the initial experience value or initial training value of the scouted player based on the rank, overall player strength, or ability value of the development player associated with the scouted player as his coach, and sets (imparts) a special ability to the scouted player based on the special ability possessed by the development player.

Furthermore, as illustrated in FIG. 26, the control unit 110 of the game system 1 can be configured to include a possession history storage control unit 114. The possession history storage control unit 114 has a function of storing the second objects that have previously been associated with user identification information in a storage device as possession history information of the user.

Here, "the second object that has previously been associated with user identification information" refers to a second object that the user has possessed at least once in the past. In other words, the second object that the user currently possesses and the second object that the user has possessed in the past correspond to "the second object that has previously been associated with user identification information."

Furthermore, "user possession history information" is information for identifying the second object that has previously been associated with user identification information. The ID of the second object can be used as "user possession history information."

In the baseball game example mentioned above, the possession history storage control unit 114 stores information (profile IDs) about event characters currently owned by the user and event characters owned by the user in the past as picture book information (an example of possession history information) in a storage device (database DB, auxiliary storage device 14, auxiliary storage device 34, etc.).

Furthermore, as shown in FIG. 25, the second game execution unit 112 can be configured to include a parameter improvement unit 1124. The parameter improvement unit 1124 has a function of improving the limit level parameters of the second object that has joined the group when it is determined, based on the possession history information, that the second object that has joined the group is the same as a second object that has previously been associated with user identification information.

Here, "identical objects" means that at least one piece of information that can identify the objects is the same. For example, if the "names" of both objects are the same, the two objects may be determined to be the same even if other parameters (such as rarity) are different. Also, two objects with the same ID, including name and rarity, may be determined to be the same.

In the baseball game example mentioned above, the parameter improvement unit 1124 improves the parameters of an event character that has joined the team through scouting if it determines, based on the pictorial book information, that the event character has the same name as an event character that the user has previously owned. In this embodiment, the event characters' names may be determined to be the same, for example, if their original IDs are the same, if all but the last digit of their profile IDs are the same, or if the name information is the same.

Furthermore, the second objects are associated with names and rarity levels, and there are second objects with the same name but different rarities. The parameter improvement unit 1124 can be configured to determine that a second object that has joined the group and a second object that has been associated with user identification information are the same if their names are the same, and to improve the parameters of the former according to the rarity of the latter.

Here, "second object rarity" is a parameter that indicates the degree of difficulty in obtaining the second object in the game. The rarity may indicate the usefulness of the second object in the game. The rarity may also be referred to as rarity, rank, or the like. In this embodiment, the rarity of the event character (N, PN, R, PR, SR, PSR) corresponds to an example of "second object rarity."

Furthermore, with regard to "improving the parameters of a second object that has joined a group in accordance with the rarity," if the user has previously owned multiple second objects of different rarities, any of the following can be applied. The parameter improvement effect may be applied to all or some of the multiple different rarities. For example, the parameters of a second object that has joined a group may be improved based on the highest rarity among the multiple different rarities. Furthermore, for example, the parameters of a second object that has joined a group may be improved based on one or more rarities selected by lottery (e.g., random lottery) from the multiple different rarities.

In the baseball game example mentioned above, as illustrated in Figure 23, there are multiple event characters with the same name (player name) but different rarities. Based on the pictorial book information, the parameter improvement unit 1124 determines that an event character who joined the team through scouting is the same as an event character that the user has previously owned, if both have the same name. If the parameter improvement unit 1124 determines that the two are the same, it improves the limit level of the former according to the rarity of the latter. Also, in the baseball game example mentioned above, if the user has a history of owning multiple event characters with different rarities, the parameter improvement unit 1124 improves the parameters of the event character who joined the team through scouting based on the highest rarity among them.

The second object may also be used in the first game. The first game execution unit 111 may be configured to have a function for executing the first game in which at least one second object associated with user identification information can be used as an auxiliary object for changing or setting parameters of the first object used in the first game.

Here, "second object associated with user identification information" refers to a second object associated with user identification information as a second object currently possessed by the user. In other words, a second object currently possessed by the user in the first game and used as an auxiliary object in the first game is the aforementioned "second object associated with user identification information."

In the baseball game example mentioned above, the first game execution unit 111 executes a training game in which an event character owned by the user can be used as an auxiliary object to change or set parameters of an original character (an example of a first object) used in the first game mode. By using an event character used as an auxiliary object to assist in training an original character in the first game mode as a scout player in the second game mode, the increase in the number of characters in the game can be effectively suppressed and character resources can be used effectively.

Furthermore, as shown in FIG. 26, the control unit 110 of the game system 1 can be configured to include an object generation unit 115. The object generation unit 115 has a function of generating a third object that can be used in the third game based on the parameters of the group whose parameters have been changed or set in the second game.

Here, "a group whose parameter changes or settings have been completed in the second game" refers to a group whose parameter changes or settings have been completed by playing the second game. In the baseball game example mentioned above, the development team whose development has been completed by playing the second game mode is an example of a "group whose parameter changes or settings have been completed."

Furthermore, a "third object" refers to an object used in the third game, such as a game character, game card, or game item. A "third object" may be an object used not only in the third game, but also in other games, such as the first game.

Furthermore, "generating a third object based on the parameters of the group" refers to generating a third object based on at least one parameter of the group. For example, executing a specific game part using the group (i.e., based on the parameters of the group) and generating a third object according to the results of executing the specific game part is an example of "generating a third object based on the parameters of the group." In the baseball game mentioned above, an example was shown in which a game part called "Baseball Equipment Crafting Journey" was executed using a training team and an equipment item was generated according to the results of the game part. Furthermore, generating a third object based on the parameters of the group without executing the specific game part as described above is also an example of "generating a third object based on the parameters of the group." For example, the group may be converted into a third object according to its parameters.

In the baseball game example mentioned above, the object generation unit 115 generates equipment items (such as a bat item) that can be used in the third game mode based on the parameters (hitting ability, defensive ability, pitching ability, mobility, etc.) of the development team that has completed development in the second game mode.

Furthermore, the third object generated by the object generation unit 115 can be used as an auxiliary object for changing or setting parameters of an object to be operated that is used in the third game. Alternatively, the third object generated by the object generation unit 115 can be used as an auxiliary object for changing or setting parameters of a group that includes multiple objects to be operated that are used in the third game.

In the baseball game example mentioned above, the equipment items (such as a bat item) generated by the object generation unit 115 can be used as auxiliary objects for changing the parameters (team rank, overall team strength, etc.) of the player's personal team, which includes multiple development players who are the controllable target in the third game mode.

4. Processing
Next, an example of the processing executed by the game system 1 of this embodiment will be described below. Here, an example of the processing executed by the game system 1 when executing the baseball game described above will be described.

Figures 27 to 33 are flowcharts showing an example of the processing of the game system 1. The processing described below is realized by the control unit 110 (CPU 11 of the game terminal 10 or CPU 31 of the server 30) executing a game program stored in a storage device (ROM 12, RAM 13, auxiliary storage device 14, ROM 32, RAM 33, auxiliary storage device 34, etc.).

FIG. 27 is a flowchart showing an example of the processing of the game system 1 that executes the first game mode.
When the user performs an operation to select a scenario from among multiple scenarios, the control unit 110 determines the scenario to be executed (S100). Note that if there is only one scenario, step S100 can be omitted. Thereafter, the control unit 110 executes an event deck setting process (S102). In step S102, the control unit 110 causes the display unit 20 to display an event deck setting screen, as shown in FIG. 4. On this event deck setting screen, the user can select any event character from among the event characters they own and organize an event deck. Note that the process of step S102 may be performed before the scenario selection in step S100.

After the scenario begins (S104), the user selects a command, such as "practice" or "rest" (S106), to progress through the scenario. After the user selects a command, the control unit 110 executes a lottery process for an event (S108). If a selected event is selected (YES in S110), an event associated with one of the event characters set in the event deck is generated (S112). Alternatively, an event associated with a combination of two or more event characters set in the event deck is generated. The control unit 110 then updates the parameters (experience points, special abilities, etc.) of the original character in accordance with the generated event (S114). In this way, in the first game mode, the event character is used as an auxiliary object for changing or setting the parameters of the original character. The user can spend the granted experience points to improve the original character's basic abilities or acquire special abilities at any time until the character's development is complete.

After step S114, or if step S110 returns NO, the process proceeds to step S116, where the control unit 110 executes the command selected by the user and updates the original character's parameters according to the execution result (S118). Note that in FIG. 27, steps S108 to S114 are performed before the command is executed in step S116, but they may also be performed after the command is executed. The control unit 110 may also generate other events (such as events according to the number of turns).

The control unit 110 then determines whether training has ended (S120). If the answer is NO in step S120, the process returns to step S106, and steps S106 to S120 are repeated until training ends. When training ends due to the end of the scenario, etc. (YES in S120), the control unit 110 registers the training player in association with the user ID (S122). This makes the training player available for use in the second game mode and the third game mode.

Next, an example of the processing of the game system 1 that executes the second game mode will be described. Figures 28 to 32 are flowcharts showing an example of the processing of the game system 1 that executes the second game mode.
To start the second game mode, the user selects a story (S130). For example, by operating the mode selection part P5011 on the game home screen G500 illustrated in FIG. 8 to select the second game mode, a story selection part P5021 for selecting one of multiple stories is displayed in the display area A502. The user selects a story by tapping the selection part P5021 associated with a desired story. The user then selects a stage (S132). Note that if the user can select only one story, step S130 can be omitted. Also, if the user can select only one stage, step S132 can be omitted.

The control unit 110 then sets the initial team to be assigned to the user (S134). In this embodiment, the initial team consists of only 25 initial level 1 player characters. This step S134 may be executed after step S136. The user then selects items to bring before the start of the stage (S136). Here, the items that the user can select are limited to those within the item cost that the user possesses.

Next, the control unit 110 sets a map for the stage (S138). An example of the map data DT105 set by the control unit 110 is shown in Figure 34. The map data DT105 includes fields for "Place ID," "Place Type ID," "Place Type," "Place Level," "Next Movable Square," "Route ID," and "Item Information, etc." The square ID is information that uniquely identifies each square in the map. The "Place Type ID" and "Place Type" fields store information about the square type set for each square (see Figure 12). The "Place Level" field stores information about the square level set for each square. For example, the square level of each square is determined by lottery. The "Next Movable Square" field stores the square ID of the square to which each square can be next moved. Note that multiple square IDs are stored for squares with multiple next movable squares. The "Route ID" field stores a route ID (see Figure 11) that indicates the type of route connected to the next movable square. The "Item Information" field stores the item information set for each square.

The "Item Information" field stores item information only for squares on which an item is placed. The "Item Information" field includes sub-fields: "Item Lottery," "Rank Range," and "Found Flag." The "Item Lottery" field stores multiple items associated with each square and their lottery probability. Figure 34 shows an example in which the match square with square ID "M3" stores item lottery information indicating an 80% probability of winning a contract item and a 20% probability of winning a match item. The "Rank Range" field stores information on the rank range set for an item. For example, if you land on the match square with square ID "M3," the item you can acquire is either a contract item with an 80% chance or a match item with a 20% chance, and the rank of the item you can acquire is selected from a range of 10 to 40. This item lottery is performed between maps (step S190, described below) as described above. The "Found Flag" field stores information about whether an item was found by landing on a square with item information set (for example, "1" for found, "0" for not found). Processing of this "Found Flag" field is performed in step S154, which will be described later.

Before map progression begins, the control unit 110 sets the number of turns (e.g., 30 turns) according to the map (S140). The control unit 110 also causes the display unit 20 to display the map information set in step S138 (S142). As a result, a map like the one shown in FIG. 10 is displayed on the game screen. Thereafter, as shown in FIG. 29, when the next square to move to is selected based on a user operation (YES in S144), the control unit 110 moves the cursor object P611 in FIG. 10 to the selected square P610 (S146).

The control unit 110 then determines whether the square on which the cursor object P611 has stopped is an END square or a GOAL square (S148, S150), and whether item information has been set on the square on which the cursor object P611 has stopped (S152). If item information has been set on the square on which the cursor object P611 has stopped (YES in S152), the control unit 110 performs processing to pick up the item (S154). That is, the control unit 110 records "1" in the record for the target square in the "Pickup Flag" field of the map data DT105 in Figure 34. The control unit 110 also increases the number of items in the part P602, which indicates the number of items picked up within the current map, on the main screen G600 in Figure 10.

Also, as shown in FIG. 30, the control unit 110 determines whether the square the player landed on is a scout square. If it is a scout square (YES in S156), the control unit 110 displays a screen on the display unit 20 for selecting a player to scout (S158). This causes the contract selection screen G700, as shown in FIG. 16, to be displayed. This contract selection screen G700 displays a list of information P702 about currently active contract items (i.e., unused contract items brought in at the start of the stage and unused contract items acquired while progressing through the map). When the user selects a contract item they wish to use from the displayed list of contract items (YES in S160), the control unit 110 executes a process to scout an event character corresponding to the selected contract item (S162). That is, the control unit 110 sets the parameters of the scouted event character (scouted player) based on the item rank, initial level, limit level, and skill information associated with the used contract item. The control unit 110 also stores the scouted player's information in association with the user ID in the data storage unit 100.

Note that the user may choose not to use the contract item; in this case (NO at S160), no scouting processing is performed and the process proceeds to step S180.

After step S162, the control unit 110 causes the display unit 20 to display a screen for selecting a coach to associate with the scout player (S164). This displays the coach selection screen G800 illustrated in FIG. 17. The coach selection screen G800 displays a list of information P803 on development players that the user has trained in the first game mode. The number of development players that the user can select as coaches varies depending on the contract item used. When the user performs an operation to select a development player that they wish to set as a coach from the list of development players (YES in S166), the control unit 110 associates the selected development player with the scout player as a coach and stores the associated development player in the data storage unit 100. The control unit 110 then changes or sets the parameters of the scout player based on the parameters of the development player associated with the scout player (S168). In other words, the control unit 110 changes the scout player's initial experience value or initial training value based on the development player's rank (overall player strength) or ability value as a coach, and sets the scout player's special ability based on the development player's special ability.

Note that the user may choose not to set a coach. In this case (NO in S166), the process proceeds to step S170 in Figure 31 without performing step S168.

In step S170, the control unit 110 determines, based on the pictorial book information, whether or not the user has a history of owning an event character with the same name as the scout player. If the answer is YES in step S170, the control unit 110 increases the scout player's limit level parameters according to the rarity of event characters the user has owned (S172). On the other hand, if the user has not a history of owning an event character with the same name as the scout player (NO in S170), the process of step S172 is not executed and the process proceeds to step S174.

The control unit 110 then performs processing to change the team order in response to the scout player joining the team (S174). In this embodiment, the scout player is replaced with an existing team member. Therefore, the control unit 110 displays a player replacement screen G900, as shown in FIG. 18, on the display unit 20. When the user selects a member to remove from the team order on the player replacement screen G900, the control unit 110 changes the team order by replacing the selected member with the scout player, and stores the information about the changed team order in the data storage unit 100.

The control unit 110 then reflects the results of the processing performed when the ball stops on the scout square described above in the team overall strength, and stores the latest team parameters in the data storage unit 100 (S176). The control unit 110 also reflects the latest team parameters (team rank, team overall strength, team batting strength, team defensive strength, team mobility, and team pitching strength) in the display of the main screen G600 in Figure 10.

Also, if the square that the player stopped on is not an END square, a GOAL square, or a SCOUT square (NO in S156), the control unit 110 proceeds to step S178 in FIG. 30 and performs processing according to the square that the player stopped on. The control unit 110 then proceeds to step S176 in FIG. 31 and reflects the results of the processing according to the square in the team's overall strength.

After step S176, the control unit 110 reduces the number of turns by one (S180) and determines whether the number of remaining turns is 0 (S182). If the number of remaining turns is 0 (YES in S182), map progression ends, and the process proceeds to the ending presentation process of step S196 in FIG. 32. On the other hand, if the number of remaining turns is not 0 (NO in S182), the control unit 110 determines whether the next route to be traveled is a forced route (S184). If the next route to be traveled is a victory route or a defeat route (see FIG. 11), it is a forced route (YES in S184), and the process proceeds to step S146 in FIG. 29. On the other hand, if the result is NO in S184, the process proceeds to step S144 in FIG. 29 and waits for the user to select the next square. The control unit 110 then repeats the above-described processes from step S144 onwards.

If the square where the player stopped is the goal square (YES in S150), the current map has been cleared and the player can move on to the next map. In this embodiment, an item lottery is conducted between maps. The control unit 110 conducts a lottery for items picked up while progressing through the map (S190). For example, the control unit 110 determines the item and its rank by lottery based on the item lottery information and rank range set for the square where the item was picked up (see map data DT105 in Figure 34). The control unit 110 also determines other parameters of the item based on the determined item rank. Note that, for example, if a contract item (item type) is determined by lottery, the event character associated with the contract item is further determined by lottery (for example, by random lottery) (see Figure 14).

Furthermore, with the current map being cleared, the control unit 110 resets the number of turns (S192) and moves on to processing the next map (S194). After that, the process proceeds to step S138 in Figure 28, and the above-mentioned processing is repeated.

Also, if the square where the player stopped is an END square (YES in S148 of FIG. 29), the process proceeds to the ending presentation process in step S196 of FIG. 32. Here, if any items were picked up while progressing through the map, an item lottery is held to determine the item and its parameters (including item rank) to be granted to the user. Note that the END square may be associated with an effect that improves or decreases the team's parameters. In step S196, for example, the control unit 110 displays a predetermined ending presentation on the screen. Note that step S196 may be omitted. With the above, team development in the second game mode is completed (S198), and the control unit 110 stores the development team information in the data storage unit 100 in association with the user ID (S200).

The control unit 110 then determines a reward based on the development team's team rank or overall team strength, etc., and awards it to the user. This reward includes item cost. The second game mode is a lap-based system, and the more times you lap a stage, the more item cost you can earn. As item cost increases, the more items you can bring with you at the start of the stage, and each lap gives you an advantage in developing your team.

The user can also use the development team developed in the second game mode to generate equipment items that can be used in the third game mode. When an operation to generate this equipment item is performed (YES in S204), the control unit 110 executes a process to generate the equipment item based on the parameters of the development team. In this embodiment, the game part called "Baseball Equipment Crafting Journey" described above is executed.

Next, an example of the processing of the game system 1 that executes the third game mode will be described. Fig. 33 is a flowchart showing an example of the processing of the game system 1 that executes the third game mode.
The user can set an order for their My Team, including development players trained in the first game mode, on the My Team order creation screen G1000 illustrated in FIG. 19 (S220). The user can also set equipment items for their My Team on the equipment setting screen G1100 illustrated in FIG. 20 (S222). The control unit 110 updates their parameters (team rank, overall team strength, etc.) based on the equipment items set for their My Team (S224). When the user performs an operation to start a game in the third game mode (YES in S226), the control unit 110 automatically generates a game progress based on parameters related to their My Team and parameters related to the opposing team, and progresses the game (S228). When the game situation reaches a predetermined situation (e.g., a situation where their Team has a chance to score) (YES in S230), the control unit 110 progresses the game based on the user's operation on the development player to be controlled within their My Team (S232). The control unit 110 repeats steps S228 to S234 until the match ends. When the match ends (YES in S234), the control unit 110 awards the user a reward determined based on the match result (S236).

5. Summary
In the game system 1 according to the embodiment described above, a development player whose parameters have been changed or set in the first game mode becomes a "use target" that can be used in the second game and the third game mode. Here, a development player who has become a "use target" can be used as an "auxiliary object" for changing or setting the parameters of a scout player in the second game mode. Furthermore, a development player who has become a "use target" can be used as a player character to be controlled in the third game mode. This increases the variety of ways in which development players who have become "use targets" in other games by executing the first game mode, thereby improving the entertainment value of the game.

In addition, in the game system 1 according to this embodiment, by associating a development player trained in the first game mode as a coach with a scout player in the second game mode, the parameters of the scout player can be improved according to the parameters of the development player. Therefore, the higher the ability parameters of a development player created in the first game mode, the more advantageous the second game mode will be, which can motivate the user to play the first game mode.

In addition, in the game system 1 according to this embodiment, if a user has ever owned an event character with the same name as a scout player, the scout player's parameters can be improved according to the rarity of the event character. In other words, even if a user acquires an event character through a lottery or other means and then disposes of it, for example, by selling it or using it as an enhancement material, the effect of improving the scout player's parameters can still be achieved even after the event character is disposed of, as long as the user has a possession history (the aforementioned encyclopedia information). In particular, if there is a limit on the number of event characters a user can possess, event characters may be disposed of by selling them or other means to adjust the number possessed. Typically, objects that have been disposed of do not continue to provide any in-game benefits after disposal. In contrast, in the game according to this embodiment, even if the user does not currently possess the event character, if the user has a history of having possessed the event character in question, they can create an advantageous situation in the game, and the in-game benefits will continue even after the event character is disposed of.

In addition, the game system 1 according to this embodiment can generate equipment items that can be used in the third game mode based on the parameters of the development team developed in the second game mode. These equipment items are used as auxiliary objects in the third game mode, and can improve the parameters of the user's team (such as team rank) based on the parameters of the equipment item. This can motivate the user to use the equipment items to play the third game mode after playing the second game mode. Furthermore, the more the development team's parameters are improved by playing the second game mode, the more equipment items with higher parameters can be generated, which gives the user an advantage in the third game mode, thereby motivating the user to play the second game mode.

6. Modifications
The present invention is not limited to the above-described embodiments.

[6-1] In the above, no conditions are set for running the second game mode, but for example, the second game mode may not be run unless a predetermined number (e.g., three) or more development players are created in the first game mode.

[6-2] The above describes an example of how a development player trained in the first game mode can be used in the second game mode by associating the development player with a scout player as a coach. However, the variety of uses may be increased as follows. For example, a predetermined number of development players selected by the user from among multiple development players trained in the first game mode may be included as members of the initial team in the second game mode. Furthermore, in the second game mode, when a predetermined condition is met, such as stopping on a specific square while progressing through a map, at least one development player (for example, any of a predetermined number of development players preset by the user before the start of a stage) may be scouted and added to the team. In this case, development players trained in the first game mode can be used in the second game mode as auxiliary objects (coach players) or as controllable objects (scout players).

[6-3] In the above, we have explained an example in which only development players with the same position as the scout player can be set as coaches, but it is also possible to allow development players with a different position from the scout player to be set as coaches. In this case, for example, if the positions are different, the effect of the coach improving parameters may be reduced compared to when the positions are the same.

[6-4] The above example shows that a contract item is required to scout an event character, but it may also be possible to scout an event character by landing on a scout square, regardless of whether or not a contract item is present. An example of this is explained below.

For example, a special item called a "piece of paper" is applied, which allows an event character to be scouted without using a contract. This "piece of paper" is not an item possessed by the user, but when it lands on a scout square, it is displayed together with the contract item on the contract selection screen G700 (see Figure 16). If there is no valid contract item, only the "piece of paper" is displayed on the contract selection screen G700. This "piece of paper" will be displayed on the contract selection screen G700 multiple times, even if it has been used once. An event character that can be scouted is also associated with the "piece of paper." However, the scout target associated with the "piece of paper" is not fixed, but is determined by random lottery from a predetermined group of event characters each time the player lands on a scout square. Furthermore, the scout target associated with the "piece of paper" is specified for each stage (quest). The parameters of an event character scouted by the user by selecting the "piece of paper" are set lower than the parameters when scouted by selecting the contract item (for example, the initial level is fixed to "Level 1"). Scouted players who join a team through "out of paper" may not be able to set development players as coaches.

Alternatively, it may be possible to have a player character, such as an event character, join a team simply by landing on a scout square, without using an item such as a contract item or a "piece of paper." For example, when landing on a scout square, it may be possible to scout one or more event characters selected by random lottery from a predetermined group of event characters.

[6-5] The above example shows how a development player can be associated as a coach with a scouted player when a contract item is used, but it may also be possible to associate a development player as a coach with a scouted player who is scouted without using a contract item. For example, it may also be possible to set a development player as a coach for a scouted player who joins a team using the aforementioned "piece of paper."

[6-6] Regarding the validity of contract items, the following variations can be applied:
For example, a contract item may be valid on the condition that the user has previously possessed an event character identical to (e.g., having the same name as) the event character associated with the contract item. This determination of validity is made based on the aforementioned encyclopedia information. In this case, even if the user acquires a contract item associated with an event character that the user has never possessed before, the contract item cannot be used immediately; the user must obtain the event character in order to use it. This can motivate the user to obtain the event character. As a variation, a contract item may be valid on the condition that the user possesses an event character identical to (e.g., having the same name as) the event character associated with the contract item.

[6-7] Furthermore, various variations can be applied to the specifications of the game using the map of the second game mode. Various specifications of the second game mode will be explained below.
In the above, an example has been described in which a lottery is held between maps (from the end of the current map to the start of the next map) to determine the item the user has picked up while progressing through the maps in the second game mode, but a lottery to determine the item may also be held when the player stops on a specific square where an item is set. Also, instead of determining the item by lottery, a preset item may be assigned to a specific square.

[6-8] The above example shows how the parameters, such as the rank of an item picked up by the user while progressing through a map, are determined by lottery. However, instead of determining item parameters by lottery, the parameters of each item may be predetermined.

[6-9] In the above, we have shown an example in which the mass level of each mass in a map is determined by lottery based on a predetermined probability, but instead of determining the mass level by lottery, the mass level of each mass may be determined in advance. It is preferable that the mass level of at least some of the masses in the same map be different from the mass level of the other masses.

[6-10] The above examples show that START squares and GOAL squares have no effect and do not benefit from square levels, but some kind of effect may be associated with a START square or GOAL square. For example, a START square may be associated with an effect that increases the number of turns determined by lottery. Also, special GOAL squares with associated effects may be set as one of the GOAL squares. For example, a special GOAL square may be associated with an effect that increases the number of turns by a predetermined number (for example, 2) at the start of the next map. Also, for example, all or some of the GOAL squares may be associated with an effect that improves or decreases the parameters of team members. Furthermore, a square level may be set for a START square or GOAL square, and the degree of the effect may vary depending on the square level.

[6-11] In the second game mode, various events may occur in addition to stopping on an event square. For example, an event may occur randomly after a certain number of turns have passed. Also, changes may occur to the map depending on the event that occurs. For example, there is an event in which an item is placed on a random square on the map. Another event is, for example, an event in which a certain number of random squares on the map change to a different square type. Another event is, for example, an event in which the square level of a certain number of random squares on the map is increased or decreased. Another event is, for example, an event in which the positions of all squares on the map are shuffled except for specific squares (START square, GOAL square, END square, etc.).

[6-12] In the second game mode, helper characters that generate advantageous effects in the game may appear on the map. The helper characters may stand on squares, and when they land on a square where the helper character is located, they can obtain an additional effect in addition to the effect of that square. There are multiple types of helper characters, such as those that improve the parameters of team members and those that allow the player to scout one player character. In addition, characters that generate disadvantageous effects in the game (such as lowering parameters) may appear on the map.

[6-13] In the second game mode, enemy characters may appear on the map. For example, the enemy characters may move on the map. For example, the enemy characters may move approximately simultaneously with the movement of the cursor object P611 (see FIG. 10), and when the player encounters the enemy character, a match with a strong opponent may be executed.

[6-14] The above describes an example in which a user can register the best team (e.g., the team with the highest overall team strength) among the training teams developed in the second game mode and check their best team at any time. Users may not only check their best team, but also play a game using the best team. For example, each user may participate in a game event in which their best teams compete against each other. Furthermore, for example, a user may use their best team to compete against the best team of a friend (another user associated with the user's user ID). Furthermore, for example, a user may use their best team to compete against a computer-controlled opponent team at any time.
[6-15] In addition to the best team, one or more development teams developed in the second game mode may be registered and available to the user in the same way as the best team. For example, the user may be allowed to register any development team, regardless of whether it is the best or not. Furthermore, for example, four development teams may be registered, each with the best team batting ability, team defensive ability, team mobility, and team pitching ability. Alternatively, all development teams developed in the second game mode may be allowed to be registered.

[6-16] Although the second game mode has been described above as a game using a map with squares, it is not limited to this. For example, the second game mode may be a game in which the player progresses by moving through a game space without squares, and when the player reaches an object (e.g., a person or object) that replaces a square, an effect similar to that of a square is produced.

[6-17] Although the third game mode has been described above as a game in which a user's personal team competes against another user's personal team, the present invention is not limited to this. For example, the third game mode may be a game in which the user controls one (or a predetermined number of two or more) development players selected by the user from among multiple development players developed in the first game mode. For example, the third game mode may be a game in which development players selected by the user participate in a home run contest. In this case, an equipment item generated based on the development team developed in the second game mode may be set for one (or two or more) development players in the third game mode. In this case, when an equipment item is set for a development player, the development player's parameters, such as their abilities, are changed or set.

[6-18] While the above explanation has primarily focused on the example of a baseball game, the present invention can also be applied to other games. For example, the present invention can be applied to a variety of games, regardless of game format or genre, as long as they "include at least a first game, a second game, and a third game," such as other sports games (games based on soccer, tennis, American football, basketball, ice hockey, volleyball, rugby, etc.), fighting games, combat games, digital card games, role-playing games, simulation games, adventure games, or training games.

[6-19] The gaming terminal 10 and the server 30 can communicate with each other to send and receive various data. Both are information processing devices (computers) equipped with a CPU, ROM, RAM, auxiliary storage device, communication unit, etc., and basically have the same hardware configuration. Therefore, some of the various functions described above may be realized by the CPU 11 of the gaming terminal 10, and the rest may be realized by the CPU 31 of the server 30. Alternatively, all of the various functions described above may be realized by the CPU 11 of the gaming terminal 10. Alternatively, all of the various functions described above may be realized by the CPU 31 of the server 30.

[6-20] Regarding a configuration having a storage control function for storing various information in a storage device, the storage device itself is not included in this configuration, and may be installed anywhere, whether inside or outside game system 1. For example, the storage device may be a storage device within game system 1 (e.g., RAM 13, auxiliary storage device 14, RAM 33, auxiliary storage device 34, database DB, etc.), or a file server (online storage) configured separately from these.

[6-21] The computer-readable program according to this embodiment is recorded on various computer-readable recording media, such as a hard disk, optical disk (CD-ROM, DVD-ROM, etc.), flexible disk, or semiconductor memory, and is read from the recording media and executed by the CPU of a computer that constitutes the game system 1 or game control device. Furthermore, the means for providing the program to a computer is not limited to the recording media mentioned above, and can also be via a communications network such as the Internet.

[7. Notes]
From the above description, the present invention can be understood, for example, as follows: It should be noted 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.

1) A game system (1) according to one aspect of the present invention provides a game (e.g., a baseball game) including a first game (e.g., a first game mode in which an original character is developed), a second game (e.g., a second game mode in which a team is developed), and a third game (e.g., a third game mode in which a match is played), and includes: first game execution means (111) that executes the first game (S100-S122) to change or set parameters of a first object (e.g., an original character) based on a user's operation and stores the changed or set first object in a storage device as an object usable in the second game and the third game; second game execution means (112) that executes the second game (S164-S168) in which at least one object usable can be used as an auxiliary object for changing or setting parameters of a second object used in the second game; and third game execution means (113) that executes the third game (S220-S236) in which at least one object usable can be used as an object to be controlled in the third game.

10) A game control device (10 or 30) according to one aspect of the present invention provides a game (e.g., a baseball game) including a first game (e.g., a first game mode in which an original character is developed), a second game (e.g., a second game mode in which a team is developed), and a third game (e.g., a third game mode in which a match is played), and includes: first game execution means (111) that executes the first game (S100 to S122) by changing or setting parameters of a first object (e.g., an original character) based on a user's operation and storing the changed or set first object in a storage device as an object usable in the second game and the third game; second game execution means (112) that executes the second game (S164 to S168) in which at least one object usable can be used as an auxiliary object for changing or setting parameters of a second object used in the second game; and third game execution means (113) that executes the third game (S220 to S236) in which at least one object usable can be used as an object to be controlled in the third game.

11) A program according to one aspect of the present invention is a program for causing a computer to function as a game system (1) described in any one of 1) to 9) or a game control device (10 or 30) described in 10).

12) An information storage medium according to one aspect of the present invention is a computer-readable information storage medium having the program described in 11) recorded thereon.

13) A control method for a game system (1) or a game control device (10 or 30) according to one aspect of the present invention is a method for controlling a game system (1) or a game control device (10 or 30) that provides a game (e.g., a baseball game) including a first game (e.g., a first game mode in which an original character is developed), a second game (e.g., a second game mode in which a team is developed), and a third game (e.g., a third game mode in which a match is played), the method comprising: changing or setting parameters of a first object (e.g., an original character) based on a user's operation; and controlling the first object that has been changed or set in the second game and The method includes a first game execution step (S100-S122) of executing the first game and storing the first game object in a storage device as a usable object in the third game; a second game execution step (S164-S168) of executing the second game in which at least one of the usable objects is usable as an auxiliary object for changing or setting parameters of a second object (e.g., an event character) used in the second game; and a third game execution step (S220-S236) of executing the third game in which at least one of the usable objects is usable as an object to be controlled in the third game.

According to the aspects 1), 10) to 13) above, a first object whose parameters have been changed or set in the first game becomes a "use object" that can be used in the second game and the third game. Here, the first object that has become a "use object" can be used in the second game as an "auxiliary object" for changing or setting the parameters of a second object. Furthermore, the first object that has become a "use object" can be used as an "operable object" in the third game. This increases the variety of ways in which the first object that has become a "use object" in other games can be used by playing the first game, thereby improving the entertainment value of the games.

2) In one aspect of the present invention, in the aspect described in 1) or 10) above, the second game is a game using a group (e.g., a baseball team) including a plurality of initial objects (e.g., initial player characters), and the second game execution means (112) may include joining means (1121) for joining the second object to the group when a predetermined condition (e.g., a condition of stopping at a scout square) is satisfied during the second game.

According to the aspect described in 2) above, if certain conditions are met during the second game, a new second object can be added to a group that includes the initial object. The group can be strengthened by adding a second object, and the group can be further strengthened by using the "usage object" as an auxiliary object for the second object. In other words, in order to strengthen a group, it is necessary to add a second object to the group, which enhances the game's appeal.

3) In one aspect of the present invention, in the aspect described in 2) above, the joining means (1121) may be configured to, when the predetermined condition is met and a valid specific object (e.g., a contract item) associated with the user identification information (e.g., a user ID) exists, join the second object (e.g., an event character) associated with the specific object to the group (e.g., a baseball team).

According to the aspect described in 3) above, in order for a second object to join a group, the user is required to possess a valid specific object to which the second object is associated, thereby further enhancing the game's appeal.

4) In one aspect of the present invention, in the aspect described in 3) above, the second game execution means (112) may further include: association means (1122) for associating the second object (e.g., an event character) associated with the specific object (e.g., a contract item) with the target of use (e.g., a training player trained in the first game) when the second object (e.g., an event character) associated with the specific object (e.g., a contract item) joins the group (e.g., a baseball team); and parameter management means (1123) for changing or setting parameters of the second object based on parameters of the target of use associated with the second object.

According to the aspect described in 4) above, by associating a target with a second object that has joined a group, the second object can be strengthened based on the parameters of the target. To strengthen the second object, it is important to improve the parameters of the target obtained by playing the first game, which further enhances the playability of the game.
Furthermore, the more the parameters of the target game obtained by playing the first game are improved, the more advantageous the second game becomes, which can motivate the user to play the first game.

5) In one aspect of the present invention, in the aspect described in any of 2) to 4) above, the game system may further include possession history storage control means (114) for storing the second objects that have previously been associated with user identification information (e.g., event characters that the user has previously owned at least once) in a storage device as user possession history information (e.g., picture book information), and the second game execution means (112) may further include parameter improvement means (1124) for improving the parameters of the second object that has joined the group when it is determined, based on the possession history information, that the second object that has joined the group is the same as a second object that has previously been associated with user identification information.

According to the aspect described in 5) above, if the user has ever possessed a second object identical to a second object that has joined a group, the parameters of the second object that has joined the group can be improved. In other words, even if the user acquires a second object and then no longer possesses that second object, for example, by selling it or using it as an enhancement material, the effect of improving the parameters can still occur if there is a history of possession of the second object. In particular, in management-type games, etc., there is often a limit on the number of objects a user can possess, and even if a user acquires an object, they may dispose of the object by selling it or other means to adjust the number of objects they possess. Typically, objects that have been disposed of do not continue to provide any in-game benefits after disposal. In contrast, in the aspect described in 5) above, even if the user does not currently possess the second object, having previously possessed the second object can create an in-game advantage, and in-game benefits continue even after the second object is disposed of.

6) In one aspect of the present invention, in the aspect described in 5) above, the second object (e.g., an event character) is associated with a name and a rarity level, and there are second objects with the same name but different rarities, and the parameter improvement means (1124) may determine that a second object that has joined the group (e.g., a baseball team) and a second object that has been associated with user identification information (e.g., an event character that the user has possessed at least once in the past) are the same if they have the same name, and improve the parameters of the former according to the rarity of the latter.

According to the aspect described in 6) above, if the user has ever owned a second object with the same name as a second object that has joined a group, the parameters of the second object that has joined the group can be improved according to the rarity of the second object that the user has ever owned. Normally, for objects that have been disposed of, there is no continuation of game benefits after disposal, regardless of their rarity. In contrast, the aspect described in 6) above is configured so that the rarity of second objects that have already been disposed of is also used as a game element, achieving a novel gameplay not previously seen.

7) In one aspect of the present invention, in any of the aspects described above in 1) to 6), the second object (e.g., an event character) may also be used in the first game, and the first game execution means (111) may execute the first game in which at least one second object (e.g., at least one event character owned by the user) associated with user identification information can be used as an auxiliary object for changing or setting parameters of the first object (e.g., an original character) used in the first game.

According to the aspect described in 7) above, the second character used as an auxiliary object in the first game is also used in the second game. This allows for effective use of object resources within the game.

8) In one aspect of the present invention, in any of the aspects 1) to 7) above, the present invention may further include object generation means (115) for generating a third object (e.g., an equipment item) that can be used in the third game based on the parameters of the group (e.g., a development team) whose parameters have been changed or set in the second game.

According to the aspect described in 8) above, a third object that can be used in the third game is generated from a group whose parameters have been changed or set by playing the second game. This can motivate the user to play the third game using the third object after playing the second game.

9) In one aspect of the present invention, in the aspect described in 8) above, the third object (e.g., an equipment item) generated by the object generation means (115) may be usable as an auxiliary object for changing or setting parameters (e.g., team rank, team overall strength) of an object to be operated (e.g., a training player trained in the first game) used in the third game or a group (e.g., a baseball team) including multiple such objects to be operated.

According to the aspect described in 9) above, a third object generated by a group completed in the second game can be used as an auxiliary object in the third game to strengthen the group, etc. used in the third game. Here, the more the group's parameters are improved by playing the second game, the higher the performance, etc. of the third object obtained, which gives an advantage in the third game, thereby motivating the user to play the second game.

1...Game system, N...Network, DB...Database, 10...Game terminal, 11...CPU, 13...RAM, 14...Auxiliary storage device, 20...Display unit, 30...Server, 31...CPU, 33...RAM, 34...Auxiliary storage device, 100...Data storage unit, 110...Control unit, 111...First game execution unit, 112...Second game execution unit, 113...Third game execution unit, 114...Ownership history storage control unit, 115...Object generation unit, 1121...Subscription unit, 1122...Association unit, 1123...Parameter management unit, 1124...Parameter improvement unit, TBL101...Place information table, TBL102...Item type table, TBL103...Contract master table, TBL104...Skill table, DT105...Map data, TBL111...User information table, TBL112...Character information table, TBL113...Owned character table

Claims (11)

A game system that provides games including a first game, a second game, and a third game of different types, each having different play content,
a first game executing means for executing the first game by changing or setting parameters of a first object based on a user's operation and storing the changed or set first object in a storage device as an object that can be used in the second game and the third game;
a second game execution means for executing the second game, wherein at least one of the use objects can be used as an auxiliary object for changing or setting parameters of a second object used in the second game;
a third game execution means for executing the third game, wherein the third game is a game in which an operation target object that performs an action in the third game can be operated, and at least one of the use objects can be used as an operation target object used in the third game;
Including,
the second object is also used in the first game,
The first game execution means is a game system that executes the first game in which at least one second object associated with user identification information can be used as an auxiliary object for changing or setting parameters of the first object used in the first game. the second game is a game using a group including a plurality of initial objects,
2. The game system according to claim 1, wherein the second game execution means includes joining means for making the second object join the group when a predetermined condition is satisfied during the second game. The game system described in claim 2, wherein the joining means joins the second object corresponding to the specific object to the group when the specified conditions are met and a valid specific object associated with the user identification information exists. The second game execution means
an associating means for associating the target of use with the second object that has joined the group and is associated with the specific object;
The game system according to claim 3 , further comprising: parameter management means for changing or setting parameters of the second object based on the parameters to be used that are associated with the second object. The method further includes a possession history storage control means for storing the second object that has been associated with the user identification information in a storage device as possession history information of the user,
A game system described in any one of claims 2 to 4, wherein the second game execution means further includes a parameter improvement means for improving the parameters of a second object that has joined the group when it is determined, based on the possession history information, that the second object that has joined the group is the same as a second object that has previously been associated with user identification information. A game system that provides games including a first game, a second game, and a third game of different types, each having different play content,
a first game executing means for executing the first game by changing or setting parameters of a first object based on a user's operation and storing the changed or set first object in a storage device as an object that can be used in the second game and the third game;
a second game execution means for executing the second game, wherein at least one of the use objects can be used as an auxiliary object for changing or setting parameters of a second object used in the second game;
a third game execution means for executing the third game, wherein the third game is a game in which an operation target object that performs an action in the third game can be operated, and at least one of the use objects can be used as an operation target object used in the third game;
Including,
the second game is a game using a group including a plurality of initial objects,
the second game execution means includes joining means for making the second object join the group when a predetermined condition is satisfied during the second game;
The method further includes a possession history storage control means for storing the second object that has been associated with the user identification information in a storage device as possession history information of the user,
the second game executing means further includes parameter improving means for improving a parameter of the second object that has joined the group when it is determined, based on the possession history information, that the second object that has joined the group is the same as a second object that has been associated with user identification information;
The second object is associated with a name and a rarity, and there are second objects with the same name but different rarities;
The parameter improvement means determines that a second object that has joined the group and a second object that has been associated with user identification information are the same if their names are the same, and improves the parameters of the former according to the rarity of the latter. the second object is also used in the first game,
The game system described in claim 6, wherein the first game executing means executes the first game in which at least one second object associated with user identification information can be used as an auxiliary object for changing or setting parameters of the first object used in the first game. A game system as described in any one of claims 2 to 6, further comprising an object generation means for generating a third object that can be used in the third game based on the parameters of the group whose parameters have been changed or set in the second game. A game system that provides games including a first game, a second game, and a third game of different types, each having different play content,
a first game executing means for executing the first game by changing or setting parameters of a first object based on a user's operation and storing the changed or set first object in a storage device as an object that can be used in the second game and the third game;
a second game execution means for executing the second game, wherein at least one of the use objects can be used as an auxiliary object for changing or setting parameters of a second object used in the second game;
a third game execution means for executing the third game, wherein the third game is a game in which an operation target object that performs an action in the third game can be operated, and at least one of the use objects can be used as an operation target object used in the third game;
the second game is a game using a group including a plurality of objects, and object generating means generates a third object that can be used in the third game based on parameters of the group whose parameters have been changed or set in the second game;
Including,
A game system in which the third object generated by the object generation means can be used as an auxiliary object for changing or setting parameters of an object to be operated used in the third game or a group including multiple objects to be operated. A game control device that provides games including a first game, a second game, and a third game of different types, each having different play content,
a first game executing means for executing the first game by changing or setting parameters of a first object based on a user's operation and storing the changed or set first object in a storage device as an object that can be used in the second game and the third game;
a second game execution means for executing the second game, wherein at least one of the use objects can be used as an auxiliary object for changing or setting parameters of a second object used in the second game;
a third game execution means for executing the third game, wherein the third game is a game in which an operation target object that performs an action in the third game can be operated, and at least one of the use objects can be used as an operation target object used in the third game;
Including,
the second object is also used in the first game,
The first game execution means is a game control device that executes the first game in which at least one second object associated with user identification information can be used as an auxiliary object for changing or setting parameters of the first object used in the first game. A program for causing a computer to function as the game system described in any one of claims 1 to 9 or the game control device described in claim 10.