Game system, game controller, and program

Abstract

To solve the problem of deviation of a use object, such as an object used in a match game.SOLUTION: A reception part accepts participation in a match game. A management part stores multiple use objects that a user whose participation is accepted by the reception part can use in the match game in a storage and manages them. A selection part randomly selects the use objects usable in the match game that are related to users' identification information of respective users to be matched mutually from among the multiple use objects managed by the management part on the basis of the same selection condition.SELECTED DRAWING: Figure 21

Description

[Technical Field]

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

[0002] Conventionally, games in which a user uses a group of multiple objects to compete against other users have been known. For example, a baseball game in which a user selects his / her favorite player characters from multiple player characters owned in the game to form a team and compete against an opposing team is known (for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 5612634 Summary of the Invention [Problem to be solved by the invention]

[0004] In the above-mentioned games, each user tends to prioritize the use of 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 tend to use objects corresponding to popular real-world players or teams corresponding to popular real-world teams, which can lead to bias in the objects and teams used in competitive games. This can lead to a large number of matches between popular players or popular teams.

[0005] Therefore, the object of the present invention is to provide a game system, a game control device, and a program that can eliminate the imbalance in objects used in a competitive game and the imbalance in groups consisting of multiple objects, thereby realizing a highly entertaining game. [Means for solving the problem]

[0006] A game system according to one aspect of the present invention is a game system that provides a game in which users can participate in a specific competitive game, and includes: an acceptance means for accepting participation in the competitive game; a management means for storing and managing in a storage device a plurality of usable objects that can be used in the competitive game by users whose participation has been accepted by the acceptance means; and a selection means for randomly selecting, based on identical selection conditions, from the plurality of usable objects managed by the management means, one of the usable objects that can be used in the competitive game and that is associated with user identification information of each user who will be competing against another user.

[0007] A game control device according to another aspect of the present invention is a game control device that provides a game in which users can participate in a specific competitive game, and includes: an acceptance means for accepting participation in the competitive game; a management means for storing and managing in a storage device a plurality of usable objects that can be used in the competitive game by users whose participation has been accepted by the acceptance means; and a selection means for randomly selecting, based on identical selection conditions, from the plurality of usable objects managed by the management means, the usable objects that are associated with user identification information of each user who will be competing against each other. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a schematic block diagram showing an example of the configuration of a game system according to an embodiment of the present invention. [Figure 2] FIG. 2 is a schematic block diagram showing an example of the hardware configuration of a game terminal. [Figure 3] FIG. 2 is a schematic block diagram illustrating an example of a hardware configuration of a server. [Figure 4] FIG. 10 is an explanatory diagram showing an example of a tournament information table. [Figure 5] FIG. 10 is an explanatory diagram showing an example of a game screen in a communication battle mode. [Figure 6] FIG. 10 is an explanatory diagram showing an example of a tournament selection screen. [Figure 7]FIG. 10 is an explanatory diagram illustrating an example of a message screen. [Figure 8] FIG. 10 is a diagram showing an example of a menu screen for the Random Player Cup. [Figure 9] FIG. 10 is a diagram illustrating an example of a character information table. [Figure 10] FIG. 10 is a diagram illustrating an example of a team information table. [Figure 11] FIG. 10 is a diagram showing an example of selection conditions for a pitcher character. [Figure 12] FIG. 10 is a diagram showing an example of selection conditions for fielder player characters. [Figure 13] FIG. 10 is a diagram showing another example of selection conditions for player characters. [Figure 14] FIG. 10 is a diagram showing another example of selection conditions for player characters. [Figure 15] FIG. 10 is a diagram showing another example of selection conditions for player characters. [Figure 16] FIG. 10 is a diagram illustrating an example of a user team table. [Figure 17] FIG. 10 is a diagram showing another example of a user team table. [Figure 18] FIG. 10 is a diagram showing an example of a battle result tally screen. [Figure 19] FIG. 2 is a schematic functional block diagram showing an example of the functional configuration of a game terminal. [Figure 20] FIG. 10 is a diagram illustrating an example of a user information table. [Figure 21] FIG. 2 is a schematic functional block diagram illustrating an example of a functional configuration of a server. [Figure 22] FIG. 10 illustrates an example of a user management table. [Figure 23] FIG. 10 is an explanatory diagram showing an example of a match management table. [Figure 24] FIG. 10 is a diagram showing an example of a character selection condition table. [Figure 25] FIG. 10 is a diagram showing an example of randomly selected character data. [Figure 26] FIG. 10 is a diagram showing an example of a team selection condition table. [Figure 27]FIG. 10 is a diagram showing an example of randomly selected team data. [Figure 28] 10 is a sequence chart showing an example of processing of the game system. [Figure 29] 10 is a flowchart illustrating an example of another process of the game system. [Figure 30] 10 is a sequence chart showing another example of the processing of the game system. [Figure 31] 10 is a flowchart illustrating an example of another process of the game system. DETAILED DESCRIPTION OF THE INVENTION

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

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

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

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

[0013] The server 30 is, for example, a server computer. The server 30 associates information about the user's game with a user ID for uniquely identifying each user, and stores and manages the information in, for example, a database DB. The database DB may be built within the server 30, or may be built in a server computer separate from the server 30.

[0014] Furthermore, server 30 executes processes such as opponent determination processing (so-called matching processing) when a communication battle (online battle) is conducted between users. In a communication battle, for example, user A operating game terminal 10-1 and user B operating game terminal 10-2 can play a battle game via network N. In this communication battle, for example, game terminal 10-1 and game terminal 10-2 matched by server 30 can directly communicate with each other via a P2P (Peer to Peer) connection or the like to conduct the battle. Alternatively, data exchange between game terminal 10-1 and game terminal 10-2 can be performed via server 30. Either method may be used to conduct the communication battle.

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

[0016] On the other hand, communication between game terminal 10-1 and game terminal 10-2 connected by P2P or the like can be realized by, for example, UDP (User Datagram Protocol), a communication protocol on the transport layer of the OSI reference model that is mainly implemented on the IP protocol. The above-mentioned UDP is a communication method in which data is sent to the other terminal device without any data delivery confirmation or error correction, and therefore has the advantage of low data reliability but high data transfer speed. It is of course possible to use existing protocols other than UDP for communication between game terminal 10-1 and game terminal 10-2, or to use new protocols that will be newly defined in the future.

[0017] Furthermore, for example, in a game terminal 10-n having a short-range wireless communication function using a predetermined frequency band (for example, the 2.4 GHz frequency band), multiple game terminals 10-n can communicate directly with each other to play competitive games, etc.

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

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

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

[0021] Communication unit 15 includes a communication interface (not shown) and has a communication control function for communicating data when a game is being played. 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., the 2.4 GHz frequency band). Communication unit 15 transmits a connection signal for connecting game terminal 10 to network N based on a command from CPU 11, and also receives information transmitted from the other party and supplies the information to CPU 11.

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

[0023] 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 electroluminescence (EL) display, can be used for the display unit 20. The display unit 20 can also be a touch panel that combines a display device, such as a liquid crystal display, with a position input unit having a touch interface. When the display unit 20 is configured as a touch panel, the image processing unit 17 includes a touch input detection unit (not shown). When a pointer, such as a finger or a pen, touches the screen, the touch input detection unit detects the coordinates of the contact position on the screen and supplies a coordinate signal to the CPU 11. This allows the CPU 11 to recognize the contact position on the screen of the display unit 20. The display unit 20 does not need to be integrated with the game device 10 and may be, for example, a television monitor externally connected to the game device 10.

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

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

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

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

[0028] The server 30 can be configured as a single computer, or can be configured as a function-distributed type in which the functions of the server 30 are distributed among multiple servers. Alternatively, a load-distributed type configuration can be achieved by providing multiple servers 30 on the network N for redundancy (multiplexing). The server 30 can also be configured as a cloud server that uses cloud computing technology.

[0029] The programs and data are supplied to game terminal 10 or server 30 from a remote location via network N and stored in RAM 13, auxiliary storage device 14, RAM 33, or auxiliary storage device 34. Game terminal 10 or server 30 may be provided with a component (such as an optical disk drive or a memory card slot) for reading programs and data stored in an information storage medium (such as an optical disk or a memory card). Then, the programs and data may be supplied to game terminal 10 or server 30 via the information storage medium.

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

[0031] For example, in a baseball game, various game modes, including a competitive game, are executed based on one or more objects (for example, game characters, game cards, game items, etc.). Below, a baseball game based on baseball will be described as an example of a game executed in the game system 1, and other games will also be mentioned as necessary.

[0032] In the baseball game of this embodiment, player characters modeled after real baseball players are provided as characters (examples of objects) that can be used in the game. That is, the names of real baseball players are set, and player characters are provided with ability parameters set based on the abilities and achievements of the baseball players. In the example baseball game of this embodiment, multiple player characters are provided corresponding to all baseball players registered under contract with the 12 professional baseball teams in Japan in the real world. Furthermore, when a new baseball player is registered under contract with 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 player characters corresponding to real baseball players may be updated periodically (e.g., monthly, weekly, after each game, etc.) or irregularly depending on the performance of the real baseball player during the season. Furthermore, for example, player characters corresponding to retired real professional baseball players may be made available for use in the game.

[0033] The player characters may be fictional baseball players. The baseball game of this embodiment also includes a game mode in which an original player character is trained. The original player character trained in this training mode may be used in various game modes together with player characters modeled after real baseball players.

[0034] The baseball game of this embodiment includes various game modes in addition to the training mode. For example, there is a computer battle mode (also referred to as a CPU battle mode) in which a user enjoys playing against a computer (CPU). In this computer battle mode, the user controls the batting, pitching, and fielding of his or her team's player characters against an opposing team whose player characters are automatically controlled by the CPU. There is also a manager play mode in which, for example, a user acquires player characters from among multiple player characters through a lottery based on probability, forms his or her own team with the acquired player characters, and competes as a manager. In this manager play mode, the user progresses through the game by giving instructions to the player characters, such as bunting, stealing bases, and hitting and running. The opponent in this manager play mode may be another user or a computer. There is also an offline battle mode in which, for example, two or more users can connect two or more controllers to a single game terminal 10 and play against each other. The baseball game of this embodiment also includes a communication battle mode in which a user can play against another user via communication. In this communication battle mode, a user can play against another user in real time online via a network N.

[0035] In the real-time battle, for example, a game between a user's team and an opponent's team (a baseball team of another user on the network N) progresses through a communication battle based on operations on each game device 10. For example, if the user is on defense and the opponent's user is on offense, a player character pitches or plays defense in response to the opponent's user's operation (pitching operation or fielding operation), and a player character bats or runs the bases in response to the user's operation (batting operation or base-running operation). In such an action game, the status of the game within the game is updated based on each user's operation on the player character. This real-time battle is a battle format that is also used in e-sports (electronic sports).

[0036] The online battle mode includes a "free battle mode" and an "online tournament mode." In the "free battle mode," users can choose their favorite team and player characters, and can also set the battle rules (such as the number of innings in a game) as they wish, allowing them to battle other users online at any time.

[0037] For example, in free battle mode, a user sets up a room (creates a room) for a free battle, which is a room where users can battle other users. When a user creates a new room, the user can set the battle rules as desired. If a room has already been created by a user, the user can enter the created room (for example, by selecting the room) to battle online with the user who set up the room. In other words, each user can battle by creating their own room and waiting for other users to enter the room, or by entering a room created by another user. If a user sets an arbitrary passcode when creating a room, only other users who know the passcode can enter the room and battle.

[0038] In online tournament mode, users can participate in online competitive game tournaments held as official tournaments by the game operator. Each user can participate in various official tournaments held regularly or irregularly, and compete in real-time against users from all over the country (or the world) via the network N. Various tournaments are held, for example, for a certain period of time (e.g., one week or three days). Each user can participate in one or more competitive games during the tournament period. Depending on the type of tournament, there may be tournaments where a limit is set on the number of matches that can be played during the tournament period, while there may be tournaments where matches can be played an unlimited number of times during the tournament period. Furthermore, for example, there may be tournaments where the number of matches that each user must play during the tournament period is specified.

[0039] When users participate in ongoing tournaments and play competitive games, they are awarded rewards (e.g., points or items that can be used in the game) and tournament points based on their match results. Users who participate in various tournaments in online tournament mode each earn "total tournament points," "weekly tournament points," and "tournament points earned in each tournament." Tournament points do not decrease based on match results; they increase the more competitive games they play. After each tournament ends, rankings are announced for each user based on the tournament points earned during the tournament period. Users are also awarded rewards (e.g., points or items that can be used in the game) based on their ranking in each tournament. Users can also earn rewards when their total tournament points reach a certain level. The main game cycle in online tournament mode is "participate in the tournament → compete → earn rewards → tournament end → ranking announcement → earn rewards based on ranking → participate in the next tournament." Various tournaments are held regularly or irregularly in online tournament mode, allowing users to enter tournaments of their interest, earn rewards, and enjoy real-time battles with users from around the country (or the world).

[0040] An example of a competitive game tournament held in online tournament mode will be described below. Tournaments include the "Regular Cup," "Beginner Cup," "Master Cup," "Real Speed ​​Cup," "Random Player Cup," and "Random Team Cup." Each tournament is a different type, with different tournament rules, participation conditions, tournament duration, and player characters that can be used in battles. This is merely an example, and other tournaments may also be held in online tournament mode.

[0041] FIG. 4 shows an example of a tournament information table TBL1 managed by the 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 "Random Player Cup," different tournament IDs are assigned to the "Random Player Cup 1st," "Random Player Cup 2nd," ... "Random Player Cup nth," and so on, which have different holding periods, and are managed individually.

[0042] The "Start Time" field in 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. Some tournaments have participation conditions, while others do not (i.e., anyone can participate). In 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 user's game level. For example, if a user participates in a tournament and plays a match, and as a result, wins against a user with a higher (or similar) matching rate, the user's matching rate MR will increase. On the other hand, if the user loses to a user with a lower (or similar) matching rate, the user's matching rate MR will decrease. Note that the user's matching rate MR may not change even if the user loses to a user with a matching rate higher or lower than the user's by a predetermined value or more. Conditions other than the matching rate MR may also be applied to the conditions for participating in a tournament. For example, the conditions for participating in a tournament may be the level of a player character owned by the user, the total number of wins in matches, the total win rate in matches, etc.

[0043] The "Tournament Rules" field indicates the rules of the games played in the tournament. The "Tournament Rules" field can include setting information such as the number of innings, whether or not there will be extra innings, the maximum number of innings in extra innings, the pitching speed level, and the difficulty level of the controls (the difficulty level of each of the batting controls, pitching controls, defensive controls, and base running controls). The tournament information table TBL1 also has other information fields. For example, it has a reward field that indicates the rewards that can be obtained by participating in the tournament, the rewards for winning a match, and the rewards according to the ranking.

[0044] For example, a tournament called the "Regular Cup" can be a tournament in which anyone can participate and in which the ball speed level and the difficulty level of the operation are set to a standard level. For example, the "Regular Cup" is held regularly every week from Monday to Sunday.

[0045] 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 ball speed level and the difficulty of operation are also set lower than the standard level. 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 more, and the ball speed level and the difficulty of operation are set to the standard level or higher. For example, the "Real Speed ​​Cup" can be a tournament in which the ball speed level is set to the highest level, real speed.

[0046] In the above-mentioned "Regular Cup," "Beginner Cup," "Master Cup," and "Real Speed ​​Cup," users participating in any of the tournaments can decide for themselves the team and player characters they will use in the match. For example, users can freely select their favorite team from a plurality of teams (in this embodiment, a plurality of teams corresponding to the 12 professional baseball teams in Japan) to compete against, and users can also organize their own team by freely selecting player characters to make up the team from among the player characters they own.

[0047] On the other hand, the "Random Player Cup" is a special tournament that differs from the aforementioned tournaments such as the "Regular Cup" in that all player characters for one team that a user can use in a match are randomly assigned for each match. The "Random Team Cup" is also a special tournament that differs from the aforementioned tournaments such as the "Regular Cup" in that the team that a user will use in a match (a team consisting of multiple default player characters) is randomly assigned for each match. Below, we provide an overview of the online match mode and an explanation of the game, mainly focusing on the "Random Player Cup" and "Random Team Cup."

[0048] Game screen G100 in FIG. 5 shows an example of a game screen when the online battle mode is selected by the user. Game screen G100 includes parts P101 to P109. Part P101 is a part for selecting the "online tournament mode." Part P102 is a part for selecting the "free battle mode." Part P103 is a part for transitioning to a screen for checking the user's cumulative ranking. Part P104 is a part for transitioning to a screen for setting the team composition. The user can set the team composition for a battle in the online battle mode in advance before the battle. However, the team composition that can be set by selecting this part P104 is only valid in battle games other than the "Random Player Cup" and "Random Team Cup." In other words, in the "Random Player Cup" and "Random Team Cup," the user cannot decide the team and player characters to use in the battle, so the team composition set in advance by selecting part P104 cannot be used.

[0049] Part P105 is a part for transitioning to a screen where the user can check the match history or tournament participation history. Part P106 is a part for transitioning to a screen where the user can check the total rewards earned in the online match mode. Part P107 is a part for transitioning to a screen where the user can set and change the user's profile. The profile that the user can set includes, for example, a nickname and the user's favorite team (for example, one of the 12 Japanese professional baseball teams).

[0050] Part P108 is a part for transitioning to a user setting screen. The user setting screen allows the user to set, for example, pitch speed levels. The user setting screen also allows the user to set the team to be used in the competitive game (pet mark, team icon, uniform, home stadium, cheering song, etc.). The team settings previously set by the user on this user setting screen are applied only to competitive games other than the "Random Player Cup" and "Random Team Cup," and are not applied to the "Random Player Cup" and "Random Team Cup." Part P109 is a part for transitioning to a screen on which a 12-team win / loss table for all matches played in the online competitive mode can be viewed. For example, a transition to a screen similar to the 12-team win / loss table illustrated in FIG. 18 is made.

[0051] When the user selects part P101 on the game screen G100 (using the operation unit 16), the screen transitions to the tournament selection screen G200 shown in FIG. 6. The tournament selection screen G200 is an example of a screen for selecting various tournaments in the online tournament mode. The tournament selection screen G100 includes parts P201 to P205. Part P201 is a part that indicates tournament information. There are as many parts P201 as there are tournaments selectable by the user, including parts not displayed on the tournament selection screen G200. By selecting part P202 or part P203, parts P201 indicating information about various tournaments can be switched and displayed on the tournament selection screen G200. The tournament for which part P201 is displayed on the tournament selection screen G200 is the currently selected tournament. Part P204 is a user interface that indicates the number of tournaments listed by the number of dots. The color of the dots for the selected tournament changes. The part P205 indicates the number of users currently competing in the selected tournament.

[0052] Part P201 displays information on whether the tournament is being held (for example, "currently being held," "ended," or "not yet held"). Part P201 also displays the tournament name, duration, total number of users participating in the tournament, tournament rules, rewards that can be obtained in the tournament, etc. After a user participates in a tournament, the user's ranking in the tournament is also displayed. Part P201 may also display the conditions for participation in the tournament. Furthermore, the conditions for participation may only be displayed for tournaments for which participation conditions have been set.

[0053] In the example of FIG. 6, the ongoing "Random Player Cup" is selected on the tournament selection screen G200. When the user performs a confirm operation on this tournament selection screen G200, the selection of the "Random Player Cup" is confirmed, and the screen transitions to the message screen G300 of FIG. 7. The message screen G300 is an example of a screen for confirming the user who selected the "Random Player Cup"'s intention to participate in the tournament. The message screen G300 includes parts P301 to P303. Part P301 displays an overview of the tournament, such as "This tournament is a tournament in which matches are played using players selected at random for each match." Part P301 also displays a message for confirming the user's intention to participate in the tournament, such as "Do you want to participate in the tournament?" Part P302 is a part that allows the user to select whether to participate in the tournament, and displays the word "Yes." Part P303 is a part that allows the user to select not to participate in the tournament, and displays the word "No."

[0054] 7, the message screen G300 notifies the user that the Random Player Cup is a tournament in which matches are played using randomly selected player characters, which is different from a normal tournament (a tournament in which the user can choose teams and player characters as they like), and provides a final confirmation of the user's intention to participate in the tournament. This message screen G300 may be omitted, or may be displayed only to users who have selected the Random Player Cup for the first time. For example, the message screen G300 may not be displayed to users who have already participated in the Random Player Cup.

[0055] If the user performs an operation to select "No" for part P303 on the message screen G300, the screen transitions to the tournament selection screen G200 of Fig. 6. On the other hand, if the user performs an operation to select "Yes" for part P302, the screen transitions to the Random Player Cup menu screen G400 of Fig. 8. Note that if the message screen G300 is omitted and the user selects "Random Player Cup" on the tournament selection screen G200 of Fig. 6, the screen transitions to the Random Player Cup menu screen G400 of Fig. 8.

[0056] The Random Player Cup menu screen G400 includes parts P401 to P406. Part P401 is a part that displays information related to the Random Player Cup. Part P401 displays information about whether the Random Player Cup is being held (for example, "Currently being held," "Ended," or "Not yet held"). Part P401 also displays the tournament name (for example, the nth Random Player Cup), the duration of the event, the total number of users participating in the Random Player Cup, the user's ranking in the Random Player Cup, the results in the Random Player Cup (for example, the number of wins, losses, draws, etc.), the tournament points earned in the Random Player Cup, etc.

[0057] Part P402 is a part that indicates the number of users currently competing in the Random Player Cup. Part P403 is a part for starting a competitive game in the Random Player Cup. When the Random Player Cup is in preparation for opening or has ended, part P403 becomes inactive and cannot be selected. Part P404 is a part for users to check the rewards they have earned in the Random Player Cup. Part P405 is a part for users to check their ranking in the Random Player Cup. Part P406 is a part that displays an image of a player character.

[0058] When the user performs an operation to select "Start Match" on part P403, participation in the competitive game is accepted, and the screen transitions to a standby screen (not shown), where a matching process is performed to determine an opponent. As an example of the matching process, users whose matching rates MR associated with the user IDs of the respective users are within a predetermined range are matched as opponents. If the matching is successful, for example, a matching success screen (not shown) is displayed.

[0059] If the matching is successful, a predetermined number of player characters available to each user who will be competing against each other are randomly selected from all player characters available for use in the Random Player Cup matches based on the same selection conditions. As will be described later, the selection conditions may be conditions related to parameters such as position information and ability information associated with the player characters. In this embodiment, 29 player characters are randomly selected for each user, but the number of player characters selected is not limited to this.

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

[0061] 9 shows an example of character information table TBL2. Character information table TBL2 is data for managing all characters used in a game provided by game system 1. Character information table TBL2 is stored and managed in the respective storage devices (e.g., RAM 13, auxiliary storage device 14, RAM 33, auxiliary storage device 34, database DB, etc.) of server 30 and game terminal 10. The character information tables TBL2 of server 30 and game terminal 10 are basically the same, and for example, when the game operator changes character information table TBL2 in server 30, the changed information is distributed from server 30 to game terminal 10 via network N. Character information table TBL2 includes a "character ID" field, a "name" field, a "team ID" field, "position information," "ability information," etc.

[0062] 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, the name of a real baseball player is set for a player character modeled after an actual baseball player.

[0063] The "Team ID" field indicates identification information for uniquely identifying the team (baseball club) to which the player character belongs. The team to which the player character belongs is managed by a team information table TBL3, an example of which is shown in FIG. 10. The team information table TBL3 is data for managing all teams (baseball clubs to which the player characters belong) used in the game provided by the game system 1. The team information table TBL3 is stored and managed in the respective storage devices (e.g., RAM 13, auxiliary storage device 14, RAM 33, auxiliary storage device 34, database DB, etc.) 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 management side changes the team information table TBL3 in the server 30, the changed information is distributed from the server 30 to the game terminal 10 via the network N.

[0064] The team information table TBL3 includes a "Team ID" field, a "Team Name" field, and a "Registered Players" field. The "Team Name" field indicates the name of the team to which a player character belongs. In other words, a player character is associated with the name of the team to which the player belongs via a character ID and a team ID. In this embodiment, the team name associated with a player character modeled after an actual baseball player is set to the name of the team to which the actual baseball player actually belongs. The "Registered Players" field will be described later. The team information table TBL3 may also include fields other than those described above, for example, a field related to the home stadium.

[0065] The "position information" in FIG. 9 indicates parameters related to the position of the player character. The "position information" includes a "main position" field that indicates the main position set for the player character. Each player character is set with one of the following defensive positions in baseball: "pitcher," "catcher," "first baseman," "second baseman," "third baseman," "shortstop," "center fielder," "right fielder," or "left fielder" as its main position.

[0066] Furthermore, the "position information" includes "position aptitude information" set for the player character. The "position aptitude information" includes fields for "starting aptitude," "relay aptitude," and "closer aptitude," which are information on position aptitude for the pitcher character. The "starting aptitude" field indicates an evaluation of the aptitude as a starting pitcher, the "relay aptitude" field indicates an evaluation of the aptitude as a relay pitcher, and the "closer aptitude" field indicates an evaluation of the aptitude as a closer. In this embodiment, the evaluation of position aptitude is shown in three levels, from highest to lowest: "◎," "○," and "- (no aptitude or no evaluation)." Without being limited to this, the evaluation of aptitude may be expressed using numbers, letters such as A, B, C, etc., or other symbols.

[0067] The "position aptitude information" also includes information on position aptitude for a fielder character. In the case of a fielder character, position aptitude for the main position and position aptitude for a secondary position that the character can play in addition to the main position are set.

[0068] The "ability information" includes an "overall ability" field. This "overall ability" field is an ability parameter that indicates the overall ability level of the player character. The overall ability may be expressed not only as a numerical value, but also as letters such as A, B, C, etc., symbols, etc.

[0069] "Ability information" also includes ability parameters other than overall ability. For example, for a pitcher player character, the "ability information" includes parameters indicating the level of the pitcher's individual ability (pitch speed parameter, control parameter, stamina parameter, etc.) and parameters indicating whether or not the pitcher has special abilities. For a fielder player character, the "ability information" includes parameters indicating the level of the fielder's individual ability (defensive ability parameter, trajectory parameter, hitting parameter, power parameter, running ability parameter, etc.) and parameters indicating whether or not the fielder has special abilities. The overall ability can be, for example, the sum (or average, etc.) of the ability values ​​of multiple individual abilities set for the player character.

[0070] Although omitted from FIG. 9 , the character information table TBL2 also includes fields other than those described above. For example, the character information table TBL2 also includes parameters such as the player character's "rank," "cost," "level," and "rarity." The character information table TBL2 also includes parameters such as the player character's dominant arm and pitching form (batting or pitching form), the multiple pitches a pitcher can throw, pitch-type-related parameters (parameters evaluating the pitch's power, trajectory, etc.), information on the batter's strengths and weaknesses in relation to the pitch's trajectory, and information on the player's compatibility with the pitcher. The character information table TBL2 also includes images and video data (two-dimensional or three-dimensional) of the player character. The character information table TBL2 may also include information indicating the type of character. For example, the character information table TBL2 may include information such as flags for identifying player characters corresponding to actual active players, player characters corresponding to actual retired players, original player characters created by the user, and other characters. The various parameters included in the character information table TBL2 described above are set for each character (each character ID) according to the character.

[0071] In the Random Player Cup match game, 29 player characters available to each user who will be competing against each other are randomly selected from all player characters (examples of players) available for use in the Random Player Cup match based on the same selection conditions related to the player character parameters (position information, ability information, etc.). The 29 player characters selected are, for example, four pitchers (starters), three pitchers (relief pitchers), two pitchers (setup pitchers), two pitchers (closers), two catchers, two first basemen, two second basemen, two third basemen, two shortstops, two center fielders, two right fielders, two left fielders, and two position random players. Here, the two position random players can be selected randomly from any position.

[0072] 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, the individual player characters to be selected for each position are classified as Candidate 1 to Candidate 4 and a position random slot. In the examples of FIGS. 11 and 12, selection conditions are set for each player character to be selected. The selection conditions include conditions related to parameters of position information (an example of role information) and ability information. In the examples of FIGS. 11 and 12, the multiple conditions set for each player character to be selected are AND conditions.

[0073] As shown in FIG. 11, for pitcher (starting pitcher), four candidates, Candidate 1 to Candidate 4, are always selected, and if one player from the position random slot is included, a maximum of five player characters may be selected. For example, the selection conditions for pitcher (starting pitcher) Candidate 1 are "main position pitcher," "starting pitcher aptitude ◎," and "overall ability value of 300 or more." Furthermore, the selection conditions for pitcher (starting pitcher) Candidates 2 and 3 are "main position pitcher," "starting pitcher aptitude ◎," and "overall ability value of 200 to 299," respectively. In this manner, the same selection conditions may be set for two or more selection candidates. Furthermore, for example, the selection conditions for pitcher (starting pitcher) Candidate 4 are "main position pitcher," "starting pitcher aptitude ○ or higher," and "overall ability value of 199 or less." Here, "aptitude ○ or higher" refers to "aptitude ○" or "aptitude ◎" (the same applies below). Also, for example, the selection conditions for the pitcher (starting pitcher) position random slot are "main position pitcher" and "starting pitcher suitability of ○ or more" and "total ability value of 150 to 350".

[0074] For pitcher (relief), three players, Candidate 1 to Candidate 3, are always selected, and including one player in the position random slot, a maximum of four player characters may be selected. For example, the selection conditions for pitcher (relief) candidate 1 are "main position pitcher," "best relay aptitude," and "overall ability value of 300 or more." For example, the selection conditions for pitcher (relief) candidate 2 are "main position pitcher," "best relay aptitude," and "overall ability value of 200 to 299." For example, the selection conditions for pitcher (relief) candidate 3 are "main position pitcher," "best relay aptitude of ○ or more," and "overall ability value of 199 or less." For example, the selection conditions for pitcher (relief) in the position random slot are "main position pitcher," "best relay aptitude of ○ or more," and "overall ability value of 150 to 350."

[0075] For pitchers (setup men), two players, Candidate 1 and Candidate 2, are always selected, and including one player in the position random slot, a maximum of three player characters may be selected. For example, the selection criteria for pitcher (setup man) Candidate 1 are "main position pitcher," "bounce aptitude ◎," "closer aptitude ○ or higher," and "overall ability value 300 or higher." For pitchers (setup men), the selection criteria take into account both bounce aptitude and closeout aptitude. For example, the selection criteria for pitcher (setup man) Candidate 2 are "main position pitcher," "bounce aptitude ◎," "closer aptitude ○ or higher," and "overall ability value 200 to 299." Furthermore, for example, the selection criteria for pitcher (setup man) in the position random slot are "main position pitcher," "bounce aptitude ◎," "closer aptitude ○ or higher," and "overall ability value 150 to 350."

[0076] For pitchers (closers), two players, Candidate 1 and Candidate 2, are always selected, and if one player from the position random slot is included, a maximum of three player characters can be selected. Although we will not go into detail here, just like pitchers (starters), etc., selection conditions are set for pitcher (closer) Candidate 1, Candidate 2, and the position random slot.

[0077] As shown in FIG. 12, for fielder characters, two players, Candidate 1 and Candidate 2, are always selected for every position, and if one player from the position random slot is included, a maximum of three player characters may be selected. For example, the selection conditions for catcher candidate 1 are "main position: catcher" and "total ability value: 300 or more." Similarly, for other positions of fielder characters, the selection conditions for candidate 1 are, for example, "main position is target position" and "total ability value: 300 or more." Furthermore, for example, the selection conditions for catcher candidate 2 are, for example, "main position: catcher" and "total ability value: 200 to 299." Similarly, for other positions of fielder characters, the selection conditions for candidate 2 are, for example, "main position is target position" and "total ability value: 200 to 299." Furthermore, for example, the selection conditions for the catcher position random slot are, for example, "main position: catcher" and "total ability value: 150 to 350." Similarly, for other positions of fielder characters, for example, the selection conditions for the position random frame are "main position is the target position" and "total ability value is 150 to 350".

[0078] In this embodiment, the same player character is not selected more than once among the 29 player characters assigned to a user. As a variation, the same player character may be selected more than once among a predetermined number of player characters assigned to a user.

[0079] For example, candidates for each position other than the random position slots can basically be randomly selected in order starting from candidate 1, but any candidate for any position can be randomly selected. Alternatively, multiple candidates or multiple positions can be randomly selected almost simultaneously by parallel processing.

[0080] To prevent the same player character from being selected more than once, players who have already been selected must be excluded from the random selection. For example, when the same selection conditions are set, such as for pitcher (starting pitcher) candidates 2 and 3 shown in FIG. 11, two player characters are randomly selected from the population that meets the selection conditions, so that there is no overlap. For example, player character candidate 2 is randomly selected first, and then player character candidate 3 is randomly selected, excluding the selected player character. Note that the order of selection between candidate 2 and candidate 3, which have the same selection conditions, does not matter.

[0081] Regarding the selection of the two player characters for the position random slots, for example, first, to determine which positions to select, two positions are randomly determined from all positions (here, 12 positions: four pitchers and eight fielders). The two randomly determined positions may be allowed to overlap, or may not overlap. Then, a player character for that position is randomly selected based on the selection conditions set in the position random slot for that determined position. To prevent the same player character from being selected more than once among the 29 player characters assigned to the user, for example, first, random selection of 27 player characters other than the position random slots is performed, and then random selection of two player characters for the position random slots is performed, excluding the player characters already selected. Alternatively, for example, random selection of two player characters for the position random slots may be performed first, and then random selection of the 27 player characters other than the position random slots is performed. As a variation, no selection conditions may be set for the position random slots. Here, the fact that no selection conditions are set means that, for example, random selection is performed from all player characters available for use in matches in the Random Player Cup. In other words, selection conditions are set for the random selection of a specific number of player characters (e.g., 27) within a team, but the random selection of the remaining player characters (e.g., 2) may be performed at random without setting selection conditions.

[0082] In this embodiment, 29 player characters are assigned to each of the two competing users, resulting in a total of 58 player characters being selected, but the same player character is not selected more than once among the 58 player characters. In other words, a player character that is the same as a player character assigned to one of the two competing users is not selected by the other user. As a variation, a player character that is the same as a player character assigned to one of the two competing users may also be selected by the other user.

[0083] To prevent a player character assigned to one of two competing users from being selected for the other, for example, random selection of a player character can be performed for one user, and the selected player character can be excluded from selection and random selection of a player character can be performed for the other user. For example, when assigning a player character of "pitcher (starting) candidate 1" to each of two competing users, a player character to be assigned to one user is randomly selected from a population that meets the selection conditions for "pitcher (starting) candidate 1," and then the selected player character is excluded from selection and a player character to be assigned to the other user is randomly selected. In this case, regardless of which of the two competing users is selected first, the probability of selecting any player character included in the population that meets the selection conditions is the same for both users. Therefore, regardless of the order of random selection processing for the two competing users, it can be said that the player characters used by each user in a match are randomly assigned from the "same population" for each user. For example, the order of the random selection process for the two competing players may be determined by a random drawing, or the order of the process may be determined without drawing a lot.

[0084] In tournaments other than the Random Player Cup and the Random Team Cup, users can choose the player characters they want to use, so they tend to use player characters with high ability parameters consecutively. Therefore, in tournaments other than the Random Player Cup and the Random Team Cup, restrictions such as starting rotation restrictions (player characters used in the starting lineup cannot be used consecutively in the next match) are imposed to prevent the consecutive use of player characters with high ability parameters. In contrast, in the Random Player Cup and the Random Team Cup, player characters and teams available to users are randomly assigned, so there are no restrictions on starting rotation.

[0085] However, there may be cases where there are insufficient player characters to be selected under the selection conditions because there are no player characters that satisfy the preset selection conditions, or because the number of player characters that satisfy the selection conditions is less than the number that should be selected. In this case, it is preferable to change the preset selection conditions to cover only the number of player characters that are insufficient.

[0086] One method for changing the selection conditions is, for example, to expand the range of ability parameters. In this case, the range of ability parameters may be expanded toward lower abilities, toward higher abilities, or in both directions. Another method for changing the selection conditions is, for example, to shift the range of ability parameters. In this case, the range of ability parameters may be shifted toward lower abilities, or toward higher abilities. Another method for changing the selection conditions is, for example, to change the conditions to those that use individual ability parameters instead of overall abilities. Another method for changing the selection conditions is, for example, to change the position conditions. Another method for changing the selection conditions is, for example, to change the type of parameters used in the conditions. For example, instead of selection conditions related to position parameters and ability parameters, other types of parameters (e.g., player character rank, level, cost, rarity, etc.) may be applied. These are just examples, and if there are not enough player characters to be selected under the preset selection conditions, the selection conditions may be changed in any way. Furthermore, for example, if there are not enough player characters to be selected even under the changed selection conditions, the selection conditions may be changed repeatedly until the shortage is resolved.

[0087] The selection conditions shown in Figures 11 and 12 are merely examples and are not limited to these. For example, in the above example, two position random slots are provided, but this may be one or three or more, or the position random slot may be eliminated. Also, for example, in the above example, the ability parameter conditions for candidate 1 are 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 slot. Also, in the above example, the value of the player character's overall ability is used as the ability parameter condition, but other ability parameters, such as individual ability parameters or the presence or absence of special abilities, may also be used.

[0088] Furthermore, selection conditions may be, for example, conditions for parameters other than ability parameters and position parameters. Alternatively, selection conditions may be set that combine various types of parameters. Furthermore, in the above example, when the selection conditions include multiple 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 conditions or OR conditions.

[0089] FIG. 13 is an explanatory diagram showing another example of selection conditions for player characters randomly assigned to each user. In FIG. 13, in order to simplify the setting of selection conditions compared to FIG. 11, pitchers are not classified into detailed positions such as starter, reliever, setup man, and closer. FIG. 13 shows an example of setting selection conditions for selecting a predetermined number (e.g., 12) of player characters for the collective position of pitcher. For example, for pitcher candidates 1 and 2, the selection conditions are set as "main position pitcher" and "overall ability 350 or higher." For example, for pitcher candidates 3 to 6, the selection conditions are set as "main position pitcher" and "overall ability value 300 to 349." For example, for pitcher candidates 7 to 9, the selection conditions are set as "main position pitcher" and "overall ability value 200 to 299." For example, for pitcher candidates 10 to 12, the selection conditions are set as "main position pitcher" and "overall ability value 199 or less."

[0090] FIG. 13 also shows an example in which selection conditions are set for selecting a predetermined number (e.g., nine) of player characters for the group of infielder positions excluding catcher. For example, for infielder candidate 1 and candidate 2, the selection conditions are set as "main position infielder" and "total ability value of 350 or more." 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 infielder candidates 3 to 6 and candidates 7 to 9, selection conditions including the condition for "main position infielder" are set. Note that in the example of FIG. 13, selection conditions are set separately for catcher and infielders other than catcher, but selection conditions may also be set by including catcher in the infielder category.

[0091] FIG. 13 also shows an example of setting selection conditions for selecting a predetermined number (e.g., six) of player characters for the group position of outfielder. For example, for outfielder candidates 1 and 2, the selection conditions are set as "main position outfielder" and "total ability value of 350 or more." 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 outfielder candidates 3 to 6, selection conditions including the condition "main position outfielder" are set.

[0092] FIG. 14 is an explanatory diagram showing another example of the selection conditions for player characters randomly assigned to each user. FIG. 14 shows an example in which the selection conditions are set using only ability parameters, without using position parameters. In FIG. 14, for example, for candidates 1 to 5, the selection condition is set to "an overall ability value of 350 or more." Furthermore, for example, for candidates 6 to 10, the selection condition is set to "an overall ability value of 300 to 349." Furthermore, for example, for candidates 11 to 20, the selection condition is set to "an overall ability value of 200 to 299." Furthermore, for example, for candidates 21 to 29, the selection condition is set to "an overall ability value of 199 or less."

[0093] FIG. 15 is an explanatory diagram showing another example of the selection conditions for player characters assigned to each user. FIG. 15 shows an example in which the selection conditions are set using only parameters related to position, without using parameters related to ability. For example, the selection conditions of "main position pitcher" and "starting pitcher suitability ◎" are set for pitcher (starting pitcher) candidates 1 and 2. For example, the selection conditions of "main position pitcher" and "starting pitcher suitability ○" are set for pitcher (starting pitcher) candidates 3 and 4. For example, the selection conditions of "main position pitcher" and "relief pitcher suitability ○ or better" are set for pitcher (relief pitcher) candidates 1 to 3. Similarly, selection conditions using position-related parameters are set for other positions.

[0094] Alternatively, the selection conditions for the player characters randomly assigned to each user may be, for example, “all player characters that can be used in matches in the Player Random Cup.” Here, the explanation will be continued assuming that the selection conditions exemplified in Figures 11 and 12 are applied.

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

[0096] FIG. 16 shows an example of a user team table TBL12 in a competitive game of the Random Player Cup. The user team table TBL12 in 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 a "tournament ID" and a "match ID" for the Random Player 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 a player character randomly assigned to a user. The "team ID" field indicates the team ID associated with the character ID of a player character. In the Random Player Cup, various team IDs (i.e., the teams to which each player character belongs) are associated. The user team table TBL12 also includes fields for setting information on the player order, which will be described later. The "serial number" field may be omitted.

[0097] The two competing users each check the player characters assigned to them on the screen. Then, each user orders a team consisting of 29 player characters within a predetermined time limit (for example, within 300 seconds). With regard to this ordering, in the Random Player Cup (and the Random Team Cup described below), unlike other tournaments (tournaments in which users can select teams and player characters as they like), users do not know which player characters will be assigned to them. Therefore, users must check the player characters after being assigned player characters that can be used in the fighting game. Therefore, in matches in the Random Player Cup (and the Random Team Cup described below), a longer time limit for ordering is set than the time limit (for example, 180 seconds) set for matches in other tournaments or free matches.

[0098] The team lineup made by each user includes pitcher lineup and fielder lineup. In pitcher lineup, the user determines the roles of starting pitcher, relief pitcher, setup man, and closer from among the pitcher player characters assigned to the user. In fielder lineup, the user selects eight player characters to be starting members from among the player characters assigned to the user, and determines their respective positions and batting order. Player characters not selected as starting members become reserve players on the bench and can be used as player substitutions during the game.

[0099] In the Random Player Cup, the multiple player characters assigned to a user are selected randomly, and therefore the names of the baseball teams associated with each player character are varied. Typically, player characters wear uniforms corresponding to the names of the baseball teams associated with them, which can result in the uniforms of the multiple player characters constituting the user's team not being uniform. Therefore, the user may be allowed to select a uniform uniform to be worn by the multiple player characters constituting the user's team from among multiple options. For example, the user may be allowed to select a uniform from one of the 12 Japanese professional baseball teams. The uniform selection process may be performed at any time before the start of the game. The uniform selection process may be omitted. Alternatively, a uniform corresponding to a favorite team (e.g., one of the 12 Japanese professional baseball teams) previously set by the user on the profile setting screen may be automatically selected.

[0100] In addition, when setting the team that the user will use 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 (one of the 12 professional baseball teams) may be applied.

[0101] A match in the Random Player Cup is a real-time action communication battle. Two competing users control randomly assigned player characters on each team. Game videos of this battle are distributed, for example, from a server 30 with a video distribution function or a video distribution server.

[0102] Nowadays, with the spread of e-sports, watching game matches is becoming one way to enjoy games, not just playing them. Many spectators simply want to watch gamers compete against each other in skill, and are not particularly interested in games where, for example, paying to acquire stronger player characters or teams significantly influences the outcome of the match. In other words, from the perspective of entertaining game spectators, it is important to ensure fair gameplay conditions for each competing user. In this regard, in the Random Player Cup competitive game, the same selection conditions are applied to both competing users, and the player characters each user can use in the match are randomly assigned from the "same population," ensuring fair gameplay conditions.

[0103] During the specified tournament period of the Random Player Cup (for example, three days), each user can participate in multiple competitive games. Each user may be allowed to participate in as many matches as they like during the tournament period, or the number of matches played during the tournament period may be fixed. For example, a league match (a round-robin tournament with a specified number of matches), a tournament match, or a combination of these may be adopted. The same applies to the Random Team Cup, which will be described next.

[0104] Next, a description will be given of a "Team Random Cup" battle game in which the team (plurality of player characters constituting the team) used by the user in the battle is randomly assigned.

[0105] When "Team Random Cup" is selected on the tournament selection screen G200 of FIG. 6, a summary of the tournament is displayed, such as "This tournament is a tournament in which matches are played using teams selected at random for each match." Also, a message is displayed to confirm whether the player wishes to participate in the tournament, such as "Do you want to participate in the tournament?" Note that the summary of the tournament or the confirmation of participation may be omitted.

[0106] When a user performs an operation to participate in the Team Random Cup, a menu screen for the Team Random Cup is displayed. The menu screen for the Team Random Cup is similar to the menu screen G400 for the Player Random Cup in FIG. 8, and therefore a description thereof will be omitted. When an operation to select "Start Match" is performed on the Team Random Cup menu screen, participation in the competitive game is accepted, and the screen transitions to a standby screen (not shown), where a matching process is performed to determine an opponent. For example, a 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.

[0107] If the match is successful, the teams available to each user (an example of a group consisting of two or more objects used by users during a competitive game) that will be used against each other are randomly selected based on the same selection conditions from among all teams (an example of objects to be used) that can be used in the Team Random Cup matches.

[0108] In the baseball game of this embodiment, all of the teams that can be used 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 professional baseball teams in Japan.

[0109] Furthermore, the "Playing Player Registration" field indicates a predetermined number (for example, 29) of player characters who have been registered as playing players. Here, "playing player registration" refers to the registration of players so that they can participate in a sports competition. In Major League Baseball, this is also called roster registration. In the baseball game of this embodiment, player characters registered in the "Playing Player Registration" field become members of teams that can be used in competitive games in the Team Random Cup. In this embodiment, 29 character IDs are registered in the "Playing Player Registration" field. The 29 player characters registered in the "Playing Player Registration" field are player characters that correspond to the 29 real players who have been registered as playing players for each of Japan's professional baseball teams.

[0110] That is, in the game of this embodiment, teams (baseball clubs) existing in the real world correspond to teams in the game, and the 29 players registered as players on the real teams correspond to the 29 player characters registered as players on the teams in the game. For example, if a player registered as a player on a real team is changed, the game operator changes the player character IDs registered in the "Registered Players" field of team information table TBL3 to reflect the change. Note that, if the registered players are unknown because of the off-season for real-world professional baseball, the game operator may refer to the registered players from the previous season, for example, and register the character IDs of the default 29 player characters in the "Registered Players" field of team information table TBL3.

[0111] The selection condition in the Team Random Cup is, for example, "all teams that can be used in the Team Random Cup matches." In this case, one team is randomly selected and assigned to each user who will be competing against the other users from among the 12 teams that can be used in the Team Random Cup matches. Each user plays the Team Random Cup match game using the team randomly assigned to them for each match, that is, using the 29 player characters registered as players on that team.

[0112] In this embodiment, teams are selected randomly so that the teams assigned to two competing users do not overlap. As a variation, the same team may be selected for two competing users more than once.

[0113] FIG. 17 shows an example of a user team table TBL12 for a competitive game in the Team Random Cup. The user team table TBL12 in FIG. 17 shows information on player characters for one team assigned to a user with a user ID of "U1." The user ID is associated with a "tournament ID" and a "match ID" for the Team Random Cup. The "team ID" field is set with the team ID of the team randomly assigned to the user, and the "character ID" field is set with the character IDs of the 29 player characters registered as participating players on the assigned team.

[0114] In the above example, a predetermined number of player characters constituting a team are registered and managed in the "Playing Player Registration" field of the team information table TBL3 in Fig. 10, but this is not limiting. For example, in the character information table TBL2 in Fig. 9, information (e.g., a flag) indicating the player characters registered as playing players in the team may be set in association with the character ID.

[0115] As described above, real teams (baseball clubs) correspond to in-game teams, and the 29 players registered as players on the real teams correspond to the 29 player characters registered as players on the in-game teams. Parameters such as abilities associated with the player characters are set to mimic the real players corresponding to the player characters. That is, the in-game teams corresponding to the real teams reflect their inherent strength, close to the actual abilities of the real teams. Therefore, in the Team Random Cup, which has the above selection conditions, mock matches are held between teams from the 12 real professional baseball teams. In this embodiment, the Team Random Cup matches are not just mock matches; teams assigned to users are randomly selected for each match. Therefore, by tallying up the results of matches held in the Team Random Cup, statistically speaking, teams in the game that correspond to teams that are actually strong in the real world will be ranked highly.

[0116] Generally, users have different operational skills, and users with high operational skills (people who are good at operating) are more likely to win a match even if they are assigned a relatively weak team. For example, if every user could select their own team to play against, it is possible that teams with many users with high operational skills would be ranked higher, rather than teams that are actually strong.

[0117] On the other hand, in the Team Random Cup matches of this embodiment, the teams assigned to users for each match are selected at random, so that each team can be used by users with a variety of operating skills. Therefore, if the results of matches held in the Team Random Cup are tallied, statistically speaking, the teams in the game that correspond to the strong teams in the real world will be ranked highly.

[0118] For example, if a "Team Random Cup" is held before the start of a real-world professional baseball exhibition game or regular season, it is possible to liven up the real-world exhibition game through the game. In other words, not only will users who play the Team Random Cup competitive game be excited, but spectators who watch the game will also be excited if, for example, a video of the competitive game is distributed. Also, if all users are able to view a summary screen (e.g., a win / loss table) of all the match results held in the Team Random Cup, they will be able to enjoy predicting the results of the professional baseball exhibition game or regular season that will be held in the real world afterwards based on the summary of all the match results.

[0119] FIG. 18 shows an example of a tally screen G500 of the results of all matches held in the Team Random Cup. The tally screen G500 is a table of wins and losses for 12 teams and includes parts P501 to P504. Part P501 is a part that displays information on the rankings of all 12 teams available for use in Team Random Cup matches, the team names, total wins, total losses, total draws, total winning percentage, and game difference. Part P502 is a part for switching to a screen showing the overall rankings of all matches from the first to nth rounds of the Team Random Cup. Part P503 is a part for switching to a screen showing the overall rankings of the currently held Team Random Cup. Part P504 is a part for switching to a screen showing the overall rankings of the Team Random Cup held last week.

[0120] By looking at the win / loss table on the tally screen G500, you can have fun predicting the rankings of real professional baseball teams based on the results of the mock games, such as how Team G looks strong in this year's professional baseball exhibition games and regular season.Of course, if the Team Random Cup is held continuously (for example, every Friday to Sunday) even after the real professional baseball regular season begins, you can enjoy predicting the future rankings of professional baseball teams from the win / loss table on the tally screen G500.

[0121] Another example of the selection condition in the Team Random Cup is a condition related to the league to which a team belongs. The 12 teams that can be used in the Team Random Cup matches are divided into two leagues, corresponding to the division of the 12 professional baseball teams in Japan into two leagues. 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. Note that instead of determining the league by the team ID, for example, information that identifies the league (e.g., a flag) may be associated with the team ID.

[0122] Examples of the selection conditions in the Team Random Cup are "first league" or "second league." For example, if the selection condition is "first league," each user who will be competing against the other will be assigned one team randomly selected from six teams that meet the conditions of "first league" out of the twelve teams available for use in the Team Random Cup matches. The user will play the Team Random Cup competitive game using the randomly assigned team, i.e., using the 29 player characters registered as players on that team. In the Team Random Cup with this selection condition, a mock battle will be played between real teams from the same league.

[0123] Another example of the selection condition in the Team Random Cup is a condition related to a specific number of teams. For example, the selection condition is two teams corresponding to two real teams competing in the Japan Series of professional baseball. In this case, each user who will be playing against the other is randomly assigned one of two teams corresponding to the two real teams competing in the Japan Series. The user plays the Team Random Cup competitive game using the randomly assigned team, i.e., using the 29 player characters registered as players on that team. In the Team Random Cup with this selection condition, a mock battle is played between real teams competing in the Japan Series.

[0124] For example, if a tournament titled "Team Random Cup (Japan Series)" is held after the actual baseball teams that will compete in the real world have been decided and before the Japan Series games are played, it would be possible to create excitement for the real-world Japan Series through the game. In other words, not only users who play the Team Random Cup competitive game, but also spectators who watch the games, for example, if videos of the competitive games are streamed, would be excited. Furthermore, a summary of all the matches played in the Team Random Cup (e.g., a win / loss table) could be viewed by any user, allowing them to enjoy predicting the outcome of the Japan Series that will be played in the real world from the summary of all the match results. For example, suppose that Team G and Team H are the two teams corresponding to the two actual teams competing in the Japan Series. Then, for example, if there are 1,000 matches in the Team Random Cup, and the summary results (either mid-tournament summary or final summary) show that Team G has 350 wins, Team H has 600 wins, and there are 50 draws, users could enjoy predicting the outcome of the Japan Series based on the summary of the mock games, such as Team H appearing to be in the lead in this year's Japan Series.

[0125] Although the example in which the tournament entitled "Team Random Cup (Japan Series)" is held before the Japan Series in the real world has been shown, the present invention is not limited to this. For example, the tournament entitled "Team Random Cup (Japan Series)" may be held during or after the Japan Series in the real world.

[0126] The user checks on the screen the player characters that make up the team assigned to them. Then, as in the Random Player Cup, the user orders the team within a predetermined time limit (for example, within 300 seconds). A match in the Random Player Cup is a real-time action communication battle. The two competing users each control player characters from the team that has been randomly assigned to them. Game video of this battle is distributed, for example, from a server 30 with a video distribution function or a video distribution server.

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

[0128] In the above, an example was shown in which the Random Player Cup or Random Team Cup competitive game is held within a specified period of time, but it is also possible to have the Random Player Cup or Random Team Cup competitive game be held at any time without limiting the period.

[0129] [3. Functional configuration of game terminal] 19 is a schematic functional block diagram showing an example of the functional configuration of the 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.

[0130] The terminal control unit 110 has a function of executing various calculations and data processing based on information related to operations performed via the operation unit 16, information received from the server 30 or other game terminals 10, etc. The terminal control unit 110 also has a storage control function of storing information resulting from the executed processing in a predetermined area of ​​the storage device (RAM 13, auxiliary storage device 14, etc.). The terminal control unit 110 also has an output control function of controlling various outputs via the image processing unit 17 and 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.), and controls the sound processing unit 18 to output sound effects during game play from the audio output unit 21. The terminal control unit 110 also has a communication control function of managing information communication with the server 30, other game terminals 10, etc. via the communication unit 15.

[0131] The terminal control unit 110 also has a user information management function that stores and manages information related to the user's game in a storage device (RAM 13, auxiliary storage device 14, etc.). For example, the terminal control unit 110 stores information such as the user's name, profile, etc. in the storage device, in association with the user ID. The items managed by the terminal control unit 110 vary depending on the type and content of the game. The terminal control unit 110 stores and manages various information such as the matching rate MR, various points and items, match results, user IDs of other users (companions, friends, etc.) associated with the user ID in the storage device. Furthermore, the terminal control unit 110 downloads information related to the user's game from the server 30, if any.

[0132] The above-described 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 storage device (such as the ROM 12, RAM 13, or auxiliary storage device 14).

[0133] The data storage unit 100 is realized by at least one of the ROM 12, RAM 13, and auxiliary storage 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, the 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. Note that 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, and therefore their description will be omitted here.

[0134] 20 shows an example of the 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."

[0135] The game level is information that evaluates the level of the user's operation skill in the baseball game. The owned points are points that the user owns and can be used in the game. For example, the owned points may be a virtual currency that the user can use in the baseball game, or may be a payment for playing the baseball game that is consumed when the user plays the baseball game.

[0136] 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, etc. The "Owned Character Information" field stores the character IDs of player characters acquired by the user in the game. The "Match Result Information" field stores information on the results of matches in various tournaments in online tournament mode (e.g., win / loss, points scored / conceded, etc.).

[0137] The "Owned Character Information" field stores the character ID of a character that the user has acquired in the game and currently owns. There are several ways to acquire a character. For example, the user can acquire a character by lottery by executing a lottery mode. In this lottery mode, a character to be assigned to the user is selected by lottery from all characters in the game. In order for the user to execute the lottery mode, for example, a predetermined amount of in-game points, paid items, etc. may be required. For example, the user can receive a character as a gift from another user (such as another user associated with the user). For example, the user can acquire a character as a reward for playing in the game. For example, the user can also acquire an original player character that has been trained in a training mode. For example, at the start of the game, a predetermined number of characters may be assigned as the user's owned characters.

[0138] The characters stored in the "Owned Character Information" field can be selected and used by the user in competitive games other than the Player Random Cup and Team Random Cup, and in other game modes, but cannot be selected and used by the user in the aforementioned Player Random Cup and Team Random Cup.

[0139] [4. Functional configuration of the server] 21 is a schematic functional block diagram showing an example of the functional configuration of the 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, and an auxiliary storage device 34. The data storage unit 300 stores data necessary for providing a game.

[0140] As a specific example of data stored in the data storage unit 300, the data necessary 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.

[0141] 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 described, so detailed description will be omitted here. Each user's game terminal 10 also holds substantially the same data as the character information table TBL2 and team information table TBL3. For example, if 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 distributed from the server 30 to the game terminal 10 via the network N.

[0142] FIG. 22 shows an example of the user management table TBL4. The user management table TBL4 is a data table for managing all users who play games on the game system 1. The user management table TBL4 includes fields such as "user ID," "user name," "matching rate," and "tournament points." Although omitted from FIG. 22, other fields are also included in the user management table TBL4. For example, the user management table TBL4 includes fields such as the user's game level, owned points, and the user IDs of other users (comrades, friends, etc.) associated with the user.

[0143] FIG. 23 shows an example of the 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 stored for each tournament (each tournament ID). The example in FIG. 23 shows an example of the match management table TBL5 that manages all match games played in tournament ID: E1 (1st Player Random Cup). The match management table TBL5 includes fields such as "match ID," "first user ID," "second user ID," and "match result."

[0144] The "match ID" is identification information for uniquely identifying a match game played in a tournament with a tournament ID associated with the match management table TBL5. A match ID is assigned and stored in the "match ID" field each time a match game is played during the period of the tournament. In addition, the user ID of one of the two users matched in the 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 about the result of the match game (e.g., win / loss, score / loss, etc.). Although omitted in FIG. 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 of each competing user (in the case of the baseball game mentioned above, one of the 12 teams).

[0145] The game system 1 or the server 30 of this embodiment provides a game in which users can participate in a specific competitive game.

[0146] Here, a "user" is, for example, a person who plays a game provided by the game system 1. For example, user identification information is associated with each user, and each user is identified (specified) by the user identification information. "User identification information" is information for uniquely identifying each user. For example, a user ID, a unique user name, or an email address is an example of "user identification information."

[0147] Furthermore, a "competitive game" is, for example, a computer game in which a user competes against an opponent to determine superiority or victory or defeat. For example, an online competitive game played between terminals 10 of multiple users connected via a network N is an example of a "competitive game." Here, a "competition" means determining superiority or victory or defeat with an opponent. The result of a competitive game does not necessarily have to be a victory or defeat, and a draw is also acceptable. A match in a sports game, a battle in a combat game, etc. are examples of a "competition."

[0148] A user's opponent may be one user or two or more users. For example, the aforementioned baseball game in which two users each play a game using multiple player characters from their own baseball team is an example of a "battle game." Also, for example, a game in which three or more users fight each other using their own characters in the same game space is an example of a "battle game."

[0149] The "battle game" may be, for example, a battle game in which the user and the opponent each manually operate their own objects. The "battle game" may also be, for example, a battle game in which a computer executes a simulation process based on the user's objects and the opponent's objects to automatically determine the progress of the battle, and the user and the opponent only operate their own objects in specific scenes. The "battle game" may also be, for example, a battle game in which a computer executes a simulation process based on the user's objects and the opponent's objects to automatically determine the outcome of the battle.

[0150] The "competitive game" may be, for example, a specific competitive game that is played within a predetermined period of time. Here, the "predetermined period" refers to a predetermined fixed period of time, such as a period during which a competitive game in which users can participate is played. Here, the "period" may be, for example, a period in days of the week, such as Friday to Sunday, a period in days, such as March 1st to March 5th, or a period in hours, such as 7:00:00 AM to 9:00:00 PM the next day. Alternatively, the "period" may be, for example, a period in weeks, months, or years.

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

[0152] A competitive game that is different from the "specific competitive game" may be referred to as a "second competitive game." In other words, a "second competitive game" refers to a competitive game in which the user can select the objects, etc. that can be used in the match. In the example of the baseball game mentioned above, a competitive game in a tournament other than the "Random Player Cup" and "Random Team Cup" held in online tournament mode, or a competitive game in free match mode, is an example of a "second competitive game."

[0153] A "specific competitive game held within a specified period" is, for example, one or more specific competitive games held within a period predetermined by the game management side. For example, a specific competitive game held during a game tournament held for a limited period by the game management side is an example of a "specific competitive game held within a specified period." Here, a "game tournament" is, for example, a game-related event in which users participating in the tournament compete against each other for superiority, wins and losses, ranking, etc. In the baseball game example mentioned above, a "Random Player Cup" or a "Random Team Cup" is an example of a "game tournament."

[0154] Furthermore, for example, a "specific competitive game to be held within a predetermined period of time" may be one in which a user is given rewards such as points or items that can be used in the game depending on wins and losses or rankings, or may be one in which a title such as a rank is given. Furthermore, for example, a "specific competitive game to be held within a predetermined period of time" may be held as a tournament known as an e-sports, or may be one in which no prize money or prizes are offered. In the baseball game example mentioned above, one or more competitive games held in a Random Player Cup or Random Team Cup, where the tournament period is set in advance, are examples of "specific competitive games to be held within a predetermined period of time."

[0155] A "specific competitive game" does not have to be a competitive game that is played during a predetermined period. For example, a "specific competitive game" may be a competitive game that can be played by each user at any time. In the example of the baseball game mentioned above, if a competitive game for the Random Player Cup or the Random Team Cup is available at any time without a time limit, the competitive game is an example of a "specific competitive game."

[0156] 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 storage device (such as the ROM 32, RAM 33, or auxiliary storage device 34).

[0157] The reception unit 310 in FIG. 21 has a function of receiving a request to participate in the competitive game.

[0158] Here, "accepting participation in a competitive game" refers to accepting a user's operation (participation application operation) to participate in the competitive game. Alternatively, "accepting participation in a competitive game" may refer to receiving information indicating a user's intention to participate in the competitive game. For example, when a user performs a button operation, a screen touch operation, a voice input operation, or the like to participate in the competitive game, receiving information regarding the operation corresponds to an example of "accepting participation in a competitive game." Participation conditions for accepting participation in a competitive game may be set, or may not be set. For example, in the case of a competitive game for which participation conditions are set, participation in the competitive game may not be accepted unless the participation conditions are met. Furthermore, for example, in the case of a competitive game that is held within a predetermined period, participation in the competitive game may not be accepted outside the predetermined period.

[0159] In the example of the baseball game described above, if the user performs an operation to select "Start Game" of part P403 on the menu screen G400 of the Random Player Cup (or Random Team Cup) in FIG. 8, the reception unit 310 will accept participation in a "Random Player Cup (or Random Team Cup) competitive game" as an example of a specific competitive game, based on information related to the operation. Note that, for example, when a process of matching users to be opponents is executed in a competitive game, the reception unit 310 may be configured to accept participation in the competitive game when the matching is successful and the opponent is determined. In other words, the period from the user's participation application operation to successful matching may be a participation acceptance waiting period, and when the matching is successful and the opponent is determined, participation in the competitive game based on the participation application operation may be accepted.

[0160] The reception unit 310 may have a function to accept participation not only in a "specific fighting game in which the user cannot select what objects, etc., that can be used in a battle will be used on" but also in a "second fighting game in which the user can select what objects, etc., that can be used in a battle will be used on." In other words, it is sufficient for the reception unit 310 to have at least a function to accept participation in the specific fighting game.

[0161] The management unit 320 in FIG. 21 has a function of storing and managing, in a storage device, a plurality of use objects that can be used in the specific competitive game by a user whose participation has been accepted by the acceptance unit 310.

[0162] Here, the "usable object" refers to an object that can be used by a user in a fighting game. The usable object can be an object that can be used by the user during the fighting game.

[0163] Here, an "object" is something that can be used in a game. For example, a game character, a game card, or a game item is an example of an "object." For example, a game character or a game card representing a person such as an athlete, a living thing such as a racehorse, a fictional character or living thing such as a monster, or an inanimate object such as a robot is an example of an "object." For example, an "object" may be a game character or a game card that corresponds to a real person, or it may not correspond to a real person.

[0164] For example, in the case of a game in which a user uses one or more game characters to compete against an opponent, the one or more game characters are an example of an "object to be used." Also, in the case of a card game in which a user organizes a deck of multiple game cards and uses the organized deck to compete against an opponent, the multiple game cards incorporated into the deck are an example of an "object to be used." In the baseball game example mentioned above, a pitcher or fielder player character that can be used in the Random Player Cup competition is an example of an "object to be used."

[0165] The use object may be a group of two or more objects that can be used by the user during the fighting game.

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

[0167] For example, in the case of a game in which a user uses a group (team, group, squad, party, guild, etc.) consisting of multiple game characters to compete against an opponent, the group (and the multiple game characters included in the group) corresponds to an example of a "target of use." In the baseball game example mentioned above, a team consisting of 29 player characters that can be used in the Team Random Cup competitive game, which is managed in team information table TBL3 of FIG. 10, corresponds to an example of a "target of use."

[0168] The "plurality of use objects usable in the competitive game by users whose participation has been accepted by the accepting unit 310" managed by the management unit 320 include at least a plurality of use objects that can be used in common by all users whose participation has been accepted in a specific competitive game. As will be described later, in order for a use object to be actually usable by a user in a competitive game, it is necessary for the use object to be associated with user identification information (e.g., a user ID). In other words, the "plurality of use objects usable in the competitive game by users whose participation has been accepted by the accepting unit 310" managed by the management unit 320 are a plurality of use objects that become usable by the user in the competitive game when associated with the user identification information of the user.

[0169] The "plurality of usable objects that the user can use in the fighting game" managed by the management unit 320 may be, for example, objects or groups that can be used not only in a specific fighting game but also in fighting games other than the specific fighting game and in other game modes. In other words, the "plurality of usable objects that the user can use in a specific fighting game" managed by the management unit 320 may be, for example, managed specially for the specific fighting game (in the baseball game example described above, managed as player characters specially prepared for the tournament), or may be managed as objects that can be used in fighting games other than the specific fighting game and in other game modes.

[0170] Furthermore, the "plurality of objects usable by the user in the competitive game" managed by the management unit 320 may be all objects or groups handled in the game provided by the game system 1, or may be some of the objects or groups. In other words, it is sufficient that the "plurality of objects usable by the user in a specific competitive game" is included among the objects (objects or groups) usable in the game managed by the management unit 320.

[0171] In the example of the baseball game mentioned above, the management unit 320 manages multiple player characters that users can use in the game (including the Random Player Cup or Random Team Cup competitive games) based on a character information table TBL2 (see Figure 9) stored in a storage device (database DB, ROM 32, RAM 33, or auxiliary storage device 34, etc.).

[0172] The selection unit 330 in Figure 21 has the function of randomly selecting the usable object that can be used in the competitive game and is associated with the user identification information of each user who will be the opponent, from the multiple usable objects managed by the management unit 320, based on the same selection conditions.

[0173] Here, "a use object associated with user identification information" refers to a use object such as an object that is stored in association with user identification information. Here, "associating a use object with user identification information" means making the associated use object available for use in the battle game by a user identified by the user identification information.

[0174] The "object associated with the user identification information" is, for example, an object or the like that is available to the user in the battle game. The "object associated with the user identification information" can be limited to be available for use in the specific battle game that is played within a predetermined period of time (or that is played without a time limit).

[0175] For example, the "object of use associated with user identification information" may not remain associated and be usable in the next competitive game even after the end of the specific competitive game that takes place within a specified period, but may be released or invalidated from its association with the user identification information after the end of the match (at any time between the end of the match and the next competitive game).

[0176] Furthermore, the "object of use associated with user identification information" may be, for example, "not owned by a user so that it can be used in games other than the specific competitive game played within a specified period (for example, competitive games other than the specific competitive game or other types of games)."

[0177] "Randomly selecting, based on the same selection conditions, from the plurality of use objects managed by the management unit 320" means that a use object associated with the user identification information of each user who will be an opponent is randomly selected, based on the same selection conditions, from "a plurality of use objects that can be used in common by all users who have accepted participation in the competitive game" managed by the management unit 320. Here, "the same selection conditions" means that the same selection conditions are applied to all users who will be opponents.

[0178] "Randomly selecting based on selection conditions" means, for example, randomly selecting one or more of the use objects from a population based on the selection conditions. Here, "randomly selecting" means randomly extracting. For example, applying a known pseudorandom number generation algorithm to randomly sample one or more of the use objects from the population is an example of "randomly selecting." Also, for example, applying the same lottery probability to all of the use objects included in the population and randomly selecting one or more of the use objects from the population based on the probability is an example of "randomly selecting."

[0179] The "selection conditions" are, for example, conditions for randomly selecting the usable object that can be used in the specific fighting game from the plurality of usable objects managed by the management unit 320. In other words, the "selection conditions" are, for example, conditions for determining a population that is the subject of random sampling.

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

[0181] The selection condition may be a condition related to the parameter. Here, "the selection condition is a condition related to the parameter" means that a condition related to the parameter associated with the object is applied as the selection condition. The selection unit 330 randomly selects the object that can be used in the fighting game from among a plurality of objects managed by the management unit 320 that satisfy the condition based on the parameter.

[0182] For example, the parameters include capability information of the object, and the selection conditions can include "conditions related to the capability information of the object."

[0183] Here, "ability information" refers to parameters that indicate the abilities set for an object. "Ability information" may be, for example, information that indicates the level of an object's ability. Furthermore, "ability information" may be, for example, information that indicates whether an object has a specific ability. Furthermore, "ability" may include, for example, the performance of an object.

[0184] For example, in the case of a baseball game, information indicating the batting ability, defensive ability, base running ability, or pitching ability of a player character as an example of an object corresponds to an example of "ability information." Furthermore, in the case of a soccer game, information indicating the offensive ability (shooting ability, passing ability, dribbling ability, etc.) or defensive ability (tackling ability, etc.) of a player character as an example of an object corresponds to an example of "ability information." Furthermore, in the case of a fighting game, information indicating the offensive ability or defensive ability of a character 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 or the like as an example of an object corresponds to an example of "ability information."

[0185] For example, in a baseball game, if all player characters that can be used in the specific competitive game are managed by management unit 320, and one or more player characters with ability values ​​within a predetermined range, for example, an ability value range of 200 to 299, are randomly selected from all of the player characters, the condition that the player character's ability value is within the range of 200 to 299 corresponds to an example of a "selection condition." In this example, all player characters with ability values ​​of 200 to 299 managed by management unit 320 become a set of selection candidates (i.e., a random selection population).

[0186] In the example of the baseball game mentioned above, the conditions for the overall ability value, such as "350 or more," "300 or more," "300 to 349," "200 to 299," "150 to 350," and "199 or less," as shown in Figures 11 to 14, correspond to "conditions related to the object's ability information" as an example of selection conditions.

[0187] Furthermore, for example, the parameters include role information of the object, and the selection conditions can include "conditions related to role information of the object."

[0188] Here, "role information" refers to a parameter that indicates the role assigned to an object. For example, in a sports game such as a baseball game or a soccer game, a position corresponds to an example of a "role." Also, in a fighting game, an occupation corresponds to an example of a "role."

[0189] For example, in the case of a baseball game, the positions of "pitcher" or "fielder" correspond to an example of "role information." Further, for example, subdivisions of the pitcher position, such as "starter," "relief pitcher," "setup man," or "closer," correspond to an example of "role information." Further, for example, subdivisions of the "fielder" position, such as "infielder" or "outfielder," correspond to an example of "role information." Further, for example, further subdivisions of the "fielder" position, such as "catcher," "first baseman," "second baseman," "third baseman," "shortstop," "center fielder," "right fielder," "left fielder," or "designated hitter (DH)," correspond to an example of "role information."

[0190] Furthermore, the position suitability information of an object corresponds to an example of "role information." Here, "position suitability information of an object" is, for example, in the case of a baseball game, information evaluating the suitability of a pitcher for each of the positions of "starter," "relief pitcher," and "closer." For example, in the case of the "starter" position, evaluation information such as "starter suitability ◎," "starter suitability ◯," or "no suitability (or no evaluation)" corresponds to an example of "role information."

[0191] For example, in a baseball game, if one or more player characters whose position is catcher are randomly selected from all player characters available in the competitive game, the condition that the position is catcher is an example of a “selection condition.” In this example, the population from which the random selection is made is all player characters whose position is catcher.

[0192] In the example of the baseball game mentioned above, the conditions for the main positions shown in Figures 11 to 13 and 15, such as "pitcher," "catcher," "first baseman," "starting pitcher suitability ◎," "relay suitability ◎," "closer suitability ◎," "starting pitcher suitability ○ or above," etc., correspond to "conditions related to the object's role information" as an example of selection conditions.

[0193] The selection condition may be a combination of a plurality of selection conditions, for example, a combination of a "condition related to ability information of an object" and a "condition related to role information of an object."

[0194] The selection condition may be, for example, a condition that all of the plurality of use objects managed by the management unit 320 are a set of selection candidates (that is, a random selection population).

[0195] When the competitive game is a game in which groups each made up of two or more objects compete against each other, the user identification information of each user who will be competing against the other is associated with the two or more objects from among a plurality of objects managed by the management unit 320. In this case, it is preferable that the selection unit 330 sets the selection condition for selecting each of the two or more objects for each object to be selected.

[0196] The baseball game described above is a game in which teams each made up of 29 player characters compete against each other, and is an example of a "game in which groups each made up of two or more objects compete against each other." Figures 11 and 12 show a preferred example in which selection conditions are set individually for each of the 29 player characters. By appropriately setting selection conditions such as position and ability for each player character to be selected in this way, it is possible to form a desired group without bias in terms of position, ability, etc.

[0197] In addition, 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 shown in Figures 13 and 14, a common selection condition may be set for multiple candidates to be selected. For example, in Figure 14, a common selection condition of "total ability of 350 or more" is set for five candidates to be selected, Candidate 1 to Candidate 5.

[0198] An example of the character selection condition table TBL6 applied in the aforementioned Random Player Cup battle game is shown in Figure 24. The character selection condition table TBL6 is a data table showing the 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."

[0199] The "Candidate ID" field indicates identification information for uniquely identifying the characters to be selected in the random selection process by the selection unit 330. PS1-4 are four pitchers (starters), PR1-3 are three pitchers (relief pitchers), PSM1-2 are two pitchers (setup pitchers), PC1-2 are two pitchers (closers), C1-2 are two catchers, 1B1-2 are two first basemen, 2B1-2 are two second basemen, 3B1-2 are two third basemen, SS1-2 are shortstops, CF1-2 are two center fielders, RF1-2 are two right fielders, LF1-2 are two left fielders, and PR1-2 are two position randoms. These candidate IDs correspond to the position candidates (1-4) and position random slots 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.

[0200] The "selection conditions" field stores the selection conditions that are applied to the selection target of each candidate ID. For example, the "selection conditions" field stores the selection conditions shown in FIGS. 11 and 12. That is, selection conditions are set individually for each of the 29 selection targets.

[0201] 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 competitive game. The team selection condition table TBL7 is a data table showing selection conditions related to teams, 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 and a user with user ID: U2 compete against each other in a competitive game (competition ID: M15) held in a tournament with tournament ID: E2 (Team Random Cup 1st).

[0202] 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 condition applied in the Team Random Cup competitive game. The "selection condition" field sets the team selection condition. In the example of FIG. 26, four selection conditions are set: "All Teams (TC1-TC6, TP1-TP6)," "First League (TC1-TC6)," "Second League (TP1-TP6)," and "Japan Series (TC1, TP6)." When the selection condition "All Teams" is set, random selection is performed from all 12 teams. In other words, when the selection condition "All Teams" is applied, random selection is essentially performed without setting any selection condition. When the selection condition "First League" is set, random selection is performed from the six teams (TC1-TC6) belonging to the first league. When the selection condition "Second League" is set, random selection is performed from the six teams (TP1-TP6) belonging to the second league. In the case of the selection condition "Japan Series," a random selection is made from teams participating in the real-world professional baseball Japan Series (for example, TC1, TP6 set by the game management).

[0203] Although the above example shows a case where a plurality of team selection conditions are registered in the team selection condition table TBL7, the present invention is not limited to this. Information on the team selection conditions may be stored in a storage device without using the team selection condition table TBL7.

[0204] Next, a case where an object corresponds to a real person will be described. In this case, it is preferable to set parameters associated with the object so as to resemble the real person corresponding to the object.

[0205] Here, a "real person" refers to a person in the real world, such as a famous person in the real world. For example, a real-world athlete, martial artist, or entertainer is an example of a "real person." For example, a person who existed in the past, such as a famous historical figure, may be included in the "real person," or only people who are currently alive may be considered "real people." Furthermore, for example, in the case of athletes, retired athletes may be included in the "real person," or only active athletes may be considered "real people."

[0206] For example, in a baseball game, a player character or a game card corresponding to an actual baseball player is an example of an "object corresponding to an actual person." In this case, for example, the ability parameters of the player character are set based on the performance of the baseball player in an actual game (performance as a fielder (batting average, RBIs, number of home runs, number of strikeouts, number of stolen bases, or number of errors)) or performance as a pitcher (earned run average, number of wins, number of strikeouts, number of walks allowed, or pitch speed, etc.). Also, in a soccer game, for example, a game character or a game card corresponding to an actual soccer player is an example of an "object corresponding to an actual person." In this case, for example, the ability parameters of the game character are set based on the performance of the soccer player in an actual game (number of goals, number of assists, number of shots, pass success rate, number of fouls, etc.).

[0207] For example, in the case of a player character corresponding to a real baseball player, as in the baseball game mentioned above, setting the parameters of the player character's team, defensive position, and abilities (batting, fielding, base running, pitching, etc.) based on the team, position, and performance (batting average, earned run average, etc.) of the real baseball player is an example of "setting parameters associated with an object to resemble the real person corresponding to the object."

[0208] In the aforementioned baseball game, users can simulate real-world matches in the game using player characters modeled after actual baseball players. In particular, in the Team Random Cup competitive game, simulated matches of real-world professional baseball games can be realized in the game. As described above, if a simulated match of a similar matchup is realized in the game before a matchup scheduled in the real world (e.g., a Japan Series match) takes place, excitement for the real-world matchup can be built through the game. Here, in the Team Random Cup competitive game, teams consisting of multiple player characters modeled after actual people used in the simulated matches in the game are randomly assigned to each competing user, so that simulated matches of a variety of matchups can be realized without bias.

[0209] Next, a preferred configuration will be described in which a random selection of a target to be used is performed each time a competitive game is played. Each user can play the competitive game multiple times within a predetermined period, and it is preferred that the selection unit 330 performs random selection based on the same selection conditions each time the competitive game is played within the predetermined period.

[0210] In the baseball game described above, users can play multiple competitive games during the Random Player Cup or Random Team Cup period, and for each competitive game, the player characters or teams associated with the user IDs of the two competing users are randomly selected based on the same selection criteria. The player characters or teams randomly assigned to users in a competitive game are reset for the next competitive game, and new player characters or teams are randomly selected.

[0211] In this way, each time a competitive game is played, a player character or team associated with the user's user ID is randomly selected, so that each user competing in a match is assigned a variety of player characters or teams without bias. In particular, in the Team Random Cup competitive game, which allows for simulated matches between real-world teams to be realized in the game, the team assigned to each user is randomly selected in each match, so that each team will be used by users with a variety of operating skills. Therefore, by tallying up the results of the in-game mock matches, statistically speaking, the teams in the game that correspond to teams that are actually strong in the real world will be ranked higher. Therefore, by tallying up the results of the in-game mock matches, players can enjoy predicting the results of subsequent matches in the real world.

[0212] [5. Processing] Next, an example of processing executed by the game system 1 of this embodiment will be described below.

[0213] Fig. 28 is a sequence chart showing an example of processing in the game system 1. Fig. 28 shows an example of processing when a competitive game (an example of a specific competitive game) of the aforementioned Random Player Cup baseball game is played between game terminal 10-1 of a user with user ID: U1 and game terminal 10-2 of a user with user ID: U2. Hereinafter, the user with user ID: U1 will be referred to as "user U1," and the user with user ID: U2 will be referred to as "user U2."

[0214] When user U1 performs an operation on game terminal 10-1 to participate in the Random Player Cup competitive game, information about the operation is transmitted to server 30 via network N (S100-1). For example, when user U1 performs an operation on game terminal 10-1 to select part P403 "Start Match" on menu screen G400 of the Random Player Cup in FIG. 8, match participation request information as information about the operation is transmitted to server 30. Similarly, when user U2 performs an operation on game terminal 10-2 to participate in the Random Player Cup competitive game, information about the operation is transmitted to server 30 via network N (S100-2).

[0215] The server 30 receives information regarding the match participation operation from the game terminals 10-1 and 10-2 and executes a process of accepting participation in the Random Player Cup match game (S300). For example, if participation conditions are set, the server 30 may be configured to accept participation in the match game only if the participation conditions are met. Furthermore, for example, the server 30 may execute a matching process to determine opponents, and if matching is successful, accept participation in the match game from the two matched users. Here, the description will continue assuming that matching has been performed between user U1 of game terminal 10-1 and user U2 of game terminal 10-2.

[0216] 28, the server 30 may return response information indicating that the participation has been accepted to the game terminals 10-1 and 10-2 that have accepted the participation in the competitive game. The server 30 may also transmit information indicating that the matching was successful to the game terminals 10-1 and 10-2.

[0217] Thereafter, the selection unit 330 of the server 30 executes a process of randomly selecting a predetermined number (e.g., 29) of player characters that can be used in the battle game and that are associated with the user IDs of the users (U1, U2) who will be opponents, from among the multiple player characters managed by the management unit 320, based on the same selection conditions (S302). Here, an example of the process of S302 will be described below with reference to the flowchart of FIG.

[0218] The server 30 sets the selection conditions stored in the "selection conditions" field by referring to the character selection conditions table TBL6 shown in Fig. 24, which is applied in the Random Player Cup battle game (S320). For example, the selection conditions are set in order starting from the top candidate ID: PS1 in the character selection conditions table TBL6.

[0219] Then, the server 30 randomly selects a player character from the character information table TBL2 (an example of a plurality of player characters managed by the management unit 320) illustrated in Fig. 9 based on the selection conditions set in S320 (S322). That is, the server 30 selects a player character by random lottery from a population of player characters that satisfy the selection conditions among the player characters stored in the character information table TBL2.

[0220] Thereafter, the server 30 stores the character ID of the player character selected in S322 in association with the user ID in a storage device (for example, RAM 33, auxiliary storage device 34, database DB, etc.), and generates randomly selected character data DT1 (S324).

[0221] FIG. 25 shows an example of randomly selected character data DT1. The randomly selected character data DT1 is data in which the character IDs of player characters selected by the random selection process by the selection unit 330 are stored in association with user IDs. The example in FIG. 25 shows a case in which users U1 and U2 compete against each other in a battle game (battle ID: M1) held in a tournament (first Player Random Cup) with tournament ID: E1. The randomly selected character data DT1 in FIG. 25 shows data associated with the user ID of user U1, and similarly, the character ID of a player character selected by the random selection process is also associated with the user ID of the opponent user U2.

[0222] The randomly selected character data DT1 in FIG. 25 includes fields for "candidate ID" and "character ID." The candidate IDs in the randomly selected character data DT1 correspond to the candidate IDs in the character selection condition table TBL6 in FIG. 24. Furthermore, the "character ID" field in the randomly selected character data DT1 stores the character ID of a player character selected by the random selection process by the selection unit 330. In other words, the character ID of a player character randomly selected based on the selection conditions associated with the candidate IDs in the character selection condition table TBL6 in FIG. 24 is stored in association with the corresponding candidate ID in the randomly selected character data DT1 in FIG. 25.

[0223] After S324, the server 30 determines whether the random selection process has been completed for positions other than the position random frame (the candidate IDs at the end of FIGS. 24 and 25: PR1 and PR2) (S326). If the server 30 determines NO in S326, it returns to S320 and sets the selection conditions for 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 in FIG. 24. Thereafter, the server 30 repeats the processes 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 processes of S320 to S326 are 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.

[0224] If the server 30 determines YES in S326, it proceeds to random selection processing S328 to S336 for the position random slot. The processing of 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 a plurality of positions, and then randomly selects a player character based on the selection conditions corresponding to the determined position.

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

[0226] After S334, the server 30 determines whether all random selection processes have been completed (S336). If the determination in S336 is NO, the server 30 returns to S328 and executes S328 to S336 again, thereby completing all random selection processes.

[0227] Although FIG. 29 shows an example in which one player character is randomly selected for each candidate ID to be selected, for example, random selection processing for a plurality of candidate IDs may be executed substantially simultaneously by parallel processing.

[0228] 29 shows an example in which the processing of S320 to S326 for the first selection candidate is performed followed by the processing of S328 to S336 for the second selection candidate, but either processing may be performed first. As a variation, a player character associated with each user's user ID may be randomly selected by performing only the processing of S320 to S326 for the first selection candidate or only the processing of S328 to S336 for the second selection candidate.

[0229] The process illustrated in Fig. 29 (i.e., the process of S302 in Fig. 28) is executed for both user U1 and user U2. Therefore, as shown in Fig. 25, randomly selected character data DT1 associated with the user IDs of user U1 and user U2 is generated.

[0230] Returning to FIG. 28, the server 30 transmits the character IDs of the player characters 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 in the "character ID" field of the randomly selected character data DT1 shown in FIG. 25 (i.e., the 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 battle ID is also transmitted. 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).

[0231] Game terminal 10-1, which has received 29 character IDs for one team from server 30, stores the received 29 character IDs in the "character ID" field of user team table TBL12, an example of which is shown in FIG. 16. This makes it possible for one team's worth of player characters associated with user U1's user ID to be used in the Random Player Cup competitive game. The same is true for game terminal 10-2, which has received 29 character IDs for one team from server 30.

[0232] Then, the user U1 and the user U2 make the above-mentioned order formation and the like, and a competitive game is executed between the game terminal 10-1 and the game terminal 10-2 (S102). The competitive game can be executed, for example, by direct communication between the game terminal 10-1 and the game terminal 10-2 using a P2P connection or the like. The competitive game may also be executed via the server 30. During the competitive game, the user U1 and the user U2 each operate player characters of their own team to progress the game.

[0233] Thereafter, when the competitive game between user U1 and user U2 ends, the user terminal 10-1 and the user terminal 10-2 transmit the results of the competitive game to the server 30 (S104-1 and S104-2). Note that if the competitive game is executed via the server 30, S104-1 and S104-2 can be omitted.

[0234] Thereafter, the server 30 transmits information for awarding tournament points and rewards to the users U1 and U2 according to the results of the competitive game to the user terminals 10-1 and 10-2 (S306-1 and S306-2).

[0235] Next, an example of processing will be described when a competitive game of the Team Random Cup baseball game (an example of a specific competitive game) is played between user U1 and user U2 in the game system 1. Fig. 30 is a sequence chart showing an example of processing by the game system 1.

[0236] When user U1 and user U2 perform an operation to participate in the Team Random Cup competitive game on game terminal 10-1 and game terminal 10-2, information about the operation is transmitted to server 30 via network N (S140-1 and 140-2). Server 30 receives information about the operation to participate in the competition from game terminals 10-1 and 10-2, and executes a process to accept participation in the Team Random Cup competitive game (S340).

[0237] Thereafter, the selection unit 330 of the server 30 executes a process of randomly selecting teams (one example of a target team) that can be used in the competitive game and that are associated with the user IDs of the users (U1, U2) who will be competing against each other, from among the multiple teams managed by the management unit 320, based on the same selection conditions (S342). Here, an example of the process of S342 will be described below with reference to the flowchart of FIG.

[0238] The server 30 sets the team selection conditions to be applied in the Team Random Cup competitive game (S360). For example, by referring to the team selection condition table TBL7 illustrated in Fig. 26, one of the selection conditions stored in the "selection condition" field is set. For example, selection conditions may be set that target all teams (12 teams) or the two teams participating in the Japan Series.

[0239] 10 (an example of a plurality of teams managed by the management unit 320) based on the selection conditions set in S360 (S362). That is, the server 30 selects a team by random drawing from a population of teams that satisfy the selection conditions among the 12 teams stored in the team information table TBL3.

[0240] Thereafter, the server 30 stores the team ID of the team selected in S362 in association with the user ID in a storage device (for example, RAM 33, auxiliary storage device 34, database DB, etc.), and generates randomly selected team data DT2 (S364).

[0241] 27 shows an example of randomly selected team data DT2. The randomly selected team data DT2 is data in which the team IDs of teams selected by the random selection process by the selection unit 330 are stored in association with the user IDs of the two users who will compete in the match. FIG. 27 shows an example in which a team selection condition ID: S1 of "all teams" is applied to a competitive game (match ID: M15) held in a tournament (Team Random Cup, 1st) with tournament ID: E2, and team ID: TC1 is associated with user ID: U1 and team ID: TP6 is associated with user ID: U2.

[0242] 30, the server 30 transmits the team ID of the team associated with user ID: U1 from among the teams randomly selected in S342 to the game terminal 10-1 of user U1 (S344-1). At the time of this transmission, data such as the user ID and battle 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).

[0243] Upon receiving the team ID from the server 30, the game terminal 10-1 refers to the team information table TBL3 in FIG. 10 and acquires the character IDs of the 29 players registered in the "Registered Players" field corresponding to the received team ID. The game terminal 10-1 then stores the acquired character IDs of the 29 players in the "Character ID" field of the user team table TBL12 illustrated in FIG. 17. This makes the team assigned to the user U1 (the 29 player characters that make up the team) available for use in the Team Random Cup competitive game. The same is true for the game terminal 10-2 that receives the team ID from the server 30.

[0244] The subsequent processes of S142, S144-1, S144-2, S346-1 and S346-2 are the same as the processes of S102, S104-1, S104-2, S306-1 and S306-2 in FIG. 28, and therefore description thereof will be omitted.

[0245] [6. Summary] In the game system 1 according to the embodiment described above, the "player characters or teams (each an example of a user object)" associated with the user identification information of each user who will compete against each other is not selected by each user, but is randomly selected based on the same selection conditions from among multiple player characters or teams that users who have accepted participation in the competitive game can commonly use in the competitive game. In other words, the user objects that users can use in the competitive game are randomly assigned to each user from the "same population," ensuring fairness in the gameplay conditions. This prevents only popular player characters or teams from being associated with each user's user identification information, eliminating bias in the player characters or teams used by each user in the competitive game. Furthermore, because the gameplay conditions during a match are fair, it becomes possible for users to genuinely compete with each other in terms of game skill. This increases the enjoyment of the competitive game not only for the users competing but also for those spectating the match.

[0246] 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 the Player Random Cup competitive game (an example of a specific competitive game), so that it is possible to form a desired team that is less likely to have bias in position, ability, etc.

[0247] Furthermore, in the game system 1, in the competitive game of the Random Player Cup, the player characters selected by the selection unit 330 include a first player character to be selected whose position has been determined before the selection, and a second player character to be selected (position random slot) whose position has not been determined before the selection. When selecting the second player character to be selected, the selection unit 330 randomly determines a position from among a plurality of positions, and randomly selects the second player character to be selected based on the selection conditions corresponding to the determined position. With this configuration, the player characters assigned to the user can include not only player characters with determined positions, but also player characters whose position is unknown until they are selected, thereby increasing the entertainment value of the game.

[0248] Furthermore, in the game system 1, parameters such as abilities associated with a player character may be set to imitate a real-life player (an example of a real person) corresponding to the player character. In this case, users can simulate real-world matches in the game using player characters that imitate real-life players. In particular, in the case of a Team Random Cup competitive game (an example of a specific competitive game), simulated matches of matches between real-world teams can be realized in the game. For example, if a mock match of a similar match (team combination) scheduled in a real-world sports match is realized in the game before the match is actually played, it is possible to build excitement for the real-world match through the game. Here, teams (an example of groups) made up of characters that imitate real-life people and used in the mock matches in the game are randomly assigned to each competing user, so that mock matches of a variety of matchups can be realized without bias.

[0249] Furthermore, in the game system 1, it is possible to hold multiple competitive games during a tournament period (an example of a predetermined period), and the random selection may be performed each time a competitive game is held. With this configuration, various player characters or teams are assigned to each user for each match, without bias. In particular, when characters modeled after real people are used to simulate matches between real-world teams in the game, the teams assigned to each user for each match are randomly selected, and each team will be used by users with a variety of operating skills. Therefore, by tallying up the results of the in-game mock matches, statistically speaking, teams in the game that correspond to teams that are actually strong in the real world will be ranked higher. Therefore, users can enjoy predicting the results of subsequent matches in the real world based on the tally of the in-game mock matches.

[0250] [7. Variations] The present invention is not limited to the above-described embodiment.

[0251] [7-1] It is also possible to allow each user to play the specific competitive game at any time without limiting the period during which the specific competitive game can be played, and to have the selection unit 330 execute the random selection process described above each time the specific competitive game is played to randomly select a character or team to be associated with the user ID.

[0252] [7-2] The above describes an example in which the player characters or teams available to the user are reset for each competitive game played during the Random Player Cup or Random Team Cup, and player characters or teams are randomly selected for each competitive game. As a variation, for example, instead of resetting the player characters or teams available to the user for each competitive game, the player characters or teams randomly assigned to the user in the first competitive game during the tournament in which the user participates may also be used in the second and subsequent competitive games. In other words, the player characters or teams assigned to the user once during the tournament may be used until the end of the period.

[0253] [7-3] Furthermore, a player character or team once assigned to a user during a tournament held in a first period may be made unavailable to 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 in a competitive game held in a first period may be excluded from being selected randomly in a competitive game held in a second period. Alternatively, a player character or team once assigned to a user during a tournament held in a first period may be less likely to be selected in a tournament held in a second period by reducing the probability of selection.

[0254] [7-4] Furthermore, a player character or team randomly assigned to a user in one fighting game may be made unavailable to the user in the next fighting game (for example, excluded from random selection). Alternatively, a player character or team randomly assigned to a user in one fighting game may be made less likely to be selected in the next fighting game by reducing the selection probability.

[0255] [7-5] The player characters or teams available to the user may be randomly selected after two or more predetermined number of matches have been played, rather than being randomly selected for each match. For example, if the predetermined number of matches is three, the player characters or teams randomly assigned to the user in the first match may be used in the first through third matches, and the player characters or teams randomly assigned to the user in the fourth match may be used in the fourth through sixth matches.

[0256] [7-6] The same player character or team may be assigned to each user who will compete against each other. For example, randomly selected player characters or teams may be associated with the user IDs of both competing users, so that both users will use the same player character or team in the competitive game. Also, the same player character or team (e.g., randomly selected player characters or teams) may be assigned to all users participating in a tournament.

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

[0258] [7-8] As a result of randomly selecting a predetermined number of objects associated with the user IDs of each user who will be competing against each other, there may be some differences in the abilities (e.g., the sum or average of ability values) of the predetermined number of objects selected for each user. Therefore, a configuration that can reduce this difference in ability and increase the fairness of gameplay conditions regarding abilities between competing users will be described below.

[0259] A competitive game is a game in which teams (an example of groups) each composed of a first predetermined number (e.g., 29) of player characters (an example of objects) compete against each other. For example, the competitive game may be the Random Player Cup. The selection unit 330 randomly selects a second predetermined number (e.g., 27) of player characters that is less than the first predetermined number, and then evaluates the ability difference between the second predetermined number of player characters selected for each competing user. For example, in the case of the Random Player Cup competitive game described above, after a random selection process of 27 player characters other than the position random slots is executed for two competing users, the difference between the users in the total value (or average, etc.) of the overall ability (an example of ability) of the 27 player characters is calculated, and it is evaluated whether the difference exceeds a predetermined standard (e.g., less than 100). If the difference in ability exceeds the predetermined standard, the selection conditions related to the abilities applied to each user in selecting the remaining player characters (e.g., selecting the two players in the position random slots) are changed so as to reduce the difference in ability. As a specific example, if the total value of the overall ability of 27 player characters assigned to user U1 by random selection is 100 or more greater than the total value of the overall ability of 27 player characters assigned to user U2, the selection condition applied to user U1 may be, for example, "total ability is 199 or less," and the selection condition applied to user U2 may be, for example, "total ability is 200 or more."

[0260] While the above example shows a specific example of adjusting the selection conditions applied to the random selection of two players from the position random slots, the present invention is not limited to this example. For example, the present invention can also be applied to a competitive game between teams composed of characters that do not have position random slots.

[0261] [7-9] While the above description has primarily focused on the example of a baseball game, the present invention can also be applied to other games. For example, the present invention can be applied to a variety of games, regardless of game format or genre, as long as they include at least a competitive game mode, such as other sports games (games based on soccer, tennis, American football, basketball, ice hockey, volleyball, rugby, etc.), racing games, fighting games, combat games, digital card games, role-playing games, simulation games, adventure games, and training games. In particular, the present invention is suitable for games in which groups of two or more objects compete against each other.

[0262] [7-10] In the above, for example, an example has been shown in which the reception unit 310, management unit 320, selection unit 330, etc. are provided in the server 30, but this is not limiting. Game terminal 10 and server 30 can communicate with each other to send and receive various data, and both are information processing devices (computers) equipped with a CPU, ROM, RAM, auxiliary storage device, communication unit, etc., and basically have the same hardware configuration. Therefore, some of the various functions of server 30 described above may be realized by CPU 11 of game terminal 10, and the rest may be realized by CPU 31 of server 30. Alternatively, all of the various functions of server 30 described above may be realized by CPU 11 of game terminal 10.

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

[0264] [7-12] The computer-readable program according to this 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, or a semiconductor memory, 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. Furthermore, the means for providing the program to a computer is not limited to the recording media described above, and can also be via a communication network such as the Internet.

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

[0266] 1) A game system (1) according to one aspect of the present invention provides a game (e.g., a baseball game) in which users can participate in a specific competitive game (e.g., a competitive game of the Player Random Cup or the Team Random Cup), and includes: an acceptance means (310) for accepting participation in the competitive game; a management means (320) for storing and managing, in a storage device, a plurality of use objects (TBL2 or TBL3) that can be used in the competitive game by users whose participation has been accepted by the acceptance means (310); and a selection means (330) for randomly selecting, based on identical selection conditions (TBL6 or TBL7), from the plurality of use objects managed by the management means (320), the use objects (e.g., player characters or teams) that can be used in the competitive game and that are associated with user identification information (e.g., user IDs) of each user who will be opponents against each other.

[0267] 10) A game control device (10 or 30) according to one aspect of the present invention provides a game in which users can participate in a specific competitive game, and includes: an acceptance means (310) for accepting participation in the competitive game; a management means (320) for storing and managing, in a storage device, a plurality of usable objects that can be used in the competitive game by users whose participation has been accepted by the acceptance means (310); and a selection means (330) for randomly selecting, based on identical selection conditions, from the plurality of usable objects managed by the management means (320), the usable objects that are associated with user identification information of each user who will be opponents against each other and that can be used in the competitive game.

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

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

[0270] 13) A control method for a game system (1) according to one embodiment of the present invention is a method for controlling a game system that provides a game in which users can participate in a specific competitive game, and includes: an acceptance step (S300 or S340) of accepting participation in the competitive game; a management step of storing and managing in a storage device a plurality of use objects (TBL2 or TBL3) that can be used in the competitive game by users whose participation has been accepted in the acceptance step (S300 or S340); and a selection step (S302 and S320 to S336, or S342 and S360 to S364) of randomly selecting, based on identical selection conditions, the use objects that can be used in the competitive game and that are associated with user identification information of each user who will be opponents against each other, from the plurality of use objects managed in the management step.

[0271] 14) A control method for 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 users can participate in a specific competitive game, and includes an acceptance step (S300 or S340) of accepting participation in the competitive game, a management step of storing and managing in a storage device a plurality of use objects (TBL2 or TBL3) that can be used in the competitive game by users whose participation has been accepted in the acceptance step (S300 or S340), and a selection step (S302 and S320 to S336, or S342 and S360 to S364) of randomly selecting, based on identical selection conditions, the use objects that can be used in the competitive game and that are associated with the user identification information of each user who will be competing against each other, from the plurality of use objects managed in the management step.

[0272] According to the above aspects 1), 10), and 14), the object associated with the user identification information of each user who will be competing against the other is not selected by each user, but is randomly selected based on the same selection criteria from among multiple objects that users who have accepted participation in the competitive game can commonly use in the competitive game. In other words, the objects that users can use in the competitive game are randomly assigned to each user from the same population, ensuring fairness in the gameplay conditions. This prevents popular objects or objects with high abilities from being associated with each user's user identification, eliminating bias in the objects used by each user in the competitive game. Furthermore, since the gameplay conditions during the competition are fair, it becomes possible for users to genuinely compete in terms of game skill. This increases the enjoyment of the competitive game not only for the competing users but also for those spectating the competition.

[0273] 2) In one aspect of the present invention, the use object may be an object (for example, a player character) that can be used by the user during the fighting game.

[0274] According to the aspect described in 2), it is possible to eliminate imbalances in the objects used by each user in a battle game.

[0275] 3) In one aspect of the present invention, the competitive game is a game in which groups (e.g., teams) consisting of two or more objects (e.g., player characters) compete against each other, and the user identification information of each user who is an opponent is associated with the two or more objects from 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.

[0276] According to the aspect described in 3), by setting selection conditions such as role and ability individually for each object to be selected, it is possible to form a desired group that is less likely to have bias in role, ability, etc.

[0277] 4) In one aspect of the present invention, each of the plurality of objects managed by the management means (320) may be associated with a parameter, the selection condition is a condition related to the parameter, and the selection means (330) may randomly select the object that can be used in the fighting 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.

[0278] According to the aspect described in 4), conditions relating to various parameters associated with the object can be set as selection conditions for random selection.

[0279] 5) In one aspect of the present invention, the parameters may include capability information of the object.

[0280] According to the aspect described in 5), the objects associated with the user identification information of each user who will be competing against each other are randomly selected based on the "same selection conditions" regarding the ability parameters of the objects. This ensures fairness in the gameplay conditions regarding the abilities of the objects that each user who will be competing against each other can use in the competitive game.

[0281] 6) In one aspect of the present invention, the parameters may include role information (for example, position information) of the object.

[0282] According to the aspect described in 6), the objects associated with the user identification information of each user who will be competing against each other are randomly selected based on the "same selection conditions" regarding the role parameters of the objects. This ensures fairness in the gameplay conditions regarding the roles of objects that each user who will be competing against each other can use in the competitive game.

[0283] 7) In one aspect of the present invention, the object of use may be a group (for example, a team) of two or more objects that can be used by the user during the fighting game.

[0284] According to the aspect described in 7), it is possible to eliminate bias in the groups used by each user in a competitive game.

[0285] 8) In one aspect of the present invention, the object may be 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 resemble the real person corresponding to the object.

[0286] According to the aspect described in 8), a mock battle of a real-world match can be realized in the game between users using objects that resemble real people. In particular, when the objects used are groups consisting of two or more objects (e.g., teams in a sports game), a mock battle of a match between real-world teams can be realized in the game. For example, if a mock battle of a similar match (team combination) scheduled in a real-world sports match is realized in the game before the match is actually played, it is possible to build excitement for the real-world match through the game. Here, the group of objects that resemble real people used in the mock battle in the game is randomly assigned to each user competing, so that mock battles of a variety of matches can be realized without bias.

[0287] 9) In one aspect of the present invention, each user may play the competitive game multiple times within a predetermined period (e.g., during a tournament), and the selection means (330) may perform a random selection based on the same selection conditions each time the competitive game is played within the predetermined period.

[0288] According to the aspect described in 9), each time a competitive game is played, a use object associated with a user's identification information is randomly selected, so that each user participating in the match is assigned a variety of use objects without bias for each match. In particular, when objects representing real people are used to simulate matches between real-world teams in a game, the groups assigned to each user are randomly selected for each match, so that each group is used by users with a variety of operating skills. Therefore, by tallying up the results of the in-game mock matches, statistically, the in-game groups that correspond to teams that are actually strong in the real world will be ranked higher. Therefore, based on the tally of the in-game mock matches, players can enjoy predicting the results of subsequent matches in the real world.

[0289] 15) In one aspect of the present invention, the objects selected by the selection means (330) include a first object to be selected whose role (e.g., position) has been decided before the selection, and a second object to be selected whose role has not been decided before the selection (e.g., a player character in a position random slot), and when selecting the second object to be selected, the selection means (330) may randomly determine the role from among a plurality of roles, and randomly select the second object to be selected based on the selection conditions corresponding to the decided role.

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

[0291] 16) In one aspect of the present invention, the competitive game is a game in which groups (e.g., teams) consisting of a first predetermined number (e.g., 29) of objects (e.g., player characters) compete against each other, and the selection means randomly selects a second predetermined number (e.g., 27) of objects that is less than the first predetermined number based on the same selection conditions, 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 if the ability difference exceeds a standard, varies the selection conditions applied to each user in selecting the remaining objects so as to reduce the ability difference.

[0292] According to the aspect described in 16), even if there is a certain degree of difference in ability among the objects selected for each user as a result of randomly selecting the second predetermined number of objects, this 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). Thus, it is possible to increase the fairness of the gameplay conditions regarding ability between competing users. [Explanation of symbols]

[0293] 1...game system, N...network, DB...database, 10...game terminal, 11...CPU, 13...RAM, 14...auxiliary storage device, 30...server, 31...CPU, 33...RAM, 34...auxiliary storage device, 100...data storage unit, 110...terminal control unit, 300...data storage unit, 310...reception unit, 320...management unit, 330...selection unit, TBL1...tournament information table, 300...data storage unit, TBL2...character information table, TBL3...team information table, TBL4...user management table, TBL5...match management table, TBL6...character selection condition table, TBL7...team selection condition table, TBL11...user information table, TBL12...user team table, DT1...randomly selected character data, DT2...randomly selected team data

Claims

[Claim 1] A game system that provides a game in which a user can participate in a specific competitive game, an acceptance means for accepting participation in the competitive game; a management means for storing and managing in a storage device a plurality of use objects that can be used in the competitive game by users whose participation has been accepted by the accepting means; a selection means for randomly selecting, based on the same selection conditions, from the plurality of use objects managed by the management means, the use objects that are associated with the user identification information of each user who will be the opponents and that can be used in the battle game; A game system including:

Images