KR102865009B1 - Game system, game control device, program, recording medium, and control method - Google Patents

Abstract

The reception department accepts applications for participation in the competition game. The management department manages multiple targets that can be used in the competition game by users who have accepted applications through the reception department, by storing them in a memory device. The selection department randomly selects, based on the same selection conditions, from among the multiple targets managed by the management department, the targets that can be used in the competition game, and which are associated with the user identification information of each user who will be competing against each other.

Description

Game system, game control device, program, recording medium, and control method

This application claims priority from Japanese Patent Application No. 2021-108487, filed with the Japan Patent Office on June 30, 2021, the entire contents of which are incorporated herein by reference.

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

Games have been known for a long time in which users use groups of multiple objects to compete against other users. For example, a baseball game is known in which users select their favorite player characters from among multiple player characters owned within the game, form a team, and compete against an opposing team (e.g., Patent Document 1).

Japanese Patent No. 5612634

In the aforementioned games, each user tends to prioritize popular objects or objects with high ability values, which can easily lead to bias in the objects used in the game. For example, in games that mimic real-world sports, many users only use objects that correspond to popular real-world players or teams that correspond to popular real-world teams, resulting in bias in the objects and teams used in competitive games. This leads to a proliferation of matches between popular players or between popular teams.

Therefore, one of the purposes of the present invention is to provide a game system, a game control device, and a program that can realize a highly interesting game by eliminating the bias of objects used in a battle game or the bias of a group composed of multiple objects.

A game system according to one aspect of the present invention is a game system that provides a game in which a user can participate in a specific battle game, and includes: a reception means for receiving participation in the battle game; a management means for storing in a storage device a plurality of use objects that can be used in the battle game by a user whose participation has been accepted by the reception means; and a selection means for randomly selecting, based on the same selection condition, from among the plurality of use objects managed by the management means, the use objects that can be used in the battle game, which are associated with user identification information of each user who is to be a battle opponent.

A game control device according to another aspect of the present invention is a game control device that provides a game in which a user can participate in a specific battle game, and includes: a reception means for receiving participation in the battle game; a management means for storing in a storage device a plurality of use objects usable in the battle game by a user whose participation has been received by the reception means; and a selection means for randomly selecting, based on the same selection condition, from among the plurality of use objects managed by the management means, the use objects usable in the battle game, which are associated with user identification information of each user who becomes a battle opponent.

Figure 1 is a schematic block diagram showing an example of the configuration of a game system according to one embodiment of the present invention.
Figure 2 is a schematic block diagram showing an example of the hardware configuration of a game terminal.
Figure 3 is a schematic block diagram showing an example of a server's hard configuration.
Figure 4 is an explanatory diagram showing an example of a competition information table.
Figure 5 is an explanatory diagram showing an example of a game screen in communication battle mode.
Figure 6 is an explanatory diagram showing an example of a competition selection screen.
Figure 7 is an explanatory diagram showing an example of a message screen.
Figure 8 is a drawing showing an example of a menu screen of a player random cup.
Figure 9 is a drawing showing an example of a character information table.
Figure 10 is a diagram showing an example of a team information table.
Figure 11 is a drawing showing an example of selection conditions for a pitcher character.
Figure 12 is a drawing showing an example of the selection conditions for a beast player character.
Figure 13 is a drawing showing another example of conditions for selecting a player character.
Figure 14 is a drawing showing another example of the selection conditions for player characters.
Figure 15 is a drawing showing another example of the selection conditions for player characters.
Figure 16 is a diagram showing an example of a user team table.
Figure 17 is a diagram showing another example of a user team table.
Figure 18 is a drawing showing an example of a summary screen of the results of the match.
Figure 19 is a schematic functional block diagram showing an example of the functional configuration of a game terminal.
Figure 20 is a diagram showing an example of a user information table.
Figure 21 is a schematic functional block diagram showing an example of the functional configuration of a server.
Figure 22 is a diagram showing an example of a user management table.
Figure 23 is an explanatory diagram showing an example of a battle management table.
Figure 24 is a diagram showing an example of a character selection condition table.
Figure 25 is a diagram showing an example of randomly selected character data.
Figure 26 is a diagram showing an example of a team selection condition table.
Figure 27 is a diagram showing an example of randomly selected team data.
Figure 28 is a sequence chart showing an example of processing of the game system.
Figure 29 is a flowchart showing an example of another process of the game system.
Figure 30 is a sequence chart showing another example of processing of the game system.
Figure 31 is a flowchart showing another example of processing of the game system.

Hereinafter, an example of an embodiment of the present invention will be described with reference to the drawings.

[1. Game System Configuration]

Fig. 1 is a schematic block diagram showing an example of the 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) within the game system (1) are connected to each other via a network N such as the Internet so as to enable data communication. Here, since the plurality of game terminals (10-n) have the same configuration, unless specifically distinguished, they are simply described as "game terminals (10)".

The network N of the present embodiment is not limited to the Internet, and 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, etc., or a combination of the Internet and these, as long as the game terminal (10-n) and the server (30) within the game system (1) can be connected to each other in a communicative manner.

A game terminal (10) operated by a user is a computer used by the user to play a game. The game terminal (10) is, for example, a home game console (stationary or portable), a personal computer, a smartphone, a mobile phone terminal, a PHS (Personal Handy-phone System) terminal, a portable information terminal (PDA: Personal Digital Assistant), a tablet computer, a multi-function television receiver (so-called smart television), a business (commercial) game console installed in an amusement facility, etc.

The server (30) is, for example, a server computer. The server (30) associates each user with a user ID for unique identification, and stores and manages information about the user's game, for example, in a database (DB). The database (DB) may be constructed within the server (30) or may be constructed within a server computer separate from the server (30).

In addition, the server (30) executes a process for determining an opponent (so-called matching process) when a communication match (online match) is conducted between users. In a communication match, for example, a user A operating a game terminal (10-1) and a user B operating a game terminal (10-2) can conduct a competition game via network N. In this communication match, for example, there is a method for conducting a competition through direct communication between a game terminal (10-1) and a game terminal (10-2) matched by the server (30) through a P2P (Peer to Peer) connection. Alternatively, there is also a method for conducting a communication match by exchanging data between the game terminal (10-1) and the game terminal (10-2) via the server (30). The communication match may be conducted in either method.

Communication between a game terminal (10-n) and a server (30) can be realized by, for example, using HTTP (Hyper Text Transfer Protocol) operating on TCP/IP (Transmission Control Protocol/Internet Protocol) as a base protocol, and implementing an application protocol specified in this system on top.

Meanwhile, communication between a game terminal (10-1) and a game terminal (10-2) connected via P2P, etc., can be realized, for example, by UDP (User Datagram Protocol), which is a communication protocol on the transport layer of the OSI reference model and is mainly implemented on the IP protocol. The above-mentioned UDP is a communication method that continuously sends data to the terminal device of the other party without performing data delivery confirmation or error correction, so although the data reliability is low, it has the advantage of a high data transmission speed. In addition, it is of course possible to use an existing protocol other than UDP for communication between the game terminal (10-1) and the game terminal (10-2), or to use a new protocol that will be newly defined in the future.

In addition, for example, in a game terminal (10-n) having a short-range wireless communication function using a predetermined frequency band (e.g., a frequency band of 2.4 GHz), direct communication can be performed between a plurality of game terminals (10-n) to execute a battle game, etc.

(Hardware configuration of the game terminal)

Fig. 2 is a schematic block diagram showing an example of the hardware configuration of a game terminal (10). The 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 memory device (14), a communication unit (15), an operation unit (16), an image processing unit (17), and a sound processing unit (18), which are connected to each other via a bus line (19) including an address bus, a data bus, and a control bus. In addition, an interface circuit is interposed between the bus line (19) and each component as necessary, but the illustration of the interface circuit is omitted here. In addition, the game terminal (10) includes a display unit (20) and a sound output unit (21).

The CPU (11) interprets and executes commands of the game program and controls the entire game terminal (10). The ROM (12) stores programs and data necessary for basic operation control of the game terminal (10). The RAM (13) stores various programs and data and secures a work area for the CPU (11).

The auxiliary memory device (14) is a memory device that stores game programs and various data. For example, a non-volatile semiconductor memory, a hard disk drive, a solid state drive, etc. can be used as the auxiliary memory device (14).

The communication unit (15) has a communication interface (not shown) and a communication control function for data communication when the game is executed. Here, the communication control function for data communication includes, for example, an Internet connection function, a wireless LAN (Local Area Network) connection function, and a short-range wireless communication function using a predetermined frequency band (e.g., a frequency band of 2.4㎓). The communication unit (15) transmits a connection signal for connecting the game terminal (10) to the network N based on a command from the CPU (11), and also receives information transmitted from the communication counterpart and supplies it to the CPU (11).

The control unit (16) is for inputting various operation commands of the user into the game terminal (10). Examples of the control unit (16) include a position input unit (component of a touch panel) equipped with a touch interface, a physical button, a controller, an analog stick, a keyboard, a pointing device, etc. In addition, the control unit (16) may be configured as a voice input capable control unit (16) by identifying a voice input from a voice input unit such as a microphone.

The image processing unit (17) drives the display unit (20) based on an image display command 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 applied to the display unit (20). Furthermore, the display unit (20) can be a touch panel that combines a position input unit equipped with a touch interface with a display device such as a liquid crystal display. When the display unit (20) is configured as a touch panel, the image processing unit (17) is equipped with a touch input detection unit (not shown). This touch input detection unit detects the coordinates of the contact position on the screen when a pointer such as a finger or a pen touches the screen and supplies a coordinate signal to the CPU (11). Thereby, the contact position on the screen of the display unit (20) is recognized by the CPU (11). The display unit (20) need not be integrated with the game device (10), and may be, for example, a television monitor externally connected to the game device (10).

The sound processing unit (18) generates an analog voice signal based on pronunciation instructions from the CPU (11) and outputs it to the voice output unit (21).

(Hard configuration of the server)

Fig. 3 is a schematic block diagram showing an example of the hardware configuration of a server (30). The server (30) mainly includes a CPU (31), a ROM (32), a RAM (33), an auxiliary memory device (34), and a communication unit (35), which are connected to each other via a bus line (36) including an address bus, a data bus, a control bus, and the like. In addition, an interface circuit is interposed between the bus line (36) and each component as necessary, but the illustration of the interface circuit is omitted here.

The CPU (31) interprets and executes commands from system software or application software, thereby controlling the entire server (30). The ROM (32) stores programs, etc. necessary for controlling the basic operations of the server (30). The RAM (13) stores various programs and data, thereby securing a work area for the CPU (31). The auxiliary memory device (34) is a memory device that stores programs, various data, etc. As the auxiliary memory device (34), a hard disk drive, etc. can be used, for example.

The communication unit (35) is provided with a communication interface (not shown) and controls communication with each game terminal (10-n) via the network N. In addition, the communication unit (35) is also configured to control communication with other servers (not shown) connected to the network N. For example, in the case where the server (30) is configured as a system built into a social networking service (SNS), the communication unit (35) of the server (30) controls communication with the SNS server. In addition, for example, the server (30) controls communication with a video image distribution server that distributes game video images played by the user to the spectators. In addition, the server (30) may be provided with a video image distribution function.

The server (30) may be configured as a standalone computer, but may also be configured as a distributed function type in which each function of the server (30) is distributed across multiple servers. Alternatively, a load-distributed configuration may be achieved by providing multiple servers (30) on network N to achieve redundancy (multiplexing). Furthermore, the server (30) may be configured as a cloud server utilizing cloud computing technology.

The program or data is supplied from a remote location to the game terminal (10) or server (30) via the network N and stored in the RAM (13), auxiliary memory device (14), RAM (33) or auxiliary memory device (34). In addition, a component (e.g., an optical disk drive or a memory card slot) for reading the program or data stored in an information storage medium (e.g., an optical disk or a memory card) may be provided in the game terminal (10) or server (30). In addition, the program or data may be supplied to the game terminal (10) or server (30) via the information storage medium.

[2. Overview of an example game]

An overview of an example game is given below.

The game system (1) can run various games. For example, a variety of games can be run, regardless of game format or genre, such as sports games (games based on baseball, soccer, tennis, American football, etc.), racing games, fighting games, battle games, and digital card games. Furthermore, the games can be run by the game terminal (10) performing data communication with a server (30) or another game terminal (10), or can be run by the game terminal (10) alone.

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

In the baseball game of this embodiment, player characters modeled after real baseball players are provided as characters (examples of objects) usable within the game. In other words, player characters are provided with the names of real baseball players and with ability parameters set based on the player's abilities and performance. In the baseball game of this embodiment, multiple player characters are provided, each corresponding to a baseball player registered under the management of 12 real-world Japanese professional baseball teams. Furthermore, when a new baseball player is registered under the management of one of the 12 professional baseball teams, a player character corresponding to that baseball player is added to the game. Furthermore, the ability parameters of the player characters corresponding to real baseball players may be updated periodically (e.g., monthly, weekly, game-by-game, etc.) or irregularly, based on the player's performance during the season. Furthermore, for example, player characters corresponding to real professional baseball players who have retired from active play may be made usable within the game.

Additionally, the player character may be a fictional baseball player. Furthermore, the baseball game of this embodiment includes a game mode for developing original player characters. In this development mode, the original player character, once developed, may be used alongside player characters modeled after real baseball players in various game modes.

The baseball game of this embodiment includes various game modes in addition to the aforementioned training mode. For example, there is a computer versus mode (also called CPU versus mode), in which the user competes against a computer (CPU). In this computer versus mode, the user controls the batting, pitching, and defensive operations of their own team's player characters, and competes against an opposing team whose player characters are automatically controlled by the CPU. Furthermore, there is a manager play mode, in which the user obtains a player character from among multiple player characters through a probability-based lottery, forms their own team with the acquired player characters, and competes as a manager. In this manager play mode, the user advances the game by issuing instructions to the player characters, such as bunts, steals, and hit-and-runs. The opponent in this manager play mode can be another user or a computer. Furthermore, there is also an offline versus mode, in which two users can compete against each other by connecting two or more controllers to a single game terminal (10), for example. Additionally, the baseball game of this embodiment features a communication battle mode that allows users to compete against other users via communication. This communication battle mode allows users to compete in real-time online battles with other users remotely via Network N.

In the above real-time match, for example, a match between a user's team and an opposing team (a baseball team of another user on network N) is conducted in a communication match based on operations on each game device (10). For example, if the user is on the defensive side and the opposing user is on the offensive side, the player character pitches or defends based on the opposing user's operation (pitching operation or defensive operation), and the player character bats or runs based on the user's operation (batting operation or base running operation). In such an action game, the match situation within the game is updated based on each user's operation of the player character. This real-time match is a match method also used in e-sports (electronic sports).

The online battle mode includes "Free Battle Mode" and "Online Competition Mode." In "Free Battle Mode," users can choose their favorite team or player character, and even set the battle rules (e.g., the number of innings per match), allowing them to battle other users at any time.

For example, in free-to-play mode, users create rooms for free-to-play matches, which are called rooms for playing matches against other users. When creating a new room, users can arbitrarily set match rules. If a user has already created a room, a user can enter the room (e.g., by selecting the room) and engage in a communication match against the user who created the room. In other words, each user can engage in a match by creating a room themselves and waiting for other users to enter, or by entering a room created by another user. Furthermore, if a user sets an arbitrary passcode when creating a room, only other users who know the passcode can enter the room and engage in a match.

In online tournament mode, users can participate in online competitions held by the game's management as official tournaments. Each user can participate in various official tournaments, held regularly or irregularly, and engage in real-time battles with users from across the country (or the world) via Network N. These tournaments typically last for a set period of time (e.g., one week or three days). Each user can participate in one or more tournaments during each tournament period. Depending on the tournament type, some tournaments may have a limit on the number of matches per tournament period, while others allow unlimited matches. Furthermore, some tournaments may specify a specific number of matches each user must participate in during the tournament period.

When users participate in ongoing tournaments and compete in competitive games, they are awarded rewards (such as points or items usable in-game) and tournament points based on the results of the competition. Users who participate in various tournaments in online tournament mode maintain "Total Tournament Points," "Weekly Tournament Points," and "Tournament Points Acquired in Each Tournament." Tournament points do not decrease based on match results, but rather increase with each competitive game played. Furthermore, after each tournament ends, a ranking based on the tournament points earned by each user during the tournament period is announced. Furthermore, users are awarded rewards (such as points or items usable in-game) based on their ranking in each tournament. Furthermore, rewards can be earned when the total tournament points reach a certain level. The main game cycle in online tournament mode is "Participate in a tournament → Play → Earn rewards → Tournament ends → Rankings are announced → Earn rewards based on ranking → Participate in the next tournament." In online competition mode, various competitions are held regularly or irregularly, so users can enter competitions that interest them to earn rewards or enjoy real-time matches with users from all over the country (or even the world).

The following describes examples of tournaments held in online tournament mode. These tournaments include the "Regular Cup," "Beginner Cup," "Master Cup," "Real Speed Cup," "Player Random Cup," and "Team Random Cup." Each tournament differs in its rules, participation requirements, tournament duration, and player characters available for use in battles. These are merely examples, and other tournaments may also be held in online tournament mode.

Fig. 4 shows an example of a tournament information table (TBL1) managed in a server (30). The tournament information table (TBL1) is a data table for managing each tournament held in online tournament mode. The tournament information table (TBL1) includes fields such as "tournament ID", "tournament name", "start time", "end time", "participation conditions", and "tournament rules". The "tournament ID" field indicates identification information for uniquely identifying each tournament held in online tournament mode. The "tournament name" field indicates the name of the tournament. For example, for the "Player Random Cup", "Player Random Cup 1st", "Player Random Cup 2nd", ... "Player Random Cup nth", which are held for different periods, are each given a different tournament ID and managed individually.

In addition, the "Start Time" field of the tournament information table (TBL1) indicates the start time of the tournament. The "End Time" field indicates the end time of the tournament. The "Participation Conditions" field indicates the conditions for participating in the tournament. Depending on the tournament, some tournaments have participation conditions set, while others do not (i.e., anyone can participate). In the example of this embodiment, the participation conditions are set based on the matching rate MR associated with each user's user ID. Here, the matching rate MR is an indicator of the height of the user's game level. For example, if a user participates in a tournament and wins against a user with a higher (or equal) matching rate than himself, the user's matching rate MR increases. On the other hand, if the user loses to a user with a lower (or equal) matching rate than himself, the user's matching rate MR decreases. Additionally, a user's matching rate MR may remain unchanged even if they lose to a user with a matching rate that is at least a predetermined higher than their own, or win against a user with a matching rate that is at least a predetermined lower. Conditions other than the matching rate MR may also be applied to the tournament participation requirements. For example, the user's own player character level, total number of wins in matches, or total win rate in matches may be used as participation requirements.

The "Tournament Rules" field indicates the rules for the matches played in the tournament. This field can include, for example, setting information regarding the number of innings, the presence or absence of extra innings, the maximum number of innings in extra innings, speed levels, and the difficulty of operations (the difficulty levels of batting, pitching, fielding, and baserunning). The tournament information table (TBL1) also includes other information fields. For example, there is a rewards field indicating rewards earned by participating in the tournament, rewards for winning matches, and rewards based on ranking.

For example, a "Regular Cup" tournament is open to anyone and has standardized difficulty levels for both the level of restraint and the difficulty of the controls. For example, the "Regular Cup" is held for a week, from Monday to Sunday, and is held regularly every week.

Also, for example, a tournament called the "Beginner Cup" is a tournament for users who are not yet familiar with the game's controls. In the "Beginner Cup," for example, the matching rate MR is set to less than 50, and the constraint level and difficulty of operation are also set to lower than the standard level. Also, for example, a tournament called the "Master Cup" is a tournament for users who are familiar with the game's controls. In the "Master Cup," for example, the matching rate MR is set to 50 or higher, and the constraint level and difficulty of operation are set to the standard level or higher than the standard level. Also, for example, the "Real Speed Cup" can be a tournament in which the constraint level is set to the highest level of real speed.

In the aforementioned "Regular Cup," "Beginner Cup," "Master Cup," and "Real Speed Cup," users participating in any tournament can decide which team and player characters they will use in battle. For example, users can freely select their favorite team from among multiple teams (in this embodiment, multiple teams corresponding to the 12 Japanese professional baseball teams) to battle against. Furthermore, users can freely select player characters to form their own team from among the player characters they own, for example.

Meanwhile, the "Player Random Cup" is a special tournament, different from the aforementioned "Regular Cup", in which all player characters for a team that users can use in a match are randomly assigned for each match. Furthermore, the "Team Random Cup" is a special tournament, different from the aforementioned "Regular Cup", in which the team that users use in a match (a team consisting of multiple default player characters) is randomly assigned for each match. Below, an overview of the online match mode will be provided, and a game description will primarily focus on the "Player Random Cup" and the "Team Random Cup."

Game screen G100 of Fig. 5 shows an example of a game screen when the online competition mode is selected by the user. Game screen G100 includes parts P101 to P109. Part P101 is a part for selecting the "Online Competition Mode." Part P102 is a part for selecting the "Free Competition Mode." Part P103 is a part for transitioning to a screen for checking the user's overall ranking. Part P104 is a part for transitioning to a screen for setting the team formation. The user can set the team formation for a competition in the online competition mode in advance before the competition. However, the team formation that can be performed by selecting this part P104 is only effective in competition games other than the "Player Random Cup" and the "Team Random Cup." That is, in the “Player Random Cup” and “Team Random Cup,” the user cannot decide the team and player characters to use in the match, so the team formation set in advance by selecting Part P104 cannot be used.

Part P105 is for transitioning to a screen where you can check your match history or participation history in a tournament. Part P106 is for transitioning to a screen where you can check your total rewards earned in online match mode. Part P107 is for transitioning to a screen where you can set and modify your user profile. User profile settings include, for example, a nickname and your favorite team (e.g., one of the 12 Japanese professional baseball teams).

Part P108 is a part for transitioning to the user settings screen. In the user settings screen, settings such as the restraint level can be made. In addition, the user settings screen can be used to configure the team (pet mark, team icon, uniform, home stadium, cheering song, etc.) used by the user in the competition game. In addition, the team settings previously set independently by the user in this user settings screen are only applied to competition games other than the "Player Random Cup" and the "Team Random Cup", and are not applied to the "Player Random Cup" and the "Team Random Cup". Part P109 is a part for transitioning to a screen where the 12-team win-loss table for all matches played in online competition mode can be checked. For example, the screen transitions to a screen similar to the 12-team win-loss table exemplified in Fig. 18.

In the game screen G100, when the user performs an operation to select part P101 (operation by the control unit (16)), the screen transitions to the competition selection screen G200 shown in Fig. 6. The competition selection screen G200 is an example of a screen for selecting various competitions in the online competition mode. The competition selection screen G100 includes parts P201 to P205. Part P201 is a part that displays information about the competition. This part P201, including those not displayed on the competition selection screen G200, exists as many as the number of competitions that the user can select. By an operation to select part P202 or part P203, parts P201 that display information about various competitions can be switched and displayed on the competition selection screen G200. The competition of part P201 displayed on the competition selection screen G200 is the currently selected competition. Part P204 is a user interface that displays the number of competitions in a list with the number of dots. The color of the dots in the selected competition section changes. Part P205 indicates the number of users currently competing in the selected competition.

Part P201 displays information about whether the competition is currently being held (e.g., "Currently held," "Ended," or "Before held"). Part P201 also displays the competition name, duration, total number of participating users, competition rules, and rewards available for the competition. Furthermore, after a user participates in a competition, their ranking in that competition is also displayed. Part P201 may also display the participation requirements for the competition. Furthermore, participation requirements may only be displayed for competitions that have established participation requirements.

In the example of Fig. 6, the currently held "Player Random Cup" is selected on the tournament selection screen G200. When the user performs a decision operation on this tournament selection screen G200, the selection of the "Player Random Cup" is determined, and the transition is made to the message screen G300 of Fig. 7. The message screen G300 is an example of a screen for confirming the intention to participate in the tournament for a user who has selected the "Player Random Cup." The message screen G300 includes parts P301 to P303. Part P301 displays an overview of the tournament, such as "This tournament is a tournament where players are randomly selected for each match." In addition, part P301 displays a message for confirming the intention to participate in the tournament, such as "Do you want to participate in the tournament?" Part P302 is a part for the user to select participation in the tournament, and the word "Yes" is displayed. Part P303 is the part where the user can choose not to participate in the competition, and the word “No” is displayed.

In message screen G300 of Fig. 7, since the Player Random Cup is a competition that uses randomly selected player characters and is different from a regular competition (a competition where users can select teams or player characters as they wish), the purpose of this is notified to the user and the final confirmation of their intention to participate in the competition is made. This message screen G300 may be omitted, or may be displayed only to users who have selected the Player Random Cup for the first time. For example, message screen G300 may not be displayed to users who have already participated in the Player Random Cup.

In the message screen G300, if the user selects "No" in part P303, the screen transitions to the tournament selection screen G200 of Fig. 6. On the other hand, if the user selects "Yes" in part P302, the screen transitions to the player random cup menu screen G400 of Fig. 8. In addition, if the message screen G300 is omitted, if the user selects "Player Random Cup" in the tournament selection screen G200 of Fig. 6, the screen transitions to the player random cup menu screen G400 of Fig. 8.

The Player Random Cup menu screen G400 includes parts P401 to P406. Part P401 is a part that displays information about the Player Random Cup. Part P401 displays information about whether the Player Random Cup is being held (e.g., whether it is “being held,” “ended,” or “before being held”). In addition, Part P401 displays the tournament name (e.g., Player Random Cup nth), the holding period, the total number of users participating in the Player Random Cup, the ranking of users in the Player Random Cup, the results in the Player Random Cup (e.g., number of wins, number of losses, number of draws, etc.), tournament points acquired in the Player Random Cup, etc.

Part P402 indicates the number of users currently competing in the Player Random Cup. Part P403 initiates a Player Random Cup match. If the Player Random Cup is being prepared or has ended, Part P403 is inactive and cannot be selected. Part P404 confirms the rewards earned by users in the Player Random Cup. Part P405 confirms the ranking in the Player Random Cup. Part P406 displays the image of the player character.

When a user selects "Start Match" on Part P403, their participation in the matchmaking game is accepted, and they are transferred to a waiting screen (not shown), where the matching process to determine their opponent is performed. As an example of the matching process, users whose matching rate (MR) associated with each user ID falls within a predetermined range are matched as opponents. If the matchmaking is successful, a matching success screen (not shown) is displayed, for example.

In the event of a successful match, a predetermined number of player characters available to each user in the Player Random Cup are randomly selected based on the same selection conditions from among all player characters available in the match. As described below, the selection conditions can be, for example, conditions related to parameters such as position information or ability information associated with the player characters. In this embodiment, 29 player characters are randomly selected for each user, but the number of selected player characters is not limited to this.

The player characters that can be used in the Player Random Cup battle game may be all characters handled in the game provided by the game system (1), or some of the characters may be used. Here, an example is shown in which player characters modeled after real baseball players registered under the management of 12 Japanese professional baseball teams are used as player characters that can be used in the Player Random Cup battle game. That is, in this example, some characters that can be used in battle games or other game modes other than the Player Random Cup and Team Random Cup (for example, player characters modeled after retired baseball players, original player characters that each user independently developed and created, etc.) are excluded from the characters that can be used in the Player Random Cup battle game.

Fig. 9 shows an example of a character information table (TBL2). The character information table (TBL2) is data for managing all characters handled in the game provided by the game system (1). The character information table (TBL2) is stored and managed in each memory device (e.g., RAM (13), auxiliary memory device (14), RAM (33), auxiliary memory device (34), database (DB), etc.) of the server (30) and the game terminal (10). The character information tables (TBL2) of the server (30) and the game terminal (10) are basically the same, and for example, when the game operator changes the character information table (TBL2) of the server (30), the changed information is transmitted from the server (30) to the game terminal (10) via the network N. The character information table (TBL2) includes a “character ID” field, a “name” field, a “team ID” field, “position information,” “ability information,” etc.

The "Character ID" field indicates identification information for uniquely identifying a player character. The "Name" field indicates the name of the player character. In this embodiment, player characters modeled after real baseball players are assigned the names of the real baseball players.

The "Team ID" field represents identification information for uniquely identifying the team (club) to which the player character belongs. The team to which the player character belongs is managed by the team information table (TBL3) exemplified in Fig. 10. The team information table (TBL3) is data for managing all teams (clubs to which the player character belongs) handled within the game provided by the game system (1). The team information table (TBL3) is stored and managed in each memory device (e.g., RAM (13), auxiliary memory device (14), RAM (33), auxiliary memory device (34), or database (DB)) of the server (30) and the game terminal (10). The team information tables (TBL3) of the server (30) and the game terminal (10) are basically the same, and for example, when the game operation side changes the team information table (TBL3) in the server (30), the changed information is transmitted from the server (30) to the game terminal (10) via the network N.

The team information table (TBL3) includes a "Team ID" field, a "Club Name" field, a "Player Registration" field, etc. The "Club Name" field indicates the name of the club to which the player character belongs. In other words, the name of the club to which the player character belongs is associated with the character ID and the team ID. In the present embodiment, the club name associated with the player character imitating an actual baseball player is set to the name of the club to which the actual baseball player belongs in reality. The "Player Registration" field will be described later. In addition to the fields described above, the team information table (TBL3) may also include fields related to the home stadium, for example.

The "Position Information" in Figure 9 represents parameters related to the player character's position. The "Position Information" includes a "Main Position" field that indicates the main position set for the player character. Each player character is assigned one of the following positions as their main position: "Pitcher," "Catcher," "First Baseman," "Second Baseman," "Third Baseman," "Shortstop," "Center Fielder," "Right Fielder," or "Left Fielder," which are defensive positions in baseball.

In addition, the "Position Information" includes the "Position Aptitude Information" set for the player character. The "Position Aptitude Information" includes fields for "Starting Pitcher Aptitude," "Middle Reliever Aptitude," and "Closer Aptitude," which are position aptitude information for pitcher characters. The "Starting Pitcher Aptitude" field indicates an evaluation of the aptitude as a starting pitcher, the "Middle Reliever Aptitude" field indicates an evaluation of the aptitude as a middle relief pitcher, and the "Closer Aptitude" field indicates an evaluation of the aptitude as a closing pitcher, respectively. In this embodiment, the evaluation of the position aptitude is expressed in three stages from the highest to the lowest: "◎," "○," and "-(no aptitude or no evaluation). The evaluation of the aptitude is not limited to this, and the evaluation of the aptitude may be expressed using a number, alphabets such as A, B, C, etc., or other symbols.

"Position Aptitude Information" also includes position aptitude information for Beast characters. For Beast characters, the position aptitude is set for the main position and any sub positions they can defend.

"Ability Information" includes a "Comprehensive Ability" field. This "Comprehensive Ability" field is an ability parameter that indicates the overall level of a player's character's abilities. In addition to numerical values, comprehensive abilities can also be expressed using letters, symbols, etc., such as A, B, C, etc.

"Ability information" includes ability parameters other than comprehensive abilities. For example, for a pitcher's player character, "ability information" includes parameters indicating the height of the pitcher's individual abilities (speed parameter, control parameter, stamina parameter, etc.) and parameters indicating the presence or absence of special abilities related to the pitcher. Furthermore, for a fielder's player character, "ability information" includes parameters indicating the height of the fielder's individual abilities (defensive power parameter, ballistic parameter, mitt parameter, power parameter, stamina parameter, etc.) and parameters indicating the presence or absence of special abilities related to the fielder. The above-mentioned comprehensive ability can be, for example, the sum (or average, etc.) of the ability values of multiple individual abilities set for the player character.

Although omitted in Fig. 9, fields other than those described above are also included in the character information table (TBL2). For example, parameters such as the player character's "rank," "cost," "level," and "rarity" are also included in the character information table (TBL2). Furthermore, parameters such as the player character's relaxation or form (batting or pitching form), the multiple pitches a pitcher can throw, parameters related to pitches (parameters evaluating pitch direction, amount of change, etc.), information on the strengths/weaknesses of a batter's pitching trajectory, and information on compatibility with the pitcher are also included in the character information table (TBL2). Furthermore, image and moving image data (two-dimensional or three-dimensional) of the player character are also included in the character information table (TBL2). Furthermore, the character information table (TBL2) may also include information indicating the character's type. For example, information such as flags for identifying player characters corresponding to actual active players, player characters corresponding to actual retired active players, original player characters created by users, and other characters may be included in the character information table (TBL2). The various parameters included in the character information table (TBL2) described above are set for each character (for each character ID).

And, in the Player Random Cup battle game, 29 player characters that each user can use as an opponent are randomly selected from among all player characters (examples of usable targets) that can be used in the Player Random Cup battle, based on the same selection conditions regarding the parameters (position information, ability information, etc.) of the player characters. The details of the 29 player characters to be selected are, for example, pitchers (starting pitchers): 4, pitchers (middle relievers): 3, pitchers (set uppercutters): 2, pitchers (closers): 2, catchers: 2, first basemen: 2, second basemen: 2, third basemen: 2, shortstops: 2, center fielders: 2, right fielders: 2, left fielders: 2, and position randomness: 2. Here, the two position randomness players can be randomly selected from any position.

Fig. 11 shows an example of selection conditions for each position of a pitcher player character, and Fig. 12 shows an example of selection conditions for each position of a fielder player character. In Figs. 11 and 12, individual player characters to be selected for each position are distinguished as Candidate 1 to Candidate 4 and position random frames. In the examples of Figs. 11 and 12, selection conditions are set for individual player characters to be selected. The selection conditions include conditions regarding parameters of position information (an example of role information) and ability information. In the examples of Figs. 11 and 12, multiple conditions set for individual player characters to be selected are AND conditions.

As shown in Figure 11, for pitchers (starting), four candidates 1 to 4 are necessarily selected, and including one player from the position random frame, there is a possibility that up to five player characters can be selected. For example, the selection conditions for pitcher (starting) candidate 1 are "main position pitcher", "starting aptitude ◎", and "overall ability value is 300 or higher." In addition, for example, the selection conditions for pitcher candidates 2 and 3 are "main position pitcher", "starting aptitude ◎", and "overall ability value is 200 to 299," respectively. In this way, the same selection conditions may be set for two or more selection targets. In addition, for example, the selection conditions for pitcher (starting) candidate 4 are "main position pitcher", "starting aptitude ○ or higher", and "overall ability value is 199 or lower." Here, "aptitude ○ or higher" means "aptitude ○" or "aptitude ◎" (hereinafter, the same applies). In addition, for example, the selection conditions for the position random frame for a pitcher (starting pitcher) are "main position pitcher," "starting aptitude ○ or higher," and "overall ability value of 150 to 350."

For pitchers (middle relievers), three of the candidates 1 to 3 are guaranteed to be selected, and including one of the position random frames, there is a possibility that up to four player characters can be selected. For example, the selection conditions for pitcher (middle reliever) candidate 1 are: "Main position pitcher", "Middle reliever aptitude ◎", and "Overall ability value 300 or higher". Furthermore, for example, the selection conditions for pitcher (middle reliever) candidate 2 are: "Main position pitcher", "Middle reliever aptitude ◎", and "Overall ability value 200 to 299". Furthermore, for example, the selection conditions for pitcher (middle reliever) candidate 3 are: "Main position pitcher", "Middle reliever aptitude ○ or higher", and "Overall ability value 199 or lower". Also, for example, the selection conditions for the position random frame of a pitcher (middle reliever) are “main position pitcher”, “middle reliever aptitude ○ or higher”, and “overall ability value of 150 to 350”.

For pitchers (set uppers), two of Candidates 1 and 2 are guaranteed to be selected, and including one of the random position frames, there is a possibility that up to three player characters can be selected. For example, the selection conditions for Candidate 1 for pitchers (set uppers) are: "Main position pitcher", "Middle relief aptitude ◎", "Closer aptitude ○ or higher", and "Overall ability value 300 or higher". In the case of pitchers (set uppers), the selection conditions are those that take into account both middle relief aptitude and closer aptitude. For example, the selection conditions for Candidate 2 for pitchers (set uppers) are: "Main position pitcher", "Middle relief aptitude ◎", "Closer aptitude ○ or higher", and "Overall ability value 200 to 299". In addition, for example, the selection conditions for the position random frame of a pitcher (set upper) are "main position pitcher", "middle relief pitcher aptitude ◎", "closer aptitude ○ or higher", and "overall ability value of 150 to 350".

For pitchers (closers), two players, Candidate 1 and Candidate 2, are guaranteed to be selected. Including one player from the position random frame, up to three player characters can be selected. While this explanation is omitted here, similar to pitchers (starters), selection conditions are set for Candidate 1, Candidate 2, and the position random frame for pitchers (closers).

As shown in Figure 12, for the fielder characters, two candidates 1 and 2 are necessarily selected for any position, and including one player from the position random frame, there is a possibility that up to three player characters can be selected. For example, the selection conditions for catcher candidate 1 are "main position catcher" and "overall ability value is 300 or higher." Similarly, for other positions of fielder characters, for example, the selection conditions for candidate 1 are "main position is the target position" and "overall ability value is 300 or higher." Furthermore, for example, the selection conditions for catcher candidate 2 are "main position catcher" and "overall ability value is 200 to 299." Similarly, for other positions of fielder characters, for example, the selection conditions for candidate 2 are "main position is the target position" and "overall ability value is 200 to 299." Also, for example, the selection conditions for the catcher's position random frame are "main position catcher" and "overall ability value is 150 to 350." Similarly, for other positions of the beast character, for example, the selection conditions for the position random frame are "main position is the target position" and "overall ability value is 150 to 350."

In this embodiment, among the 29 player characters assigned to users, the same player character is not selected multiple times. Furthermore, as a variation, among a predetermined number of player characters assigned to users, the same player character may be selected multiple times.

For example, outside of the position random frame, each candidate for each position is basically randomly selected starting from candidate 1, but any candidate for any position can be randomly selected. Alternatively, through parallel processing, multiple candidates or multiple positions can be randomly selected at approximately the same time.

To prevent duplicate selection of identical player characters, already selected players must be excluded from random selection. For example, if identical selection conditions are set for pitcher (starting) candidates 2 and 3 as shown in Figure 11, two player characters are randomly selected from the population that satisfies the selection conditions so that they do not overlap. For example, first, the player character of candidate 2 is randomly selected, and then the player character of candidate 3 is randomly selected while excluding the selected player character. Furthermore, the selection order of candidate 2 and candidate 3, which have identical selection conditions, may be selected first.

For example, in selecting two player characters in the position random frame, first, in order to determine which position to select from, two positions are randomly selected from all positions (here, 12 positions: 4 pitchers + 8 fielders). The two positions randomly selected here may be allowed to overlap, or may not overlap. Then, based on the selection conditions set in the position random frame of the determined position, the player character for the corresponding position is randomly selected. In a case where the same player character is not selected repeatedly among the 29 player characters assigned to the user, for example, first, random selection of 27 player characters other than the position random frame is performed, and then, excluding the player characters that have already been selected, random selection of two players in the position random frame is performed. Alternatively, for example, two players in the position random frame may be randomly selected first, and then random selection of the 27 player characters other than the position random frame may be performed. As a variation, no selection conditions need to be set for the position random frame. Here, "no selection conditions" means, for example, that all player characters available in a Player Random Cup match are selected for random selection. In other words, while selection conditions are set for the random selection of a certain number of player characters within a team (e.g., 27), the remaining player characters (e.g., 2) can be selected randomly without any selection conditions.

Furthermore, in this embodiment, since 29 player characters are assigned to each of the two competing users, a total of 58 player characters are selected. However, among the 58 player characters, the same player character is not selected repeatedly. In other words, the player character assigned to one of the two competing users is not selected for the other user. Furthermore, as a variation, the player character assigned to one of the two competing users may be selected for the other user as well.

In a case where the player character assigned to one of the two competing users is not selected for the other user, for example, a random selection of a player character is performed for one user, the selected player character is excluded from the selection, and a random selection of a player character is performed for the other user. For example, if the player character "Pitcher (Starting) Candidate 1" is assigned to each of the two competing users, the player character assigned to one user is randomly selected from the population that satisfies the selection condition for "Pitcher (Starting) Candidate 1," and then the selected player character is excluded from the selection, and the player character assigned to the other user is randomly selected. In this case, regardless of which user among the two competing users performs the random selection process first, the probability of selecting any player character included in the population that satisfies the selection condition is the same for both users. Therefore, regardless of the order of random selection for the two players competing, the player characters used by each user in the match can be said to be randomly assigned to each user from the "same population." Furthermore, for example, the order of random selection for the two players competing could be determined by random drawing, or the order could be determined without such a drawing.

In addition, in competitions other than the Player Random Cup and Team Random Cup, since users can choose the player characters they want to use, there is a tendency to use player characters with high ability parameters consecutively. Therefore, in competitions other than the Player Random Cup and Team Random Cup, restrictions such as restrictions on the starting rotation (player characters used in the starting rotation cannot be used consecutively in the next match) are put in place to prevent the continuous use of player characters with high ability parameters. In contrast, in the Player Random Cup and Team Random Cup, player characters and teams that users can use are randomly assigned, so there are no restrictions on the starting rotation.

However, there are cases where the above selection conditions may not be enough to select a player character, either because there are no player characters that meet the preset selection conditions, or because the number of player characters that meet the above selection conditions is less than the number that should be selected. In this case, it is desirable to change the preset selection conditions to target the number of player characters equal to the number of players that are missing.

One way to change the selection conditions is to expand the range of ability parameters. In this case, the range of ability parameters can be expanded toward either the lower or higher ability level, or in both directions. Another way to change the selection conditions is to shift the range of ability parameters. In this case, the range of ability parameters can be shifted toward either the lower or higher ability level. Another way to change the selection conditions is to change the conditions using individual ability parameters instead of comprehensive abilities. Another way to change the selection conditions is to change the position conditions. Another way to change the selection conditions is to change the type of parameters used in the conditions. For example, instead of selection conditions related to position and ability parameters, other types of parameters (such as the player character's rank, level, cost, or rarity) can be applied. These are just examples, and if the preset selection conditions do not provide enough player characters to be selected, the selection conditions can be changed in any way. Additionally, for example, if there is a shortage of player characters to be selected even after the selection conditions have been changed, the selection conditions may be changed repeatedly until the shortage is resolved.

The selection conditions shown in FIGS. 11 and 12 are merely examples and are not limited thereto. For example, in the above example, position random frames for two people are provided, but it may be provided for one person, three or more people, or the position random frame may be omitted. In addition, for example, in the above example, the ability parameter conditions of Candidate 1 are made the same for all positions of the player character, but the ability parameter conditions may be different for some or all of the positions. The same applies to Candidate 2 and the position random frame. In addition, in the above example, the value of the overall ability of the player character is used as the ability parameter condition, but other ability parameters, such as parameters for individual abilities or the presence or absence of special abilities, may be used.

Furthermore, selection conditions may include parameters other than ability parameters and position parameters, for example. Alternatively, selection conditions may be set by combining various types of parameters. Furthermore, in the above example, if multiple conditions are included in the selection conditions, AND conditions are used, but OR conditions may also be used, or AND and OR conditions may be combined. Alternatively, NOT conditions may be applied, or NOT conditions may be combined with AND or OR conditions.

Figure 13 is an explanatory diagram illustrating another example of the selection conditions for player characters randomly assigned to each user. In Figure 13, in order to simplify the selection condition settings compared to Figure 11, detailed position classifications for pitchers, such as starting pitcher, middle reliever, set uppercutter, and closer, are not provided. Figure 13 illustrates an example of setting selection conditions for selecting a predetermined number (e.g., 12) of player characters for a single pitcher position. For example, for pitcher candidates 1 and 2, the selection conditions of "main position pitcher" and "overall ability 350 or higher" are set. Furthermore, for example, for pitcher candidates 3 to 6, the selection conditions of "main position pitcher" and "overall ability value 300 to 349" are set. Furthermore, for example, for pitcher candidates 7 to 9, the selection conditions of "main position pitcher" and "overall ability value 200 to 299" are set. Additionally, for example, for pitcher candidates 10 to 12, the selection conditions of “main position pitcher” and “comprehensive ability value of 199 or less” are set.

Also, Fig. 13 shows an example of setting selection conditions for selecting a predetermined number (e.g., 9) of player characters for a single position, namely, infielders excluding catchers. For example, for infielders candidates 1 and 2, the selection conditions of "main position infielder" and "overall ability value of 350 or higher" are set. Here, the condition for "main position infielder" is an OR condition in which the main position is "first baseman", "second baseman", "third baseman", or "shortstop". Similarly, for infielders candidates 3 to 6 and candidates 7 to 9, for example, selection conditions that include the condition of "main position infielder" are set, respectively. Also, in the example of Fig. 13, selection conditions are set separately for catchers and infielders other than catchers, but catchers may also be included in the infielders and selection conditions may be set.

Also, Fig. 13 illustrates an example of setting selection conditions for selecting a predetermined number (e.g., 6) of player characters for a single position, such as outfielders. For example, for outfielders candidates 1 and 2, the selection conditions of "main position outfielder" and "overall ability value of 350 or higher" are set. Here, the condition for "main position outfielder" is an OR condition where the main position is "center fielder," "right fielder," or "left fielder." Similarly, for outfielders candidates 3 to 6, for example, selection conditions that include the condition for "main position outfielder" are set.

Figure 14 is an explanatory diagram illustrating another example of the selection conditions for player characters randomly assigned to each user. Figure 14 illustrates an example in which the selection conditions are set using only ability-related parameters, without using position-related parameters. In Figure 14, for example, for candidates 1 to 5, the selection condition of "a comprehensive ability value of 350 or higher" is set. Furthermore, for example, for candidates 6 to 10, the selection condition of "a comprehensive ability value of 300 to 349" is set. Furthermore, for example, for candidates 11 to 20, the selection condition of "a comprehensive ability value of 200 to 299" is set. Furthermore, for example, for candidates 21 to 29, the selection condition of "a comprehensive ability value of 199 or less" is set.

Figure 15 is an explanatory diagram showing another example of the selection conditions for player characters assigned to each user. Figure 15 shows an example in which the selection conditions are set using only parameters related to positions, without using parameters related to abilities in the selection conditions. For example, for pitcher (starting) candidates 1 and 2, the selection conditions of "main position pitcher" and "starting aptitude ◎" are set. For example, for pitcher (starting) candidates 3 and 4, the selection conditions of "main position pitcher" and "starting aptitude ○" are set. For example, for pitcher (middle reliever) candidates 1 to 3, the selection conditions of "main position pitcher" and "middle reliever aptitude ○ or higher" are set. Similarly, selection conditions using position-related parameters are set for other positions.

Alternatively, the selection conditions for the player characters randomly assigned to each user may be, for example, "all player characters available in the Player Random Cup matches." Here, the explanation continues, assuming that the selection conditions exemplified in Figures 11 and 12 apply.

Based on the selection conditions set for each player character to be selected as described above, 29 player characters are randomly selected from among all player characters available for use in the Player Random Cup matches and assigned to each user competing. As a result, the two matched users will compete using each of the 29 randomly selected player characters as members of their own team. The player characters assigned to the two competing users are randomly selected from among all player characters commonly available to all users in the Player Random Cup matches based on the same selection conditions. In other words, the player characters that users can use in the matches are randomly assigned from the "same population" for all users.

Fig. 16 shows an example of a user team table (TBL12) in a competitive game of the Player Random Cup. The user team table (TBL12) of Fig. 16 shows information on player characters for one team randomly assigned to a user with a user ID of "U1." The user ID is associated with the "tournament ID" and "match ID" of the Player Random Cup. The user team table (TBL12) includes a "serial number" field, a "character ID" field, a "team ID" field, etc. The "character ID" field indicates the character ID of the player character randomly assigned to the user. The "team ID" field indicates the team ID associated with the character ID of the player character. In the Player Random Cup, the team ID (i.e., the affiliated club) associated with each player character varies. The user team table (TBL12) also includes fields for setting information on the order formation described below. In addition, the "serial number" field may be omitted.

The two users competing each check their assigned player characters on the screen. Then, each user forms a team order for a team containing 29 player characters within a given time limit (e.g., within 300 seconds). Regarding this order formation, in the Player Random Cup (and the Team Random Cup described below), unlike other competitions (where users can select teams and player characters as they wish), users cannot know which player characters will be assigned to them. Therefore, users must confirm the player characters that can be used in the competition game after they are assigned. Therefore, in matches in the Player Random Cup (and the Team Random Cup described below), a longer time limit is set for order formation than the time limit (e.g., 180 seconds) given in matches in other competitions or free matches.

Each user's team order formation includes pitcher order formation and fielder order formation. In pitcher order formation, the user determines the roles of the starting pitcher, middle reliever, set uppercut, and closer among the pitcher characters assigned to them. In fielder order formation, the user selects eight starting players from among the players assigned to them, and determines their respective positions and batting order. Player characters not selected as starting players become substitutes on the bench and can be used during player substitutions during the game.

Furthermore, in the Player Random Cup, since the multiple player characters assigned to a user are selected randomly, the team names associated with each player character vary. Typically, player characters wear uniforms corresponding to their associated team names, resulting in non-uniform uniforms for the multiple player characters that make up the user's team. Therefore, the user may be allowed to select a uniform for the multiple player characters that make up the user's team from among multiple options. For example, the user may be allowed to select the uniform of any of the 12 Japanese professional baseball teams. The uniform selection process may be performed at any time up until the start of the match. Furthermore, the uniform selection process may be omitted. Alternatively, the uniform corresponding to a favorite team (e.g., one of the 12 Japanese professional baseball teams) that the user has previously set in the profile settings screen may be automatically selected.

Additionally, for the team settings used by the user in the Player Random Cup, for example, the team settings (pet mark, team icon, uniform, home stadium, cheering song, etc.) of the user's favorite team (any of the 12 professional baseball teams) may be applied.

Matches in the Player Random Cup are real-time action-packed online battles. Each player controls a randomly assigned player character for each team. The game animations for these battles are distributed, for example, from a server (30) with an animation distribution function or from an animation distribution server.

However, with the proliferation of eSports, watching game matches is becoming a way to enjoy games, not just playing them. Many spectators simply want to see the skill competition between players, and are less interested in acquiring powerful player characters or teams that are worth paying for, and whose performances significantly influence the outcome of the match. Therefore, from the perspective of entertaining spectators, ensuring fair gameplay conditions for each player competing is crucial. In this regard, in a random player cup match, the same selection criteria apply to both players, and the player characters available to each player in the match are randomly assigned from the same population, ensuring fair gameplay conditions.

During a designated tournament period (e.g., three days) in the Player Random Cup, each user can participate in multiple competitive games. During the tournament period, each user can participate in any match, or the number of matches held during the tournament period may be fixed. For example, a league format (where all players compete against each other in a designated number of matches), a tournament format, or a combination of these formats may be used. The same applies to the Team Random Cup, described below.

Next, we will explain the "Team Random Cup" battle game, where the team (multiple player characters that make up the team) that the user uses in battle is randomly assigned.

When selecting "Team Random Cup" on the tournament selection screen G200 in Figure 6, a brief description of the tournament will be displayed, such as, "This tournament uses teams randomly selected for each match." Furthermore, a message asking for confirmation of participation in the tournament will be displayed, asking, "Would you like to participate in the tournament?" Furthermore, the tournament brief description or confirmation of participation may be omitted.

When a user performs an operation to participate in the Team Random Cup, the Team Random Cup menu screen is displayed. Since the Team Random Cup menu screen is the same as the Player Random Cup menu screen G400 of FIG. 8, its description is omitted. When the operation of selecting "Start Match" on the Team Random Cup menu screen is performed, participation in the match game is accepted, and the game transitions to a waiting screen (not shown), where a matching process to determine an opponent is performed. For example, the matching process is performed based on each user's matching rate MR. If the matching is successful, for example, a matching success screen (not shown) is displayed.

And, if the matching is successful, the team (an example of a group including two or more objects used by the user during the match) available to each user who will be the opponent is randomly selected based on the same selection conditions from among all teams (an example of the target of use) available for the match in the Team Random Cup.

In the baseball game of this embodiment, all teams available for use in the Team Random Cup matches are, for example, the 12 teams managed in the team information table (TBL3) of FIG. 10. The "Team Name" field of the team information table (TBL3) indicates the name of one of the 12 Japanese professional baseball teams.

In addition, the "Player Registration" field indicates a predetermined number of player characters (e.g., 29) for which player registration has been performed. Here, "Player Registration" refers to the registration of players so that they can play in a sports game. In Major League Baseball, it is also called "Roster Registration." In the baseball game of this embodiment, the player characters registered in the "Player Registration" field become members of a team that can be used in a match game in the Team Random Cup. In this embodiment, 29 character IDs are registered in the "Player Registration" field. The 29 player characters registered in the "Player Registration" field are player characters corresponding to 29 real players who have been registered as players in each Japanese professional baseball team.

That is, in the game of this embodiment, a real team (club) in the real world corresponds to a team in the game, and 29 players registered as players on the real team correspond to 29 player characters registered as players on the team in the game. For example, if a player registered as a player on the real team changes, the game operator changes the player character ID registered in the "Playing Player Registration" field of the team information table (TBL3) in accordance with the change. In addition, if the playing player registration is unclear due to the off-season of real-world professional baseball, for example, the game operator can register the character IDs of the default 29 player characters in the "Playing Player Registration" field of the team information table (TBL3) by referring to the playing player registration from the previous season.

For example, the selection criteria for the Team Random Cup are "all teams available for Team Random Cup matches." In this case, each user facing off against another player is randomly assigned a team from among the 12 available teams. For each match, the user uses the team randomly assigned to them, i.e., the 29 player characters registered for that team, to play in the Team Random Cup matches.

In this embodiment, teams are randomly selected to ensure that the two competing users are assigned to the same team. As a variation, the same team may be selected multiple times for the two competing users.

Figure 17 illustrates an example of a user team table (TBL12) in a Team Random Cup match game. The user team table (TBL12) in Figure 17 represents information on player characters for a team assigned to a user with the user ID "U1." The user ID is associated with the "tournament ID" and "match ID" of the Team Random Cup. The "team ID" field contains the team ID of the team randomly assigned to the user, and the "character ID" field contains the character IDs of the 29 player characters registered as players for the assigned team.

In addition, although the above example shows how to manage a predetermined number of player characters forming a team by registering them in the "Player Registration" field of the team information table (TBL3) of FIG. 10, the present invention is not limited thereto. For example, in the character information table (TBL2) of FIG. 9, information (e.g., a flag) indicating a player character registered as a player on the team may be set in association with a character ID.

As described above, real teams (clubs) correspond to in-game teams, and 29 players registered as players for the real teams correspond to 29 player characters registered as players for the in-game teams. Furthermore, parameters such as abilities associated with the player characters are set to mimic the real players corresponding to the corresponding player characters. In other words, the in-game teams corresponding to the real teams reflect their true strength, closely resembling the actual teams' abilities. Therefore, in the Team Random Cup with the above-described selection conditions, a mock match is played between teams from 12 real professional baseball clubs. The Team Random Cup matches in this embodiment are not simply mock matches; for each match, a team is randomly assigned to the user. Therefore, when the results of the Team Random Cup matches are aggregated, statistically, the in-game teams corresponding to the strongest clubs in the real world are ranked higher.

Typically, players differ in their skill level, and players with higher skill (those skilled at controlling) are more likely to win matches, even if they're assigned to a relatively weaker team. For example, if any user could choose their own team and play against others, teams with a high proportion of skilled players would likely rank higher, rather than stronger teams.

Meanwhile, in the Team Random Cup matches of this embodiment, each match assigns a random team to each user, allowing any team to be used by users with varying skill levels. Therefore, when the results of Team Random Cup matches are tallied, statistically speaking, the in-game teams that correspond to the strongest teams in the real world will be ranked higher.

For example, by holding a "Team Random Cup" before the opening or regular season of a real-world professional baseball league, the excitement surrounding the real-world league can be heightened through the game. This means that not only users playing the Team Random Cup matches will be excited, but also spectators watching them, for example, if they betray the animation of the match. Furthermore, by allowing any user to view a summary screen of all match results (e.g., a win-loss table) from the Team Random Cup matches, users can enjoy predicting the results of future real-world professional baseball league matches or regular seasons based on the aggregate results.

Fig. 18 shows an example of a summary screen G500 of all match results held in the Team Random Cup. Summary screen G500 is a 12-team win-loss table and includes parts P501 to P504. Part P501 is a part that displays information on the rankings, team names, total wins, total losses, total draws, total win rate, and game difference of each of the 12 teams that can be used in Team Random Cup matches. Part P502 is a part for switching to a screen showing the total rankings of all matches from the 1st to nth round of the Team Random Cup. Part P503 is a part for switching to a screen showing the total rankings of the currently-held Team Random Cup. Part P504 is a part for switching to a screen showing the total rankings of the Team Random Cup held last week.

Looking at the win-loss table on the G500 screen, it seems like Team G will do well in this year's professional baseball season, both during the opener and regular season. Similarly, you can use the mock game results to predict the rankings of real-world professional baseball teams. Of course, even after the actual regular season begins, if you continue to hold Team Random Cups (e.g., every Friday through Sunday), you can use the G500 screen's win-loss table to predict future rankings for professional baseball teams.

Another example of the selection conditions for the Team Random Cup is a condition regarding the league to which a team belongs. The 12 teams available for Team Random Cup matches are divided into two leagues, corresponding to the two divisions of the 12 professional baseball teams in Japan. For example, in the team information table (TBL3) of Fig. 10, the six teams with team IDs TC1 to TC6 belong to the first league, and the six teams with team IDs TP1 to PC6 belong to the second league, which is different from the first league. Furthermore, rather than determining the league based on the team ID, information for identifying the league (e.g., a flag) may be associated with the team ID.

Examples of the above selection conditions in the Team Random Cup include "1st League" or "2nd League." For example, if "1st League" is the selection condition, each user who is to face off against another player is randomly assigned one team from among the 6 teams that meet the "1st League" conditions among the 12 teams available for Team Random Cup matches. Users use the randomly assigned team, i.e., the 29 player characters registered as players for that team, to play the Team Random Cup match. In the Team Random Cup with this selection condition, a mock match is held between teams from the same actual league.

Another example of the above selection conditions in the Team Random Cup is a condition regarding a specific number of teams. For example, the selection conditions are two teams corresponding to two real teams competing in the Japan Series of professional baseball. In this case, each user who is to play against another player is randomly selected and assigned to one of the two teams corresponding to the two real teams competing in the Japan Series. The user uses the randomly assigned team (i.e., the 29 player characters registered as players for that team) to play in the Team Random Cup. In the Team Random Cup with this selection condition, a mock match is played between real teams competing in the Japan Series.

For example, in the real world, after the real baseball teams competing in the Japan Series have been decided, if a tournament called the "Team Random Cup (Japan Series)" is held before the Japan Series matches are held, the excitement of the real-world Japan Series can be heightened through the game. In other words, not only users playing the Team Random Cup matches, but also spectators watching the match, for example, if they betray the animation of the match, will be excited. Furthermore, by allowing any user to check the aggregate results of all matches held in the Team Random Cup (e.g., win-loss table), users can enjoy predicting the outcome of the Japan Series that will be held in the real world based on the aggregate results of all matches. For example, let's say that the two teams corresponding to the two real-world teams competing in the Japan Series are Team G and Team H. And, for example, if the total number of matches in the Team Random Cup is 1000, Team G has 350 wins, Team H has 600 wins, and there are 50 draws, and the aggregate results (aggregated results during the tournament or the final aggregate results) are as follows: Team H will have the upper hand in this year's Japan Series. In this way, you can enjoy predicting the results of the Japan Series by referring to the aggregate results of the mock matches.

Furthermore, while the above-mentioned "Team Random Cup (Japan Series)" tournament is held before the real-world Japan Series, this is not a limitation. For example, the above-mentioned "Team Random Cup (Japan Series)" tournament could be held during or after the real-world Japan Series.

Users check the player characters that make up their assigned team on the screen. Then, as in the Player Random Cup, they organize the team order within a given time limit (e.g., within 300 seconds). Matches in the Team Random Cup are real-time action communication matches. The two competing users each control player characters from randomly assigned teams. The game animation for this match is delivered, for example, from a server (30) with an animation delivery function or from an animation delivery server.

As described above, the teams assigned to the two competing users are randomly selected from all available teams for all users in Team Random Cup matches, based on the same selection criteria. In other words, the teams available to each user in a match are randomly assigned from the same pool.

In addition, although the above shows an example in which a player random cup or team random cup battle game is held within a certain period of time, it is also possible to allow a player random cup or team random cup battle game to be held at all times without limiting the period.

[3. Functional configuration of the game terminal]

Fig. 19 is a schematic functional block diagram showing an example of the functional configuration of a game terminal (10). The game terminal (10) mainly includes a data storage unit (100) and a terminal control unit (110) that controls each unit of the user terminal (10).

The terminal control unit (110) has a function of executing various operations or data processing based on information regarding operations via the operation unit (16), information received from the server (30) or another game terminal (10), etc. In addition, the terminal control unit (110) has a memory control function of storing information on the results of the executed processing in a predetermined area of a memory device (RAM (13), auxiliary memory device (14), etc.). In addition, the terminal control unit (110) has an output control function of controlling various outputs via the image processing unit (17) and the sound processing unit (18). For example, the terminal control unit (110) controls the image processing unit (17) to display a game screen on the display unit (20) (or an externally connected television monitor, etc.), or controls the sound processing unit (18) to output sound effects during game play from the audio output unit (21). In addition, the terminal control unit (110) has a communication control function that manages information communication between the server (30) or other game terminals (10) through the communication unit (15).

In addition, the terminal control unit (110) has a user information management function that stores and manages information about the user's game in a memory device (RAM (13), auxiliary memory device (14), etc.). For example, the terminal control unit (110) associates the user ID with information such as the user name, profile, etc., and stores them in the memory device. The items managed by the terminal control unit (110) vary depending on the type and content of the game. The terminal control unit (110) associates the user ID with information such as the matching rate MR, various points and items, match results, user IDs of other users (colleagues, friends, etc.) associated with the user, various parameters during the game, and save data after the game, and stores them in the memory device and manages them. In addition, if there is information about the user's game stored in the server (30), the terminal control unit (110) downloads it from the server (30).

The above various functions of the terminal control unit (110) are basically realized by the CPU (11) of the game terminal (10) executing a program stored in a memory device (ROM (12), RAM (13), or auxiliary memory device (14), etc.).

The data storage unit (100) is realized by at least one of a ROM (12), a RAM (13), or an auxiliary memory device (14). The data storage unit (100) stores data necessary for providing a game. As a specific example of data stored in the data storage unit (100), data necessary for providing the baseball game described above will be described. The data storage unit (100) stores a user information table (TBL11), a character information table (TBL2), a team information table (TBL3), and a user team table (TBL12). In addition, since the character information table (TBL2) (see Fig. 9), the team information table (TBL3) (see Fig. 10), and the user team table (TBL12) (see Figs. 16 and 17) have already been described, their descriptions are omitted here.

Figure 20 illustrates an example of a user information table (TBL11). The user information table (TBL11) includes fields such as "User ID," "User Name," "Favorite Team," "Matching Rate," "Game Level," "Owned Points," "Tournament Points," "Reward," "Match Result Information," and "Owned Character Information."

The above game level is information that evaluates the user's skill level in the baseball game. The above-mentioned possession points are points that the user owns and can use within the game. For example, possession points could be a virtual currency available to the user in a baseball game, or they could be a reward for playing the baseball game, consumed when the user plays the game.

The "Tournament Points" field stores tournament points (total points, points per tournament, etc.) earned in various tournaments in online tournament mode. The "Rewards" field stores rewards (items, etc.) earned in online tournament mode. The "Owned Character Information" field stores the character IDs of player characters acquired by the user in-game. The "Match Results Information" field stores information about the results of matches in various tournaments in online tournament mode (e.g., wins, losses, goals scored, etc.).

The "Owned Character Information" field stores the character IDs of characters acquired and currently owned by the user within the game. There are several ways to acquire characters. For example, a user can acquire characters through a raffle by executing a raffle mode. In this raffle mode, a character is selected from all characters within the game. To activate the raffle mode, the user may need, for example, a certain amount of in-game points, in-game items, etc. Furthermore, for example, a user may receive characters as gifts from other users (e.g., other users connected to the user). Furthermore, for example, a user may acquire characters as a reward for playing within the game. Furthermore, for example, a user may acquire original player characters developed in the training mode. Furthermore, for example, a predetermined number of characters may be granted to the user as owned characters upon starting the game.

Characters remembered in the "Owned Character Information" field can be selected and used by the user in battle games or other game modes other than the Player Random Cup and Team Random Cup, but cannot be selected and used by the user in the aforementioned Player Random Cup and Team Random Cup.

[4. Functional Configuration of the Server]

Fig. 21 is a schematic functional block diagram showing an example of the functional configuration of a server (30) (an example of a game control device). The server (30) includes a data storage unit (300). For example, the data storage unit (300) is realized by at least one of a database (DB), a ROM (32), a RAM (33), or an auxiliary memory device (34). The data storage unit (300) stores data necessary for providing a game.

As a specific example of data stored in the data storage unit (300), data required to provide the baseball game described above will be described. The data storage unit (300) stores a tournament information table (TBL1), a character information table (TBL2), a team information table (TBL3), a user management table (TBL4), a match management table (TBL5), a character selection condition table (TBL6), a team selection condition table (TBL7), randomly selected character data (DT1), and randomly selected team data (DT2). The character selection condition table (TBL6), the team selection condition table (TBL7), the randomly selected character data (DT1), and the randomly selected team data (DT2) will be described later.

Since the tournament information table (TBL1) (see Fig. 4), character information table (TBL2) (see Fig. 9), and team information table (TBL3) (see Fig. 10) have already been explained, a detailed explanation is omitted here. As for the character information table (TBL2) and team information table (TBL3), substantially the same data is also maintained in each user's game terminal (10). For example, when the game operator changes the information in the character information table (TBL2) or team information table (TBL3) of the server (30), the changed information is transmitted from the server (30) to the game terminal (10) via the network N.

Fig. 22 illustrates an example of a user management table (TBL4). The user management table (TBL4) is a data table for managing all users playing a game in the game system (1). The user management table (TBL4) includes fields such as "user ID," "user name," "matching rate," and "tournament points." Although omitted in Fig. 22, other fields are also included in the user management table (TBL4). For example, fields such as the user's game level, owned points, and the user IDs of other users (colleagues, friends, etc.) associated with the user are included in the user management table (TBL4).

Fig. 23 shows an example of a match management table (TBL5). The match management table (TBL5) is a data table for managing match games executed in the game system (1). The match management table (TBL5) is associated with a tournament ID and is stored for each tournament (each tournament ID). The example in Fig. 23 shows an example of a match management table (TBL5) that manages all match games held under tournament ID: E1 (Player Random Cup 1). The match management table (TBL5) includes fields such as "match ID," "first user ID," "second user ID," and "match result."

The "Match ID" is identification information used to uniquely identify a match game held in a tournament with a tournament ID associated with the Match Management Table (TBL5). The "Match ID" field assigns and stores a match ID each time a match game is held during the holding period of the target tournament. Furthermore, the user ID of one of the two users matched in the target match game is stored in the "First User ID" field, and the user ID of the other user is stored in the "Second User ID" field. The "Match Result" field stores information regarding the match game's outcome (e.g., win/loss, goals scored, etc.). Although omitted in Figure 23, other fields are also included in the Match Management Table (TBL5). For example, the Match Management Table (TBL5) includes fields such as team information for each competing user (in the aforementioned baseball game, which of the 12 teams).

The game system (1) or server (30) of the present embodiment provides a game in which a user can participate in a specific battle game.

Here, a "user" refers to, for example, a person playing a game provided by the game system (1). For example, user identification information is associated with each user, and each user is identified (specifically identified) by the user identification information. "User identification information" refers to information that uniquely identifies each user. Examples of "user identification information" include a user ID, a unique user name, or an email address.

Furthermore, a "competition game" is, for example, a computer game in which a user competes against an opponent to determine superiority or victory. For example, an online competition game played between multiple user terminals (10) connected via a network N is an example of a "competition game." Here, a "competition" refers to determining superiority or victory against an opponent. The outcome of a competition game does not necessarily have to be a win or loss, and a draw may be possible. Examples of "competitions" include matches in sports games and battles in combat games.

A user's opponent may be one user, or two or more. For example, the aforementioned baseball game, in which two users each use multiple player characters from their respective baseball teams to compete, is an example of a "competition game." Furthermore, a game in which three or more users each use their own characters to battle within the same game space is an example of a "competition game."

The above "battle game" is, for example, a battle game in which the user and the opponent each independently operate the objects they are using. In addition, the above "battle game" may also be, for example, a battle game in which a computer automatically determines the outcome of the battle by executing a simulation process based on the user's object and the opponent's object, and in which the user and the opponent operate their own objects only in specific scenes. In addition, the above "battle game" may also be, for example, a battle game in which the outcome of the battle is automatically determined by executing a simulation process based on the user's object and the opponent's object.

The above "competition game" may be, for example, a specific competition game held within a predetermined period. Here, the "predetermined period" refers to a predetermined period of time, such as the period during which a competition game in which users can participate is held. Here, the "period" may be a period of time measured in days of the week, such as Friday to Sunday, a period of time measured in days, such as March 1 to March 5, or a period of time measured in hours, such as from 7:00:00 AM to 9:00:00 PM the following day. Alternatively, the "period" may be a period measured in weeks, months, or days, for example.

Furthermore, a "specific battle game" refers to a battle game in which users cannot select the objects, etc., that can be used in battles. For example, a battle game in which the objects, etc. that can be used by each user in a battle are randomly selected based on the same selection conditions is an example of a "specific battle game." In the baseball game example described above, one or more battle games held in the Player Random Cup or Team Random Cup are examples of a "specific battle game."

A fighting game that differs from a "specific fighting game" may be referred to as a "second fighting game." Specifically, a "second fighting game" refers to a fighting game in which the user can select the target of use, such as objects available in the battle. In the baseball game example mentioned above, a fighting game held in a tournament other than the "Player Random Cup" or "Team Random Cup" held in online competition mode, or a fighting game in free competition mode, would be an example of a "second fighting game."

"A specific competitive game held within a predetermined period" refers to, for example, one or more specific competitive games held within a predetermined period determined by the game operator. For example, a specific competitive game held during a limited-time game tournament held by the game operator is an example of a "specific competitive game held within a predetermined period." Here, a "game tournament" refers to, for example, a game-related event in which participating users compete against each other for superiority, wins or losses, rankings, etc. In the baseball game example mentioned above, the "Player Random Cup" or the "Team Random Cup" are examples of "game tournaments."

Furthermore, for example, a "specific battle game held within a predetermined period of time" may grant users rewards such as points or items that can be used in the game based on wins or losses or rankings, or may grant them titles such as units. Furthermore, for example, a "specific battle game held within a predetermined period of time" may be held as a so-called e-sports competition, and may not particularly include prize money or giveaways. In the example of the baseball game mentioned above, one or more battle games held in a player random cup or team random cup, where the competition holding period is determined in advance, are an example of a "specific battle game held within a predetermined period of time."

A "specific competitive game" does not have to be a competitive game held during a predetermined period. For example, a "specific competitive game" can be a competitive game that each user can play at any time. In the baseball game example mentioned above, if a competitive game is available at any time, such as a Player Random Cup or Team Random Cup, without a time limit, then that competitive game would be considered an example of a "specific competitive game."

As shown in Fig. 21, the server (30) mainly includes a reception unit (310), a management unit (320), and a selection unit (330). These are basically realized by the CPU (31) of the server (30) executing a program stored in a memory device (ROM (32), RAM (33), or auxiliary memory device (34), etc.).

The reception section (310) of Fig. 21 has a function of accepting participation in the above-mentioned game.

Here, "accepting participation in a competitive game" means accepting a user operation (participation application operation) for participating in a competitive game. Alternatively, "accepting participation in a competitive game" may also mean receiving information indicating a user's intention to participate in a competitive game. For example, if a user performs a button operation, screen touch operation, voice input operation, etc. to participate in a competitive game, receiving information regarding such operation corresponds to an example of "accepting participation in a competitive game." Participation conditions for accepting participation in a competitive game may or may not be set. For example, in the case of a competitive game with participation conditions, participation in the competitive game may not be accepted if the participation conditions are not met. Furthermore, for example, in the case of a competitive game held within a specified period, participation in the competitive game may not be accepted outside of the specified period.

In the example of the baseball game described above, when the user performs an operation of selecting "Start Match" of part P403 in the menu screen G400 of the Player Random Cup (or Team Random Cup) of FIG. 8, the reception unit (310) accepts participation in the "Player Random Cup (or Team Random Cup) Competition Game" as an example of a specific competition game based on information about the operation. In addition, for example, in a competition game, when a process of matching users who will be opponents is executed, the reception unit (310) may accept participation in the competition game when the matching is successful and the opponent is determined. That is, the period from the user's participation application operation until the matching is successful may be referred to as a participation application waiting period, and when the matching is successful and the opponent is determined, participation in the competition game based on the participation application operation may be accepted.

In addition, the reception unit (310) may have a function for accepting participation in "a specific battle game in which the user cannot select the target of use of objects, etc., that can be used in battles" as well as participation in "a second battle game in which the user can select the target of use of objects, etc., that can be used in battles." In other words, the reception unit (310) should have a function for accepting participation in at least the specific battle game.

The management unit (320) of Fig. 21 has a function of managing multiple usable objects that can be used in the specific battle game by a user whose participation has been accepted by the reception unit (310) by storing them in a memory device.

Here, "target of use" refers to an object that can be used by a user in a battle game. The target of use can be defined as an object that can be used by the user during the battle game.

Here, an "object" is something that can be used in a game. For example, game characters, game cards, or game items are examples of "objects." For example, game characters or game cards representing people such as sports players, creatures such as racehorses, fictional people or creatures such as monsters, or inanimate objects such as robots are examples of "objects." For example, an "object" may be a game character or game card corresponding to a real person, or it may not necessarily correspond to a real person.

For example, in a game where a user uses one or more game characters to battle an opponent, the one or more game characters are examples of "targets of use." Furthermore, in a card game where a user builds a deck using multiple game cards and battles an opponent using the built deck, the multiple game cards contained in the deck are examples of "targets of use." In the baseball game example described above, the pitcher or fielder player characters that can be used in the player random cup battle game are examples of "targets of use."

Additionally, the target of use may be a group including two or more objects that can be used by the user during the battle game.

Here, a "group" is a group composed of two or more objects. A "group" can also be rephrased as a team, group, pack, party, or guild, for example. For example, in a baseball game, a baseball team composed of a certain number of player characters (e.g., 29) on the bench who can participate in a match would be an example of a "group." Similarly, in a soccer game, a soccer team composed of a certain number of player characters (e.g., 18 or 23) on the bench who can participate in a match would be an example of a "group."

For example, in a game where a user battles an opponent using a group (team, group, pack, party, guild, etc.) comprised of multiple game characters, the group (and the multiple game characters included in the group) would be an example of a "target of use." In the baseball game example described above, a team comprised of 29 player characters that can be used in a Team Random Cup battle game managed in the team information table (TBL3) of FIG. 10 would be an example of a "target of use."

The "multiple usage targets that can be used in the above-mentioned battle game by a user whose participation has been accepted by the reception unit (310)" managed by the management unit (320) include at least multiple usage targets that can be commonly used by all users who have been accepted to participate in a specific battle game. In addition, as described below, in order for a user to actually be able to use a usage target in a battle game, it is necessary to associate the usage target with user identification information (e.g., user ID). That is, the "multiple usage targets that can be used in the above-mentioned battle game by a user whose participation has been accepted by the reception unit (310)" managed by the management unit (320) are multiple usage targets that can be used by the user in the above-mentioned battle game when they are associated with the user identification information of the user in question.

The "multiple usage targets that the user can use in the above-mentioned battle game" managed by the management unit (320) are not limited to a specific battle game, and may be objects or groups that can be commonly used in battle games other than the specific battle game or in other game modes, for example. That is, the "multiple usage targets that the user can use in the specific battle game" managed by the management unit (320) may be managed specifically for a specific battle game, for example (in the example of the baseball game described above, managed as player characters specially prepared for the competition), or may be managed as objects that can be commonly used in battle games other than the specific battle game or in other game modes, etc.

In addition, the "multiple usage targets that the user can use in the above-mentioned battle game" managed by the management unit (320) may be all objects or groups handled within the game provided by the game system (1), or may be some of the objects or groups among them. In other words, among the usage targets (objects or groups) that the management unit (320) manages and that can be used in the game, "multiple usage targets that the user can use in a specific battle game" may be included.

In the example of the baseball game described above, the management unit (320) manages a plurality of player characters that the user can use in the game (including a player random cup or team random cup battle game) based on a character information table (TBL2) (see FIG. 9) stored in a memory device (database (DB), ROM (32), RAM (33), or auxiliary memory device (34), etc.).

The selection unit (330) of Fig. 21 has a function of randomly selecting, based on the same selection conditions, the target of use that can be used in the battle game, from among the plurality of target of use managed by the management unit (320), which is related to the user identification information of each user who is a battle opponent.

Here, the "target associated with user identification information" refers to a target of use, such as an object, that is remembered in association with user identification information. Here, "associating a target of use with user identification information" means enabling a user identified by the user identification information to use the associated target of use in the aforementioned competitive game.

"Targets of use associated with user identification information" refer to, for example, objects or other objects that can be used by the user in the aforementioned competitive game. For example, "Targets of use associated with user identification information" may be made available only for the aforementioned specific competitive game played within a specified period of time (or without a time limit).

For example, the “target of use associated with user identification information” does not continue to be associated even after the end of the specific battle game held within a given period of time and can be used in the next battle game, but rather, after the end of the battle (at any time between the end of the battle and the next battle game), the association with user identification information may be released or invalidated.

In addition, the “target of use related to user identification information” may be, for example, “not owned by the user who can use it in games other than the specific battle game played within a given period of time (e.g., battle games other than the specific battle game or other types of games).”

"Randomly selecting from among the plurality of usage targets managed by the management unit (320) based on the same selection conditions" means that usage targets associated with the user identification information of each user who will be a rival are randomly selected from among "multiple usage targets that can be commonly used by all users who have accepted participation in the above-mentioned competition game" managed by the management unit (320) based on the same selection conditions. Here, "same selection conditions" means that the same selection conditions are applied to all users who will be a rival.

"Randomly selecting based on selection conditions" means, for example, randomly selecting one or more of the above-mentioned subjects from a population based on the selection conditions. Here, "randomly selecting" means randomly extracting. For example, randomly sampling one or more of the above-mentioned subjects from the population by applying a known pseudo-random number generation algorithm is an example of "randomly selecting." Furthermore, for example, applying the same drawing probability to all of the above-mentioned subjects included in the population and drawing one or more of the above-mentioned subjects from the population based on the probability is an example of "randomly selecting."

The above "selection conditions" are, for example, conditions for randomly selecting the target of use that can be used in the specific battle game from among the multiple target of use managed by the management unit (320). In other words, the "selection conditions" are, for example, conditions for determining the population that will be the target of random sampling.

Each of the plurality of objects managed by the above management unit (320) is associated with a parameter. Here, the "parameter associated with the object" is a parameter set for the object. For example, in the case of a game character of a baseball player, the parameters of the game character's team affiliation, role (e.g., defensive position), and ability (ability related to batting, defense, base running, pitching, etc.) correspond to an example of the "parameter associated with the object." In addition, for example, the object's body type information (height, weight, foot length, hand size, etc.) or gender information may be included in the "parameter associated with the object."

And, the above selection condition may be a condition regarding the parameter. Here, "the above selection condition is a condition regarding the parameter" means that a condition regarding the parameter associated with the object is applied as the selection condition. Based on the condition regarding the parameter, the selection unit (330) randomly selects an object usable in the battle game from among a plurality of objects managed by the management unit (320) that satisfy the condition.

For example, the above parameters include information about the object's abilities. Furthermore, the selection conditions may include "conditions regarding the object's ability information."

Here, "ability information" refers to parameters indicating the abilities set for an object. "Ability information" may, for example, be information indicating the level of an object's ability. Furthermore, "ability information" may also, for example, indicate whether an object possesses a specific ability. Furthermore, "ability" may include, for example, the object's performance.

For example, in a baseball game, information indicating a player character's batting ability, defensive ability, base-running ability, or pitching ability, as an example of an object, corresponds to an example of "ability information." Furthermore, in a soccer game, information indicating a player character's offensive ability (shooting ability, passing ability, dribbling ability, etc.) or defensive ability (tackling ability, etc.), as an example of an object, corresponds to an example of "ability information." Furthermore, in a combat game, information indicating a character's offensive ability or defensive ability, as an example of an object, corresponds to an example of "ability information." Furthermore, information indicating the offensive performance or defensive performance of a weapon, as an example of an object, corresponds to an example of "ability information."

For example, in a baseball game, if all player characters available for the specific battle game are managed in the management unit (320), and one or more player characters whose ability values are within a predetermined range, for example, within the range of ability values 200 to 299, are randomly selected from among all the player characters, the condition that the ability values of the player characters are within the range of 200 to 299 corresponds to an example of a “selection condition.” In this example, all player characters whose ability values are within the range of 200 to 299 and are managed in the management unit (320) become a set of selection candidates (i.e., a population for random selection).

In the example of the baseball game described above, the conditions such as “350 or more”, “300 or more”, “300 to 349”, “200 to 299”, “150 to 350”, and “199 or less” of the comprehensive ability values shown in FIGS. 11 to 14 correspond to “conditions regarding object ability information” as examples of selection conditions.

Additionally, for example, the above parameters include role information of the object. Furthermore, the selection conditions may include "conditions regarding role information of the object."

Here, "role information" refers to a parameter that indicates the role assigned to an object. For example, in sports games like baseball or soccer, positions are an example of "roles." Similarly, in combat games, occupations are an example of "roles."

For example, in a baseball game, the positions of "pitcher" or "fielder" are examples of "role information." Furthermore, for example, "starter," "middle reliever," "set uppercut," or "closer," which are further subdivided from the pitcher position, are examples of "role information." Furthermore, for example, "infielder" or "outfielder," which are further subdivided from the "fielder" position, are examples of "role information." Furthermore, for example, "catcher," "first baseman," "second baseman," "third baseman," "shortstop," "center fielder," "right fielder," "left fielder," or "designated hitter (DH)," which are further subdivided from the "fielder" position, are examples of "role information."

Furthermore, the appropriate position information of an object corresponds to an example of "role information." Here, "appropriate position information of an object" refers to, for example, information evaluating the appropriateness of each of the pitcher's positions, "starter," "middle reliever," and "closer," in a baseball game. For example, in the case of the "starter" position, evaluation information such as "appropriate starting pitcher ◎," "appropriate starting pitcher ○," or "no appropriateness (or no evaluation)" corresponds to an example of "role information."

For example, in a baseball game, if one or more player characters whose position is catcher are randomly selected from among all player characters available in the game, the condition that the position is catcher corresponds to an example of a "selection condition." In this example, the population subject to random selection is all player characters whose position is catcher.

In the example of the baseball game described above, the conditions such as “pitcher”, “catcher”, “first baseman”, “starting pitcher aptitude ◎”, “middle reliever aptitude ◎”, “closer aptitude ◎”, “starting pitcher aptitude ○ or higher” shown in FIGS. 11 to 13 and FIG. 15 correspond to “conditions regarding role information of objects” as examples of selection conditions.

The above selection conditions may be a combination of multiple selection conditions. For example, the selection conditions may be a combination of "conditions regarding the object's ability information" and "conditions regarding the object's role information."

In addition, the above selection condition may be a condition that makes all of the multiple usage targets managed by the management unit (320), for example, a set of selection candidates (i.e., a random selection population).

If the above-mentioned battle game is a game in which a battle is fought between groups consisting of two or more objects, the user identification information of each user who is a battle opponent is associated with two or more objects among a plurality of objects managed by the management unit (320). In this case, it is preferable that the selection unit (330) set the selection conditions for selecting each of the two or more objects for each object to be selected.

The aforementioned baseball game is a game in which teams of 29 player characters compete against each other, and is an example of a "game in which groups of two or more objects compete against each other." Figures 11 and 12 illustrate a preferred example in which selection conditions are individually set for each of the 29 player characters. In this way, by appropriately setting selection conditions, such as positions and abilities, for each selected player character, a desired group can be formed without bias in positions or abilities.

Furthermore, when selecting two or more objects, the configuration is not limited to setting individual selection conditions for each of the two or more objects. For example, as illustrated in FIGS. 13 and 14 , a common selection condition may be set for multiple candidates for selection. For example, in FIG. 14 , a common selection condition of "comprehensive ability of 350 or higher" is set for five candidates for selection, Candidates 1 through 5.

Here, an example of a character selection condition table (TBL6) applied in the aforementioned player random cup battle game is shown in Fig. 24. The character selection condition table (TBL6) is a data table indicating selection conditions used in the random selection process by the selection unit (330). The character selection condition table (TBL6) includes fields for "candidate ID" and "selection condition."

The "Candidate ID" field represents identification information for uniquely identifying the characters to be selected in the random selection process by the selection unit (330). PS1 to 4 represent four pitchers (starting pitchers), PR1 to 3 represent three pitchers (middle relievers), PSM1 to 2 represent two pitchers (set uppercutters), PC1 to 2 represent two pitchers (closers), C1 to 2 represent two catchers, 1B1 to 2 represent two first basemen, 2B1 to 2 represent two second basemen, 3B1 to 2 represent two third basemen, SS1 to 2 represent shortstops, CF1 to 2 represent two center fielders, RF1 to 2 represent two right fielders, LF1 to 2 represent two left fielders, and PR1 to 2 represent the candidate IDs of each of the two random positions. These candidate IDs correspond to the candidates (1 to 4) of each position and the position random frame shown in Figures 11 and 12. In other words, the "candidate ID" is also position identification information that uniquely identifies the position of the character to be selected.

The "Election Conditions" field stores the election conditions applicable to each candidate ID. For example, the election conditions shown in Figures 11 and 12 are stored in the "Election Conditions" field. In other words, individual election conditions are set for each of the 29 candidates.

Next, specific examples of selection conditions when the target of use is a team (an example of a group) are shown. Fig. 26 shows an example of a team selection condition table (TBL7) applied in the aforementioned Team Random Cup battle game. The team selection condition table (TBL7) is a data table indicating selection conditions regarding a team used in the random selection process by the selection unit (330). The example of Fig. 27 shows a case where a user with user ID: U1 competes with a user with user ID: U2 in a battle game (match ID: M15) held in a tournament (Team Random Cup 1st) with tournament ID: E2.

The team selection condition table (TBL7) includes fields for "Team Selection Condition ID" and "Selection Condition." The team selection condition ID is identification information for uniquely identifying the team selection conditions applied in the Team Random Cup match. The "Selection Condition" field sets the team selection conditions. In the example of Fig. 26, four selection conditions are set: "All Teams (TC1 to TC6, TP1 to TP6)", "First League (TC1 to TC6)", "Second League (TP1 to TP6)", and "Japan Series (TC1, TP6)". In the case of the selection condition of "All Teams", a random selection is performed targeting all 12 teams. In other words, when the selection condition of "All Teams" is applied, a random selection is performed without actually setting a selection condition. In the case of the selection condition of "First League", a random selection is performed targeting the six teams (TC1 to TC6) belonging to the First League. In the case of the above-mentioned "2nd League" selection condition, a random selection is conducted among the six teams (TP1 to TP6) belonging to the 2nd League. In the case of the above-mentioned "Japan Series" selection condition, a random selection is conducted among the teams participating in the Japan Series of real-world professional baseball (e.g., TC1 and TP6, as set by the game management).

Additionally, while the above example illustrates registering multiple team selection conditions in the team selection condition table (TBL7), this is not a limitation. Team selection condition information may be stored in a memory device without using the team selection condition table (TBL7).

Next, we will describe a case where the object corresponds to a real person. In this case, it is preferable to set the parameters associated with the object to imitate the real person corresponding to the object.

Here, a "real person" refers to a person from the real world, such as a prominent figure from the real world. Examples of "real people" include real-world athletes, martial artists, or entertainers. For example, a "real person" could include a person who actually existed in the past, such as a prominent figure from history, or only a currently living person. Furthermore, for example, in the case of athletes, retired former athletes could be included in the "real person" category, or only active athletes could be considered "real people."

For example, in a baseball game, a player character or game card corresponding to a real baseball player corresponds to an example of an "object corresponding to a real person." In this case, for example, the ability parameters of a player character are set based on the baseball player's performance in a real game (performance as a fielder (batting average, runs batted in, home runs, strikeouts, stolen bases, or errors) or performance as a pitcher (ERA, wins, strikeouts, walks, or speed, etc.). In addition, for example, in a soccer game, a game character or game card corresponding to a real soccer player corresponds to an example of an "object corresponding to a real person." In this case, for example, the ability parameters of a game character are set based on the soccer player's performance in a real game (number of goals, number of assists, number of shots, pass success rate, or number of fouls, etc.).

For example, in the case of a player character corresponding to a real baseball player, such as in the aforementioned baseball game, setting parameters of the player character's team, defensive position, and abilities (such as batting, defense, base running, and pitching abilities) based on the real baseball player's team, position, and performance (such as batting average or ERA) is equivalent to an example of "setting parameters related to an object to imitate the real person corresponding to the object."

In the aforementioned baseball game, users can simulate real-world matches within the game using player characters modeled after real baseball players. In particular, in the Team Random Cup match game, a simulated match of a real-world professional baseball game can be realized within the game. As described above, by implementing a simulated match using the same match card in the game before a match scheduled in the real world (e.g., a Japan Series match) is held, the excitement of the real-world match card can be heightened through the game. Here, in the Team Random Cup match game, a team including multiple player characters modeled after real people used in the in-game simulated match is randomly assigned to each competing user, so that simulated matches using various match cards can be realized without bias.

Next, a preferred configuration is described in which a random selection of a target is performed each time a battle game is played. Each user can play the battle game multiple times within a predetermined period of time, and it is preferred that the selection unit (330) perform a random selection based on the same selection conditions each time the battle game is played within the predetermined period of time.

In the aforementioned baseball game, during the Player Random Cup or Team Random Cup period, users can play multiple matches, and in each match, player characters or teams associated with the user IDs of the two competing users are randomly selected based on the same selection conditions. The player characters or teams randomly assigned to users in the match are reset for the next match, and new player characters or teams are randomly selected.

In this way, each time a match is held, a player character or team associated with the user's user ID is randomly selected, so each user participating in the match is assigned a variety of player characters or teams without bias. In particular, in Team Random Cup match games, which simulate real-world team matches within the game, each user's assigned team is randomly selected for each match, so any team can be used by users with a wide range of skill levels. Therefore, when the results of in-game match matches are tallied, statistically speaking, the in-game team that corresponds to the strongest real-world team will be ranked higher. Therefore, by aggregating the results of in-game match matches, the game can predict and enjoy the results of subsequent matches using the Battle Card in the real world.

[5. Processing]

Next, an example of processing executed in the game system (1) of the present embodiment is described below.

Fig. 28 is a sequence chart showing an example of processing of a game system (1). This Fig. 28 shows an example of processing when a player random cup battle game (an example of a specific battle game) of the aforementioned baseball game is performed between a game terminal (10-1) of a user with user ID: U1 and a game terminal (10-2) of a user with user ID: U2. Hereinafter, the user with user ID: U1 is referred to as "user U1", and the user with user ID: U2 is referred to as "user U2".

In the game terminal (10-1), when user U1 performs an operation to participate in a player random cup match, information regarding the operation is transmitted to the server (30) via the network N (S100-1). For example, in the game terminal (10-1), when user U1 performs an operation to select part P403 "Start Match" of the menu screen G400 of the player random cup of FIG. 8, match participation request information as information regarding the operation is transmitted to the server (30). Similarly, in the game terminal (10-2), when user U2 performs an operation to participate in a player random cup match, information regarding the operation is transmitted to the server (30) via the network N (S100-2).

The server (30) receives information on the operation of participating in a match from the game terminals (10-1 and 10-2) and executes a process for accepting participation in a match game of the Player Random Cup (S300). For example, if participation conditions are set, the server (30) may accept participation in a match game only if the participation conditions are met. In addition, for example, the server (30) may execute a matching process for determining a match opponent, and if the matching is successful, accept participation in a match game for the two matched users. Here, the explanation continues assuming that matching has been performed between user U1 of the game terminal (10-1) and user U2 of the game terminal (10-2).

In addition, although not described in FIG. 28, the server (30) may return response information indicating that participation has been accepted to the game terminals (10-1 and 10-2) that have accepted participation in the battle game. In addition, the server (30) may transmit information indicating that matching has been successful to the game terminals (10-1 and 10-2).

Thereafter, the selection unit (330) of the server (30) executes a process of randomly selecting a predetermined number (e.g., 29) of player characters available for use in the above-described battle game, which are associated with the user IDs of each user (U1, U2) who will be the opponents, from among a plurality of player characters managed by the management unit (320), based on the same selection conditions (S302). Here, an example of the process of S302 is described below with reference to the flowchart of Fig. 29.

The server (30) sets the selection conditions stored in the "Selection Conditions" field (S320) by referring to the character selection condition table (TBL6) exemplified in FIG. 24, which is applicable to the player random cup battle game. For example, the selection conditions for candidate ID:PS1 at the top of the character selection condition table (TBL6) are set sequentially.

And, the server (30) randomly selects a player character (S322) from among the character information table (TBL2) (an example of multiple player characters managed by the management unit (320)) illustrated in FIG. 9, based on the selection conditions set in S320. That is, the server (30) selects a player character by random drawing, using the player characters that satisfy the selection conditions among the player characters stored in the character information table (TBL2) as a population.

After that, the server (30) stores the character ID of the player character selected in S322 in relation to the user ID in a memory device (e.g., RAM (33), auxiliary memory device (34), database (DB), etc.) and generates randomly selected character data (DT1) (S324).

Fig. 25 shows an example of randomly selected character data (DT1). The randomly selected character data (DT1) is data that associates the character ID of a player character selected through a random selection process by a selection unit (330) with a user ID and stores it. The example of Fig. 25 shows a case where user U1 and user U2 compete against each other in a competition game (competition ID: M1) held in a competition (Player Random Cup 1st) with competition ID: E1. The randomly selected character data (DT1) of Fig. 25 shows data associated with the user ID of user U1, but similarly, the character ID of the player character selected through the random selection process is also associated with the user ID of the opponent user U2.

The randomly selected character data (DT1) of Fig. 25 includes fields for “candidate ID” and “character ID.” The candidate ID of the randomly selected character data (DT1) corresponds to the candidate ID of the character selection condition table (TBL6) of Fig. 24. Furthermore, the character ID of the player character selected through the random selection process by the selection unit (330) is stored in the “character ID” field of the randomly selected character data (DT1). That is, the character ID of the player character randomly selected based on the selection condition associated with the candidate ID of the character selection condition table (TBL6) of Fig. 24 is stored in association with the corresponding candidate ID in the randomly selected character data (DT1) of Fig. 25.

After S324, the server (30) determines whether the random selection process other than the position random frame (candidate IDs PR1 and PR2 of the rearmost part of FIGS. 24 and 25) has been completed (S326). If the server (30) determines "No" in S326, it returns to S320 and sets the selection conditions of the candidate IDs of positions for which the random selection process has not yet been completed by referring to the character selection condition table (TBL6) of FIG. 24. Thereafter, the server (30) repeats the processing of S320 to S326 until it determines "Yes" in S326. This completes the random selection process for positions other than the position random frame. The processing of S320 to S326 is a routine for randomly selecting a selection target (referred to as a first selection target) whose position (an example of a role) has been determined before the selection process.

If the server (30) determines "Yes" in S326, it proceeds to random selection processing S328 to S336 for the position random frame. The processing in S328 to S336 is a routine for randomly selecting a selection target (referred to as a second selection target) whose position has not been determined before the selection processing. In the selection processing for this second selection target, the selection unit (330) of the server (30) first randomly determines a position from among a plurality of positions, and randomly selects a player character based on the selection conditions corresponding to the determined position.

That is, the server (30) randomly determines one position from all positions (S328). In addition, the server (30) reads and sets the selection conditions associated with the candidate ID of the determined position from the character selection condition table (TBL6) (S330). In addition, the server (30) randomly selects a player character based on the selection conditions set in S330 (S332). In addition, the server (30) associates the character ID of the player character selected in S332 with the user ID and stores it as the random selection character data (DT1) of FIG. 25 (S334).

After S334, the server (30) determines whether all random selection processing has been completed (S336). If the server (30) determines "No" at S336, it returns to S328 and re-executes S328 to S336, thereby completing all random selection processing.

In addition, in Fig. 29, an example of randomly selecting a player character for each candidate ID of the selection target is shown, but for example, the random selection process for multiple candidate IDs may be executed approximately simultaneously through parallel processing.

In addition, although Fig. 29 illustrates an example in which processing S328 to S336 for the second selection target is performed after processing S320 to S326 for the first selection target, either processing may be performed first. Furthermore, as a variation, a player character associated with each user's user ID may be randomly selected only through processing S320 to S326 for the first selection target or only through processing S328 to S336 for the second selection target.

The processing illustrated in Fig. 29 (i.e., processing of S302 in Fig. 28) is executed for both users U1 and U2. Accordingly, as illustrated in Fig. 25, randomly selected character data (DT1) associated with each user ID of users U1 and U2 is generated.

Returning to Fig. 28 and continuing the explanation, the server (30) transmits the character ID of the player character randomly selected in S302 to the game terminal (10-1) of user U1 (S304-1). For example, the server (30) transmits at least the data of the "Character ID" field of the randomly selected character data (DT1) shown in Fig. 25 (i.e., 29 character IDs associated with the user ID of user U1) to the game terminal (10-1) of user U1. During this transmission, data such as the user ID and match ID are also transmitted, for example. Similarly, the server (30) transmits the 29 character IDs associated with the user ID of user U2 to the game terminal (10-2) of user U2 (S304-2).

In the game terminal (10-1) that has received 29 character IDs per team from the server (30), the 29 character IDs received are stored in the "Character ID" field of the user team table (TBL12) illustrated in Fig. 16. As a result, the player characters of the team associated with the user ID of user U1 become available for use in the player random cup battle game. The same applies to the game terminal (10-2) that has received 29 character IDs per team from the server (30).

Then, the aforementioned order formation, etc. are performed by user U1 and user U2, and a battle game is executed between the game terminal (10-1) and the game terminal (10-2) (S102). The battle game can be executed, for example, through direct communication such as a P2P connection between the game terminal (10-1) and the game terminal (10-2). In addition, the battle game may be executed via a server (30). During the battle game, user U1 and user U2 each operate their own team's player characters to progress the game.

Afterwards, when the battle game between user U1 and user U2 ends, the user terminal (10-1) and user terminal (10-2) transmit the results of the battle game to the server (30) (S104-1 and S104-2). In addition, if the battle game is executed via the server (30), S104-1 and S104-2 can be omitted.

After that, the server (30) transmits information for granting competition points and rewards to user U1 and user U2 according to the results of the competition game to the user terminal (10-1) and user terminal (10-2) (S306-1 and S306-2).

Next, an example of processing in a case where a team random cup battle game (an example of a specific battle game) of the aforementioned baseball game is played between users U1 and U2 in the game system (1) will be described. Fig. 30 is a sequence chart showing an example of processing in the game system (1).

When user U1 and user U2 perform an operation to participate in a team random cup battle game on the game terminal (10-1) and the game terminal (10-2), information regarding the operation is transmitted to the server (30) via the network N (S140-1 and 140-2). The server (30) receives information regarding the battle participation operation from the game terminal (10-1 and 10-2) and executes a process for accepting participation in the team random cup battle game (S340).

Thereafter, the selection unit (330) of the server (30) executes a process of randomly selecting a team (an example of a target of use) that can be used in the above-mentioned battle game, which is associated with the user IDs of each user (U1, U2) who will be the opponents, from among multiple teams managed by the management unit (320), based on the same selection conditions (S342). Here, an example of the process of S342 is described below with reference to the flowchart of Fig. 31.

The server (30) sets the team selection conditions applicable to the Team Random Cup match (S360). For example, referring to the team selection condition table (TBL7) illustrated in FIG. 26, a selection condition stored in the "Selection Condition" field is set. For example, a selection condition may be set for all teams (12 teams) or for two teams participating in the Japan Series.

Then, the server (30) randomly selects a team (S362) from among the team information table (TBL3) (an example of multiple teams managed by the management unit (320)) illustrated in FIG. 10, based on the selection conditions set in S360. That is, the server (30) selects a team by random drawing, using the teams that satisfy the selection conditions among the 12 teams stored in the team information table (TBL3) as the population.

After that, the server (30) stores the team ID of the team selected in S362 in relation to the user ID in a memory device (e.g., RAM (33), auxiliary memory device (34), database (DB), etc.) and generates randomly selected team data (DT2) (S364).

Fig. 27 shows an example of randomly selected team data (DT2). The randomly selected team data (DT2) is data that associates the team ID of a team selected through a random selection process by a selection unit (330) with the user IDs of two users participating in a match and stores it. Fig. 27 shows an example in which, in a match game (match ID: M15) held in a tournament (Team Random Cup 1st) with tournament ID: E2, the team selection condition ID: S1 of "all teams" is applied, team ID: TC1 is associated with user ID: U1, and team ID: TP6 is associated with user ID: U2.

Returning to Figure 30 and continuing the explanation, the server (30) transmits the team ID of the team associated with user ID: U1 among the teams randomly selected in S342 to the game terminal (10-1) of user U1 (S344-1). During this transmission, data such as the user ID and match ID are also transmitted. Similarly, the server (30) transmits the team ID of the team associated with user ID: U2 to the game terminal (10-2) of user U2 (S344-2).

The game terminal (10-1) that received the team ID from the server (30) refers to the team information table (TBL3) of Fig. 10 and acquires the 29 character IDs registered in the "Player Registration" field corresponding to the received team ID. Then, the game terminal (10-1) stores the 29 character IDs acquired above in the "Character ID" field of the user team table (TBL12) exemplified in Fig. 17. As a result, the team assigned to user U1 (the 29 player characters that make up the team) becomes available for use in the Team Random Cup match game. The same applies to the game terminal (10-2) that received the team ID from the server (30).

Since the subsequent processing of S142, S144-1, S144-2, S346-1 and S346-2 is the same as the processing of S102, S104-1, S104-2, S306-1 and S306-2 of Fig. 28, the description thereof is omitted.

[6. Summary]

In the game system (1) according to the embodiment described above, the "player characters or teams (each an example of a target of use)" associated with the user identification information of each user who is to compete against each other are not selected by each user, but are randomly selected based on the same selection conditions from among multiple player characters or teams commonly usable in the competition game by the user who has accepted participation in the competition game. In other words, the targets that users can use in the competition game are randomly assigned from the "same population" for each user, ensuring fairness in the conditions of game play. Therefore, it is possible to avoid only associating popular player characters or teams with each user's user identification information, thereby eliminating the bias in the player characters or teams used by each user in the competition game. Furthermore, since the conditions for game play during the competition are fair, it is possible for users to compete purely in terms of their gaming skills. Therefore, the excitement of the competition game is promoted not only for the users competing but also for those spectating the competition.

In addition, in the game system (1), selection conditions such as position and ability are set for each player character (an example of an object) selected in a player random cup battle game (an example of a specific battle game), so that a desired team can be formed in which it is difficult for bias in position and ability to occur.

In addition, in the game system (1), in the player random cup battle game, among the player characters selected by the selection unit (330), a first selection target player character whose position has been determined before the selection and a second selection target player character (position random frame) whose position has not been determined before the selection are included. In addition, the selection unit (330) is configured to randomly determine a position from among a plurality of positions when selecting the second selection target player character, and randomly select the second selection target player character based on a selection condition corresponding to the determined position. By this configuration, the player characters assigned to the user can include not only player characters of determined positions, but also player characters whose positions are unknown until the selection, thereby increasing the interest of the game.

Furthermore, in the game system (1), parameters such as abilities associated with a player character may be set to imitate a real player (an example of a real person) corresponding to the player character. In this case, a mock match of a real-world match can be realized in the game between users using a player character imitating a real player. In particular, in the case of a team random cup match game (an example of a specific match game), a mock match of a match between real-world teams can be realized in the game. For example, if a mock match using the same match card is realized in the game before a match using a match card (team combination) scheduled in a real-world sport is held, the real-world match card can be heightened through the game. Here, since the team (an example of a group) including a character imitating a real person used in the mock match in the game is randomly assigned to each competing user, a mock match using a variety of match cards can be realized without bias.

Furthermore, in the game system (1), multiple battle games can be held during the tournament period (as an example of a predetermined period), and the above-mentioned random selection can be performed each time a battle game is held. According to this configuration, each user participating in a battle is assigned a variety of player characters or teams without bias for each match. In particular, when a mock match between real-world teams is realized in-game using characters modeled after real people, the team assigned to each user is randomly selected for each match, so that any team can be used by users with a variety of operating skills. Therefore, when the results of the in-game mock matches are aggregated, statistically, the in-game team that corresponds to a team that is actually strong in the real world will be ranked higher. Therefore, the results of the in-game mock matches can be predicted and enjoyed based on the aggregate results of the matches.

[7. Variant Example]

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

[7-1] The period during which the specific battle game can be played is not limited, and each user can play the specific battle game at any time. Each time the specific battle game is played, the selection unit (330) may execute the random selection process described above to randomly select a character or team related to the user ID.

[7-2] The above shows an example in which the player characters or teams that the user can use are reset for each match played during the Player Random Cup or Team Random Cup period, and the player characters or teams are randomly selected for each match. As a variation, for example, instead of resetting the player characters or teams that the user can use for each match, during the period of the tournament in which the user participates, the player characters or teams randomly assigned to the user in the first match may be used in the second and subsequent matches. In other words, the player characters or teams that are assigned to the user once during the tournament period may be used until the end of the said period.

[7-3] In addition, a player character or team assigned to a user once during a tournament held in the first period may be prevented from being used by the user in the next tournament (a tournament held in a second period different from the first period). For example, a player character or team randomly assigned to a user during a battle game held in the first period may be excluded from random selection in a battle game held in the second period. Alternatively, a player character or team assigned to a user during a tournament held in the first period may have a reduced selection probability, making it difficult to be selected in a tournament held in the second period.

[7-4] In addition, a player character or team randomly assigned to a user in a certain battle game may be made unavailable to the user in the next battle game (e.g., excluded from random selection). Alternatively, a player character or team randomly assigned to a user in a certain battle game may have a reduced selection probability, making it difficult for the user to be selected in the next battle game.

[7-5] Instead of randomly selecting the player character or team that the user can use for each match, it is also possible to randomly select the player character or team every time a predetermined number of matches are played. For example, if the predetermined number of matches is 3, the player character or team randomly assigned to the user in the first match is used from the 1st to the 3rd matches, and the player character or team randomly assigned to the user in the 4th match is used from the 4th to the 6th matches.

[7-6] The same player character or team may be assigned to each user competing against the other. For example, a randomly selected player character or team may be associated with the user IDs of both users, allowing both users to use the same player character or team in the competition. Furthermore, the same player character or team (e.g., a randomly selected player character or team) may be assigned to all users participating in the competition.

[7-7] First, a team to be assigned to a user is randomly determined, and a predetermined number of player characters associated with the user ID are randomly selected from among multiple player characters associated with the determined team.

[7-8] When a predetermined number of objects are randomly selected and associated with the user IDs of each user who will be competing against each other, there may be a certain difference in the abilities (e.g., the sum or average of ability values) of the predetermined number of objects selected for each user. Therefore, the following describes a configuration that can reduce this difference in abilities and increase the fairness of the game play conditions regarding abilities between competing users.

A battle game is a game in which teams (an example of a group) consisting of a first predetermined number (e.g., 29) of player characters (an example of objects) compete against each other. For example, this is the aforementioned Player Random Cup battle game. The selection unit (330) randomly selects a second predetermined number (e.g., 27) of player characters that are less than the first predetermined number, and then evaluates the ability difference of the second predetermined number of player characters selected for each competing user. For example, in the case of the aforementioned Player Random Cup battle game, after the random selection process of 27 player characters other than the position random frame is performed for two competing users, the difference between the users in the sum (or average, etc.) of the comprehensive abilities (an example of abilities) of the 27 player characters is calculated, and it is evaluated whether or not the difference exceeds a predetermined standard (e.g., less than 100). Here, if the ability difference exceeds a given standard, the selection conditions for the abilities applied to each user in the selection of the remaining player characters (e.g., selection of two players in the position random frame) are made different so that the ability difference is reduced. For example, if the sum of the comprehensive abilities of the 27 player characters assigned to user U1 through random selection is 100 or more greater than the sum of the comprehensive abilities of the 27 player characters assigned to user U2, the selection condition applied to user U1 is, for example, "comprehensive ability is 199 or less," and the selection condition applied to user U2 is, for example, "comprehensive ability is 200 or more."

The above illustrates a specific example of adjusting the selection conditions applied in the random selection of two players in a position random frame. However, this is not a limitation. For example, it can also be applied to a battle game between teams comprised of characters without a position random frame.

[7-9] Although the above description mainly focuses on examples of baseball games, the present invention can be applied to other games as well. For example, the present invention can be applied to various games, regardless of game format or genre, as long as the game includes at least a game mode of a competition format, such as other sports games (games based on soccer, tennis, American football, basketball, ice hockey, volleyball, rugby, etc.), racing games, fighting games, battle games, digital card games, role-playing games, simulation games, adventure games, or nurturing games. In particular, the present invention is suitable for games in which groups of two or more objects compete against each other.

[7-10] The above shows an example in which, for example, a reception unit (310), a management unit (320), or a selection unit (330) is provided on the server (30), but is not limited thereto. The game terminal (10) and the server (30) are capable of communicating with each other to transmit and receive various types of data, and are both information processing devices (computers) equipped with a CPU, ROM, RAM, auxiliary memory, a communication unit, etc., and basically have the same hardware configuration. Therefore, some of the various functions of the server (30) described above may be realized by the CPU (11) of the game terminal (10), and the remainder may be realized by the CPU (31) of the server (30). Alternatively, all of the various functions of the server (30) described above may be realized by the CPU (11) of the game terminal (10).

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

[7-12] The computer-readable program according to the present embodiment is recorded on various computer-readable recording media such as a hard disk, an optical disk (CD-ROM, DVD-ROM, etc.), a flexible disk, a semiconductor memory, etc., and is read from the recording media and executed by the CPU of a computer constituting the game system (1) or the game control device. In addition, the means for providing the program to the computer is not limited to the aforementioned recording media, and may be performed via a communication network such as the Internet.

[8. Swelling]

From the above description, the present invention can be understood, for example, as follows. Furthermore, to facilitate understanding of the present invention, reference numerals in the accompanying drawings are conveniently placed in parentheses; however, the present invention is not limited to the illustrated embodiments.

1) A game system (1) according to one embodiment of the present invention provides a game (e.g., a baseball game) in which a user can participate in a specific competition game (e.g., a player random cup or team random cup competition game), and includes: a reception means (310) for receiving participation in the competition game; a management means (320) for storing in a storage device a plurality of usage targets (TBL2 or TBL3) usable in the competition game by a user whose participation has been received by the reception means (310); and a selection means (330) for randomly selecting, from among the plurality of usage targets managed by the management means (320), the usage targets (e.g., player characters or teams) usable in the competition game, which are associated with user identification information (e.g., user ID) of each user who is to be a competition opponent, based on the same selection condition (TBL6 or TBL7).

10) A game control device (10 or 30) according to one embodiment of the present invention provides a game in which a user can participate in a specific battle game, and includes a reception means (310) for receiving participation in the battle game, a management means (320) for storing in a storage device a plurality of use objects usable in the battle game by a user whose participation has been received by the reception means (310), and managing them, and a selection means (330) for randomly selecting, based on the same selection condition, from among the plurality of use objects managed by the management means (320), the use objects usable in the battle game, which are associated with user identification information of each user who becomes a battle opponent.

11) A program according to one embodiment 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 as a game control device (10 or 30) described in 10).

12) An information storage medium according to one embodiment of the present invention is a computer-readable information storage medium recording the program described in 11).

13) A control method of a game system (1) according to one embodiment of the present invention is a method of controlling a game system that provides a game in which a user can participate in a specific battle game, and includes a reception step (S300 or S340) for receiving participation in the battle game, a management step for storing in a storage device a plurality of use targets (TBL2 or TBL3) that can be used in the battle game by a user whose participation has been received by the reception step (S300 or S340), and a selection step (S302 and S320 to S336, or S342 and S360 to S364) for randomly selecting the use targets that can be used in the battle game, which are associated with user identification information of each user who becomes a battle opponent, from among the plurality of use targets managed by the management step based on the same selection condition.

14) A method for controlling a game control device (10 or 30) according to one embodiment of the present invention is a method for controlling a game system that provides a game in which a user can participate in a specific battle game, and includes a reception step (S300 or S340) for receiving participation in the battle game, a management step for storing in a storage device a plurality of use targets (TBL2 or TBL3) that can be used in the battle game by a user whose participation has been received by the reception step (S300 or S340), and a selection step (S302 and S320 to S336, or S342 and S360 to S364) for randomly selecting, based on the same selection condition, the use targets that can be used in the battle game, which are associated with user identification information of each user who becomes a battle opponent, from among the plurality of use targets managed by the management step.

According to the aspects described in 1), 10), and 14), the usage targets associated with the user identification information of each user who is a matchmaker are not selected by each user, but are randomly selected by the user who has accepted participation in the matchmaker game from among multiple usage targets commonly available in the matchmaker game based on the same selection conditions. In other words, the usage targets that users can use in the matchmaker game are randomly assigned to each user from the "same population," ensuring fairness in the game play conditions. Therefore, it is possible to eliminate the bias in the usage targets used by each user in the matchmaker game by avoiding that only popular usage targets or high-ability usage targets are associated with each user's user identification information. Furthermore, since the gameplay conditions during the match are fair, it becomes possible to have users compete purely in terms of their gaming skills. Therefore, the excitement of the matchmaker game is promoted not only for the users competing but also for those spectating the match.

2) In one aspect of the present invention, the object of use may be an object (e.g., a player character) that can be used by the user during the battle game.

According to the aspect described in 2), the imbalance of objects used by each user in a battle game can be resolved.

3) In one aspect of the present invention, the above-described battle game is a game in which a group (e.g., a team) composed of two or more objects (e.g., player characters) competes against each other, and the user identification information of each user who is a battle opponent is associated with two or more objects among a plurality of objects (TBL2) managed by the management means (320), and the selection means may set the selection conditions (TBL6) for selecting each of the two or more objects for each object to be selected.

According to the aspect described in 3), by setting selection conditions such as roles and abilities for each object to be selected, a desired group can be formed in which it is difficult for imbalances in roles and abilities to occur.

4) In one aspect of the present invention, a parameter is associated with each of the plurality of objects managed by the management means (320), the selection condition is a condition related to the parameter, and the selection means (330) may randomly select an object usable in the battle game from among the plurality of objects managed by the management means (320) that satisfy the condition based on the condition related to the parameter.

According to the aspect described in 4), as a selection condition for random selection, conditions regarding various parameters related to the object can be set.

5) In one aspect of the present invention, the parameter may include capability information of the object.

According to the aspect described in 5), the user identification information of each user who is a rival is associated with a randomly selected user based on the "same selection conditions" regarding the object's ability parameters. Therefore, the fairness of the gameplay conditions regarding the abilities of the objects available to each user who is a rival in the game is guaranteed.

6) In one aspect of the present invention, the parameter may include role information (e.g., position information) of the object.

According to the aspect described in 6), the usage target associated with the user identification information of each user who is a rival is randomly selected based on the "same selection conditions" regarding the object's role parameters. Therefore, the fairness of the gameplay conditions regarding the role of the objects available to each user who is a rival in the game is guaranteed.

7) In one aspect of the present invention, the target of use may be a group (e.g., a team) including two or more objects that can be used by the user during the battle game.

According to the aspect described in 7), the imbalance of groups used by each user in a battle game can be resolved.

8) In one aspect of the present invention, the object is an object (e.g., a player character) corresponding to a real person (e.g., a baseball player), and the parameters associated with the object may be set to imitate the real person corresponding to the object.

According to the aspect described in 8), a mock match of a real-world match can be realized in the game between users using objects imitating real people. In particular, when the target of use is a group including two or more objects (e.g., a team in a sports game), a mock match of a match between real-world teams can be realized in the game. For example, if a mock match using the same match card is realized in the game before a match using a match card (team combination) scheduled in a real-world sport is held, the real-world match card can be heightened through the game. Here, the group including the object imitating real people used in the mock match in the game is randomly assigned to each competing user, so that mock matches using various match cards can be realized without bias.

9) In one aspect of the present invention, each user can play the above-mentioned competitive game multiple times within a predetermined period (for example, within a competition holding period), and the above-mentioned selection means (330) may be configured to perform a random selection based on the same selection conditions each time the above-mentioned competitive game is played within the predetermined period.

According to the aspect described in 9), each time a battle game is played, a target associated with the user's identification information is randomly selected, so that each user participating in the battle is assigned a variety of targets for each battle without bias. In particular, when a mock battle between real-world teams is realized in the game using objects imitating real people, the group assigned to each user is randomly selected for each battle, so that any group can be used by users with various operating skills. Therefore, when the results of the in-game mock battles are aggregated, statistically, the in-game group corresponding to the team that is actually strong in the real world will be ranked higher. Therefore, the results of the battle card matches played in the real world can be predicted and enjoyed based on the aggregate results of the in-game mock battles.

15) In one aspect of the present invention, among the objects selected by the selection means (330), there are included a first selection target object whose role (e.g., position) has been determined before the selection, and a second selection target object whose role has not been determined before the selection (e.g., a player character of a position random frame), and when the selection means (330) selects the second selection target object, the role may be randomly determined from among a plurality of roles, and the second selection target object may be randomly selected based on the selection condition corresponding to the determined role.

According to the aspect described in 15), the objects assigned to users can include not only objects with determined roles, but also objects whose role is unknown until they are selected, thereby increasing the interest of the game.

16) In one aspect of the present invention, the battle game is a game in which a group (e.g., a team) composed of a first predetermined number (e.g., 29) of objects (e.g., player characters) competes, and the selection means randomly selects a second predetermined number (e.g., 27) of objects less than the first predetermined number based on the same selection condition, and then evaluates the ability difference (e.g., the sum or average of ability values) of the second predetermined number of objects selected for each user, and when the ability difference exceeds a standard, the selection condition applied to each user in the selection of the remaining objects may be different so that the ability difference becomes smaller.

According to the aspect described in 16), even if there is a certain difference in the ability of the objects selected for each user as a result of randomly selecting a second predetermined number of objects, the difference in ability can be reduced when selecting the remaining objects (the number obtained by subtracting the second predetermined number from the first predetermined number). Therefore, the fairness of the game play conditions regarding ability between competing users can be increased.

In addition, the specific implementation modes or examples made in the form of implementing the invention are only for clarifying the technical content of the present invention, and should not be narrowly interpreted as being limited to such specific examples, and can be implemented by changing them in various ways within the scope of the technical idea and patent claims of the present invention.

1: Game System
N: Network
DB: database
10: Game terminal
11: CPU
13: RAM
14: Auxiliary memory device
30: Server
31: CPU
33: RAM
34: Auxiliary memory device
100: Data storage
110: Terminal control unit
300: Data storage
310: Reception
320: Management Department
330: Elections
TBL1: Competition Information Table
300: Data storage
TBL2: Character Information Table
TBL3: Team Information Table
TBL4: User Management Table
TBL5: Match Management Table
TBL6: Character Selection Conditions Table
TBL7: Team Selection Conditions Table
TBL11: User Information Table
TBL12: User Team Table
DT1: Randomly Selected Character Data
DT2: Randomly Selected Team Data

Claims (13)

It is a game system that provides a game in which users can participate in a specific battle game.
A means of accepting applications for participation in the above-mentioned competition game,
A management means for managing multiple usable targets in the above-mentioned battle game by storing them in a memory device, by a user who has received participation through the above-mentioned reception means,
Includes a selection means for randomly selecting the target of use that can be used in the battle game, based on the same selection conditions, from among the plurality of target of use managed by the management means, and which is associated with the user identification information of each user who is a battle opponent.
The above-mentioned object of use is an object that can be used by the user during the above-mentioned battle game.
A game system in which, among the objects selected by the above-mentioned selection means, there are objects to be selected as first objects whose roles have been determined before the selection, and objects to be selected as second objects whose roles have not been determined before the selection, and in which, when selecting the objects to be selected as second objects, the above-mentioned selection means randomly determines the roles from among a plurality of roles, and randomly selects the objects to be selected as second objects based on the selection conditions corresponding to the determined roles. delete In the first paragraph, the battle game is a game in which a battle is fought between groups consisting of two or more objects,
The user identification information of each user who is a rival is associated with two or more objects among the plurality of objects managed by the management means,
A game system in which the above-mentioned selection means sets the selection conditions for selecting each of the two or more objects for each object to be selected. In the first paragraph, each of the plurality of objects managed by the management means has a parameter associated with it,
The above selection conditions are conditions regarding the above parameters,
A game system in which the above selection means randomly selects an object that can be used in the above-described battle game from among a plurality of objects managed by the above-described management means that satisfy the conditions based on the conditions regarding the above-described parameters. A game system in claim 4, wherein the parameter includes ability information of the object. A game system in claim 4, wherein the parameter includes role information of the object. A game system in the first paragraph, wherein the target of use is a group including two or more objects used by the user during the battle game. In the first paragraph, the object is an object corresponding to a real person,
A game system in which the parameters associated with the above object are set to imitate the real person corresponding to the object. In the first paragraph, each user can play the above-mentioned game multiple times within a given period of time,
The above-mentioned selection means is a game system that executes a random selection based on the same selection conditions each time the above-mentioned competition game is played within the above-mentioned predetermined period. A game control device that provides a game in which users can participate in a specific battle game.
A means of accepting applications for participation in the above-mentioned competition game,
A management means for managing multiple usable targets in the above-mentioned battle game by storing them in a memory device, by a user who has received participation through the above-mentioned reception means,
Includes a selection means for randomly selecting the target of use that can be used in the battle game, based on the same selection conditions, from among the plurality of target of use managed by the management means, and which is associated with the user identification information of each user who is a battle opponent.
The above-mentioned object of use is an object that can be used by the user during the above-mentioned battle game.
A game control device in which, among the objects selected by the above-mentioned selection means, there are included objects to be selected as first objects whose roles have been determined before the selection, and objects to be selected as second objects whose roles have not been determined before the selection, and in which, when selecting the objects to be selected as second objects, the above-mentioned selection means randomly determines the roles from among a plurality of roles, and randomly selects the objects to be selected as second objects based on the selection conditions corresponding to the determined roles. A program recorded on a recording medium for causing a computer to function as a game system described in any one of claims 1 and 3 to 9 or as a game control device described in claim 10. A computer-readable recording medium recording a program for causing a computer to function as a game system as described in any one of claims 1 and 3 to 9 or as a game control device as described in claim 10. A control method of a game system that provides a game in which users can participate in a specific battle game,
The reception staff who accepts participation in the above-mentioned competition game,
A management step that manages multiple usable targets of the above-mentioned battle game by storing them in a memory device, by a user who has received participation through the above-mentioned reception step,
Includes a selection step for randomly selecting the target of use that can be used in the battle game, based on the same selection conditions, from among the plurality of target of use managed by the management step, and which is associated with the user identification information of each user who is a battle opponent.
The above-mentioned object of use is an object that can be used by the user during the above-mentioned battle game.
A control method wherein, among the objects selected in the above selection step, there are included objects to be selected as first objects whose roles have been determined before the selection, and objects to be selected as second objects whose roles have not been determined before the selection, and wherein, in the case where the above selection step selects an object to be selected as the second object, the above selection step randomly determines the role from among a plurality of roles, and randomly selects an object to be selected as the second object based on the selection condition corresponding to the determined role.