Game system, game control device, and program

Abstract

This will allow players to choose their target based on game conditions, while also increasing the chances of finding a match even under conditions where matching was previously difficult. [Solution] The registration unit registers multiple objects for use, each containing at least one object, based on user operations. The condition setting unit allows the user to set conditions, each of which corresponds to one of multiple game conditions, that can be any two or more of those conditions, based on user operations. The matching unit matches the user with a play partner based on the matching request accompanied by the condition settings. The game execution unit executes a game using the objects for use that correspond to the game conditions for which the matching was successful.

Description

Technical Field

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

Background Art

[0002] Conventionally, an online game in which matched users can play against each other via a network is known. A user can set matching conditions to search for an opponent.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] For example, when a plurality of leagues in which each user can arbitrarily participate are provided, a user can specify any league as a matching condition. In this case, users tend to gather in leagues with a large number of participants. For this reason, people concentrate on a specific one league, and for users who want to play in a league with a small number of participants, matching may not be easily established and the waiting time may become long, and there may be cases where they cannot enjoy the game satisfactorily.

[0005] Therefore, one of the objects of the present invention is to increase the matching opportunity even under conditions where matching is difficult.

Means for Solving the Problems

[0006] A game system or game control device according to one aspect of the present invention includes: registration means for registering a plurality of objects to be used, each containing at least one object, based on user operation; condition setting means for enabling the setting of any two or more game conditions corresponding to each of the plurality of objects to be used, based on user operation; matching means for matching a player for the user based on a matching request accompanied by the condition setting; and game execution means for executing a game using the objects to be used that correspond to the game conditions for which the matching has been achieved.

[0007] A game control device according to another aspect of the present invention includes: registration means for registering a plurality of objects to be used, each containing at least one object, based on user operation; condition setting means for enabling the setting of any two or more game conditions corresponding to each of the plurality of objects to be used, based on user operation; and game execution means for executing a game using the objects to be used that correspond to the game conditions for which a match has been made based on a matching request accompanied by the condition setting. [Brief explanation of the drawing]

[0008] [Figure 1] This is a schematic block diagram showing an example of the configuration of a game system according to one embodiment of the present invention. [Figure 2] This figure shows an example of the display screen for the event deck. [Figure 3] This figure shows an example of a screen displaying the abilities of the main character. [Figure 4] This is an example of the main screen for the real-time battle mode. [Figure 5] This figure shows an example of a screen for setting up a development player lineup. [Figure 6] This figure shows an example of the search settings screen. [Figure 7] This figure shows an example of a pre-match confirmation screen. [Figure 8] This figure shows an example of a character information table. [Figure 9]A diagram for explaining an example of matching processing [Figure 10] It is a schematic functional block diagram showing an example of the functional configuration of the game system. [Figure 11] It is a diagram showing an example of a user information table. [Figure 12] It is a diagram showing an example of a game condition table. [Figure 13] It is a diagram showing an example of a team order table. [Figure 14] It is a diagram showing an example of the possessed character data. [Figure 15] It is a diagram showing an example of team order data. [Figure 16] It is a diagram showing another example of the search setting screen. [Figure 17] It is a diagram showing another example of the team order table. [Figure 18] It is a flowchart showing an example of the processing of the game system. [Figure 19] It is a sequence chart showing an example of the processing of the game system.

Mode for Carrying Out the Invention

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

[0010] [1. Configuration of Game System] FIG. 1 is a schematic block diagram showing a configuration example of a game system 1 according to an embodiment of the present invention. This game system 1 includes a plurality of game terminals 10-n (n is a positive integer: 10-1, 10-2,...) and a server 30. The game terminals 10-n and the server 30 in the game system 1 are connected to each other via a network N such as the Internet so as to be capable of data communication. Here, since the plurality of game terminals 10-n have the same configuration, when not particularly distinguished, they will simply be described as "game terminal 10".

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

[0012] The game terminal 10 operated by the user is a computer used by the user to play games. The game terminal 10 is, for example, a home game console (stationary or portable), a personal computer, a smartphone, a mobile phone terminal, a PHS (Personal Handy-phone System) terminal, a personal digital assistant (PDA), a tablet computer, a multi-functional television receiver (so-called smart TV), a business (commercial) game machine installed in a game facility, etc.

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

[0014] In the game system 1, computer vs. computer (also referred to as CPU vs. CPU) or communication-based battles are possible. In a communication-based battle, for example, user A operating the game terminal 10-1 and user B operating the game terminal 10-2 can play a battle game via the network N. In this case of communication-based battle, for example, there is a method of directly communicating and battling between the game terminal 10-1 and the game terminal 10-2 matched by the server 30 by P2P (Peer to Peer) connection or the like. Alternatively, there is also a method of communicating and battling by exchanging data between the game terminal 10-1 and the game terminal 10-2 via the server 30. Communication-based battles may be conducted by any method.

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

[0016] On the other hand, communication between game terminals 10-1 and 10-2, which are connected via P2P or similar methods, can be achieved, for example, by UDP (User Datagram Protocol), a communication protocol on the transport layer of the OSI reference model, which is mainly implemented on the IP protocol. UDP is a communication method that sends data to the other game terminal without performing data delivery confirmation or error correction, so it has the advantage of high data transfer speed but low data reliability. It is also possible to use other existing protocols other than UDP for communication between game terminals 10-1 and 10-2, or to use new protocols that will be defined in the future.

[0017] Furthermore, for example, a game terminal 10-n having a short-range wireless communication function using a predetermined frequency band (for example, the 2.4GHz frequency band) can also perform competitive games and the like by communicating directly with multiple game terminals 10-n.

[0018] (Game console hardware configuration) The game terminal 10 mainly comprises a CPU (Central Processing Unit) 11, ROM (Read Only Memory) 12, RAM (Random Access Memory) 13, auxiliary storage device 14, communication unit 15, operation unit 16, display unit 17, and audio output unit 18, which are interconnected via bus lines including an address bus, data bus, and control bus. Interface circuits, image processing units, or sound processing units are interposed between the bus lines and each component as needed, but these are omitted from the illustration here.

[0019] The CPU 11 interprets and executes game program instructions and controls the entire game terminal 10. The ROM 12 stores programs and data necessary for the basic operation control of the game terminal 10. The RAM 13 stores various programs and data and reserves workspace for the CPU 11.

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

[0021] The communication unit 15 is equipped with a communication interface (not shown) and has a communication control function for data communication during game execution. 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 (for example, the 2.4 GHz frequency band). Based on instructions from the CPU 11, the communication unit 15 transmits a connection signal to connect the game terminal 10 to the network N, and also receives information transmitted from the communication partner and supplies it to the CPU 11.

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

[0023] The display unit 17 is driven based on image display commands from the CPU 11 and displays game screens, etc. Various known display devices such as liquid crystal displays and organic EL (Electro-Luminescence) displays can be applied to the display unit 17. Alternatively, the display unit 17 can be a touch panel that combines a display device such as a liquid crystal display with a position input unit equipped with a touch interface. When the display unit 17 is configured as a touch panel, the game terminal 10 includes a touch input detection unit (not shown). When an object such as a finger or pen touches the screen, this touch input detection unit detects the contact position coordinates 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 17. The display unit 17 does not need to be integrated with the game terminal 10; for example, it may be an externally connected television monitor, etc., to the game terminal 10. In this case, when the display unit 17 is an externally connected television monitor, etc., the display unit 17 is not included in the configuration of the game terminal 10. The audio output unit 18 generates an analog audio signal based on sound output instructions from the CPU 11 and outputs sound and other audio from the speaker.

[0024] The game terminal 10 may also be equipped with a recording medium drive. Examples of recording medium drives include DVD-ROM drives, CD-ROM drives, hard disk drives, optical disk drives, flexible disk drives, silicon disk drives, and cassette media readers. In this case, the recording medium may be a DVD-ROM, CD-ROM, hard disk, optical disk, flexible disk, or semiconductor memory. The recording medium drive reads image data, audio data, and program data from the recording medium and supplies the read data to the RAM 13 or the like via a decoder.

[0025] (Server hardware configuration) The server 30 mainly comprises a CPU 31, ROM 32, RAM 33, auxiliary storage device 34, and communication unit 35, which are interconnected via bus lines including an address bus, data bus, and control bus. Interface circuits are interposed between the bus lines and each component as needed, but the illustration of the interface circuits is omitted here.

[0026] The CPU 31 interprets and executes instructions from system software and application software, and controls the entire server 30. The ROM 32 stores programs and other data necessary for the basic operation control of the server 30. The RAM 33 stores various programs and data, and reserves workspace for the CPU 31. The auxiliary storage device 34 is a storage device that stores programs and various data. For example, a hard disk drive or a solid-state drive can be used as the auxiliary storage device 34.

[0027] The communication unit 35 is equipped with 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, in a system configuration in which server 30 is integrated into a social networking service (SNS), the communication unit 35 of server 30 controls communication with the SNS server. Also, for example, server 30 controls communication with a video distribution server that distributes game videos played by users to viewers. It is also possible to give server 30 a video distribution function.

[0028] Server 30 can be configured as a single computer, but it can also be configured in a function-distributed manner, where the functions of Server 30 are distributed among multiple servers. Alternatively, a load-balancing configuration can be implemented by providing redundancy (multiplexing) by placing multiple Server 30 on Network N. Furthermore, Server 30 may be configured as a cloud server utilizing cloud computing technology.

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

[0030] In the following, we assume that the game device 10 is a smartphone or tablet computer equipped with a touch panel.

[0031] [2. Overview of an example game] An overview of one example of the game is described below. Game System 1 can run various games. For example, it can run a wide variety of games regardless of game format or genre, including sports games (games based on baseball, soccer, tennis, American football, etc.), racing games, fighting games, combat games, digital card games, and more.

[0032] For example, in a baseball game, various game modes, including training and matches, are executed based on one or more objects (e.g., game characters, game cards, or game items). Below, as an example of a game executed in Game System 1, we will mainly describe a baseball game, which is based on baseball, and will also mention other games as needed.

[0033] This embodiment of the baseball game includes various game modes such as training mode, team training mode, lottery acquisition mode, enhancement mode, CPU battle mode, and real-time battle mode.

[0034] The training mode is a character training mode in which the user trains a target character to create their own original game character. In this embodiment, it is possible to train a pitcher or a fielder (including a catcher) character in training mode. Hereinafter, the game character created by the user in training mode will be referred to as a "trained player". Trained players can be used in other game modes such as team training mode, CPU battle mode, and real-time battle mode. Team training mode is a game mode in which the user trains a team composed of multiple player characters.

[0035] The lottery acquisition mode is a game mode in which players can obtain "event characters," described below, through a lottery, which can be used as auxiliary objects when training target characters in the training mode. In this lottery acquisition mode, for example, a lottery (so-called gacha) is held to determine which event character to give to the user from among all the event characters in the game. In order for the user to play the lottery acquisition mode, for example, a certain amount of in-game points, paid items, etc. may be required. Enhancement Mode is a mode in which you can improve the level of event characters by combining event characters obtained through methods such as lottery acquisition mode.

[0036] The CPU battle mode is also called the computer battle mode. For example, the CPU battle mode may be given a name such as "Stadium". In this CPU battle mode, the user controls the batting, pitching, and fielding of their own team of players, which are made up of players trained in the training mode, and plays against an opponent team that is automatically controlled by the CPU. For example, the opponent team that the CPU automatically controls is a team made up of players trained by other users in the training mode.

[0037] The real-time battle mode allows users to play against other users in remote locations online via network N. In this real-time battle, for example, a match between a user's team and an opponent's team (another user's baseball team on network N) progresses via communication based on the operations performed on each game terminal 10. For example, if a user is on the defensive side and the opponent is on the offensive side, the player characters will pitch or field according to the opponent's operations (pitching or fielding operations), and will bat or run according to the user's operations (batting or base running operations). In such action games, the game situation is updated based on each user's operations on the player characters. This real-time battle is a battle format also used in e-sports (electronic sports).

[0038] In the real-time battle mode of this embodiment, at least two types of objects are available: players trained by the user in training mode, and event characters that are also used in training mode. The following will first explain the training mode, and then provide a more detailed explanation of the real-time battle mode using trained players and event characters.

[0039] (2-1. Training Mode) In the training mode, the main character being trained practices baseball at a high school, and through various events, the main character is trained to become either a pitcher or a fielder. In this embodiment, the training mode has multiple scenarios, and the high school the character attends differs depending on the scenario. In this game, the high school the main character attends is determined by the user selecting one of the scenarios.

[0040] Once a scenario is selected, the user first determines the basic information of the main character. This includes name, position, dominant hand, batting form, and, if the character is a pitcher, pitching form. For positions, the user can choose from pitcher, catcher, first baseman, second baseman, third baseman, shortstop, and outfielder. Below, positions other than pitcher will be described as fielders.

[0041] Once the main character's basic information is determined, the next step is to set up the event deck. The event deck is where you set up the event characters who will be teammates with the main character at the high school they attend, practicing and interacting with them. Event characters are characters who influence the main character's development (providing advantageous effects to the user) through events that occur during the main character's training process, and the user selects the event characters to set up in the event deck from among the event characters they possess. Event characters can be obtained as rewards for winning in CPU battle mode or real-time battle mode, or through a lottery in the aforementioned lottery acquisition mode.

[0042] Event characters acquired by a user in the game are stored in memory devices (database DB, auxiliary memory device 14, auxiliary memory device 34, etc.) associated with the user's user ID and managed by game system 1. There is a limit to the number of event characters each user can possess. Users can sell their owned event characters as needed. Selling event characters converts them into points or in-game currency that can be used within the game.

[0043] Furthermore, users can select one base character and one or more enhancement material characters from their owned event characters, and enhance the base character by combining it with the enhancement material characters. This enhancement process increases the level of the event character selected as the base character. On the other hand, event characters used as enhancement material characters are no longer owned by the user.

[0044] Before starting a scenario in Training Mode, it is advisable for the user to raise the event character's level beforehand through the enhancement process described above in Enhancement Mode. This is because the higher the event character's level, the greater the increase in the main character's abilities through training and the higher the initial evaluation of the main character, allowing for a more advantageous development of the main character.

[0045] Figure 2 shows an example of the event deck display screen G100. When setting up an event deck, the display screen G100 shown in Figure 2 is displayed. The deck name is displayed in display area A110. Users can register combinations of event characters within the event deck in advance before starting a scenario in training mode. The change button B1101 is a button for changing the deck name.

[0046] The selected event character is displayed in display area A112. For example, up to six event characters can be set in the event deck. While the event characters are selected from those owned by the user, some can be selected from those owned by other users (for example, other users associated with the user).

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

[0048] Additionally, each event character may have a preferred training method associated with them. When the main character trains with an event character using that character's preferred method, the main character may learn skill tips from that character, or special training events may occur.

[0049] Display area A114 shows a list of the event characters' preferred training types. The types of training include "Batting," "Strength," "Baserunning," "Arm Strength," "Pitching Speed," "Control," "Stamina," "Breaking Ball," "Fielding," and "Mental." When an event character is set in the event deck, the number of event characters whose preferred training type is displayed in display area A115. In the example shown in Figure 4, it is shown that one event character specializes in batting, two event characters specialize in strength, one event character specializes in baserunning, one event character specializes in arm strength, and one event character specializes in mental. Note that an event character may have more than one preferred training type.

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

[0051] Once you have finished selecting the game items as described above, the scenario will begin. Before explaining the content of the scenario, let's explain the ability parameters of the main character being trained. Figure 3 shows an example of the ability list screen G200 when the main character is trained as a fielder. The main character's image is displayed in display area A210.

[0052] Display area A211 displays the main character's name. Display area A212 displays the main character's position number. Display area A213 displays the main character's batting form and dominant hand. Display area A214 displays the main character's defensive position.

[0053] Display areas A215 to A221 show the basic abilities of a fielder. The basic abilities displayed in display areas A216 to A221 are shown in eight ranks: S, A, B, C, D, E, F, and G. An ability value of 90 or higher is S, 80-89 is A, 70-79 is B, 60-69 is C, 50-59 is D, 40-49 is E, 20-39 is F, and 19 or lower is G.

[0054] Display area A215 shows the basic ability related to "ball trajectory," which is represented by a numerical value from 1 to 4 as an evaluation rank. The higher the number, the higher the trajectory of the batted ball and the easier it is to hit a home run. Display area A216 shows the basic ability related to "contact," and the higher the "contact" ability, the easier it is to make contact with the ball and the easier it is to get a hit. Display area A217 shows the basic ability related to "power," and the higher the "power" ability, the easier it is to hit for extra bases. Display area A218 shows the basic ability related to "speed," and the higher the "speed" ability, the faster the base runner is and the easier it is to get an infield hit. Display area A219 shows the basic ability related to "arm strength," and the higher the "arm strength" ability, the faster the ball can be thrown in the field. Display area A220 shows the basic ability related to "fielding ability," and the higher the "fielding ability" ability, the wider the fielding range. Display area A221 shows basic abilities related to "catching," and the higher the "catching" ability, the easier it is to catch the ball well in defense and the less likely errors will occur.

[0055] Display area A222 shows a list of special fielding abilities possessed by the main character. In the example shown in Figure 3, the main character possesses five types of special abilities: "Infield Hit," "Pinch Hitter," "Inside Pitch," "Throwing," and "Consistent Performance." This indicates that the main character is prone to infield hits, has improved ability scores when appearing as a pinch hitter, excels at hitting inside pitches, can throw accurately in the field, and has consistent performance.

[0056] Note that the example shown in Figure 3 illustrates the case where the main character is a fielder, and therefore displays basic and special abilities related to fielders. If the main character is a pitcher, then basic abilities (e.g., ball speed, control, stamina, etc.) and special abilities related to pitchers will be displayed.

[0057] Next, let's explain how the scenario progresses in training mode. For example, the scenario consists of four sections. Sections 1 through 3 each consist of 12 turns, while Section 4 consists of 15 turns. Each turn, the user can choose from several types of training commands to have the main character train, or choose the rest command to have the main character rest. Note that from the middle of Section 4 onwards, high school baseball qualifiers and high school baseball games at Koshien are included. Therefore, if the main character loses a game and is eliminated midway through, Section 4 may be forcibly ended.

[0058] In each turn of each section, in addition to the main character, several teammates appear and significantly influence the main character's development. Teammates include event characters set in the event deck, event characters predetermined for that scenario, and other default characters (non-event characters).

[0059] Additionally, pre-events and post-events may occur with one turn in between. These events include those corresponding to the event characters set in the event deck, those corresponding to combinations of multiple event characters set in the event deck, and scenario-specific scenario events. Whether an event is a pre-event or a post-event is predetermined by the content of the scenario event and the event characters, and each event occurs only if it is selected in the event occurrence lottery. When these events occur, the main character receives training effects corresponding to the event.

[0060] In each turn, the user can gain experience points necessary to increase the main character's ability scores or acquire special abilities, based on the results of the training commands selected by the user and the events that occur. The user then considers which ability parameters to increase and which special abilities to acquire within the range of experience points gained.

[0061] Furthermore, the main character's abilities may improve or special abilities may be acquired based on the results of the user's selected training commands or the outcomes of events that occur, without relying on experience points.

[0062] Basically, the main character's development is completed upon the completion of one scenario. Once the main character's development is complete, they are evaluated based on their basic abilities and special abilities, and a player rank is determined based on that overall player strength value. Main characters that have been developed in development mode are registered as "developed players" that can be used by the user in game modes other than development mode, and are associated with the user ID. Furthermore, "developed players" may also be associated with the information of the scenario that was used for development. After the scenario is completed, another "developed player" can be created by starting the scenario again from the beginning and developing the main character. In other words, by repeating the development in development mode, the user can create multiple "developed players" with various abilities. Furthermore, a team development mode may be provided in which the user develops a team (a group composed of multiple objects) by progressing through a scenario selected from multiple scenarios. In this case, one team can be created by executing one scenario. Teams developed in this team development mode are also registered as "developed teams" that the user can use in other game modes such as real-time battle mode, and are associated with the user ID. In addition, the "developed teams" may be associated with information about the scenario applied to their development.

[0063] (2-2. Real-time battle mode) The following describes the real-time battle mode using the aforementioned training players (an example of the first object) and event characters (an example of the second object).

[0064] In the real-time battle mode of this embodiment, there are two in-game leagues that each user can optionally join. One of the in-game leagues is the "Training Player League," in which users can battle each other using their respective "Training Player Orders" (an example of the first target of use), which are composed of a predetermined number of training players (25 in this embodiment) that each user possesses. The other in-game league is the "Event Character League," in which users can battle each other using their respective "Event Character Orders" (hereinafter referred to as "Event Character Orders") (an example of the second target of use), which are composed of a predetermined number of event characters (25 in this embodiment) that each user possesses.

[0065] (Regarding the lineup of development players) The development player lineup consists of 25 development players owned by the user (for example, 8 starting position players, 8 reserve position players, 3 starting pitchers, 5 relief pitchers, and 1 closer).

[0066] At the start of the game, each user is given a predetermined number of default players to train (for example, 25). Typically, the ability values ​​of these default players are set lower than those of players the user trains in training mode. The ability parameters of the default players are the same for all users. This means that each user can assemble a training lineup that includes the default players even before training more than 25 players in training mode.

[0067] When you first run the real-time battle mode, a default training player lineup is set. For example, when you first run the real-time battle mode, a tutorial on how to play the mode is executed, and the default training player lineup is set during the user interaction in this tutorial. For example, at that time, the CPU 11 of game system 1 automatically selects the training players that it deems optimal from all the training players associated with the user's user ID (i.e., all training players the user has trained in training mode and all default training players), and the default training player lineup is automatically set.

[0068] Alternatively, the lineup consisting of training players used in the aforementioned CPU battle mode may be used as the default training player lineup for real-time battle mode. Note that the training player lineup for real-time battle mode is a dedicated lineup and can be edited by the user as a different lineup from the lineup for CPU battle mode. As a variation, the lineup for CPU battle mode and the training player lineup for real-time battle mode (one of them if there are multiple training player lineups) may be used as a common lineup.

[0069] Figure 4 shows an example of the top screen G300 of the real-time battle mode, which is displayed on the display unit 17 when the real-time battle mode is selected by the user. This top screen G300 includes a training player order editing button B301 for editing the training player order. Tapping the training player order editing button B301 transitions to the training player order editing screen G400, as illustrated in Figure 5.

[0070] In Figure 5, area A410 of the G400 development player order editing screen displays the development player order for the user's team. The development players included in the order are displayed separately as starting lineup members and reserve members. To change members, drag part P411, which contains the name of one member, to part P411, which contains the name of another member. Also, to swap a member with a development player not currently included in the order, dragging part P411 to part P412 will display a list of available development players. Button B421 is the "Auto" button; when the user taps button B421, game system 1 automatically assembles the optimal lineup for the user's development player team. For example, the development player with the highest overall player ability in each position will be automatically selected from all development players associated with the user's user ID at that time.

[0071] Button B430 is used to switch to the editing screen for the pitcher development player lineup. Similar to the position players mentioned earlier, the pitcher development player lineup can also be edited. Area A440 displays the current team rank and overall team strength for the development player lineup. For example, the team rank and overall team strength are calculated based on the ability parameters of all development players included in the lineup. If the development player lineup is edited, area A440 displays the changes in team rank and overall team strength before and after the edit. When the user taps the confirm button B422, the edited development player lineup is finalized, and the user is redirected to the top screen G300 shown in Figure 4. Alternatively, to return to the top screen G300 without editing the current development player lineup, tap the back button B450.

[0072] As mentioned above, the player development lineup can be strengthened by replacing players owned by the user. For example, if a player with higher ability parameters is developed in development mode, the user can strengthen their team by editing the player development lineup.

[0073] (Regarding event character orders) The event character order consists of 25 event characters owned by the user (for example, 8 starting fielders, 8 reserve fielders, 3 starting pitchers, 5 relief pitchers, and 1 closer).

[0074] When the real-time battle mode is first played, each user is assigned a predetermined number of default event characters (for example, 27). A default event character order is also set. For example, when the real-time battle mode is first played, a tutorial on how to play the mode is executed, and during the user interaction in this tutorial, a predetermined number of event characters (for example, 27) are assigned to the user. These assigned event characters are common to all users. As a variation, the predetermined number of event characters granted to each user upon their first execution of the real-time battle mode may be determined by a lottery, similar to the lottery acquisition mode. In this case, the predetermined number of event characters that each user can acquire on their first attempt will differ.

[0075] Here, we will explain the event characters used in the game provided by Game System 1. Figure 8 shows an example of the character information table TBL102. The character information table TBL102 is the master data for managing all event characters used in the game provided by Game System 1. The character information table TBL102 stores the initial data of all event characters as reference parameters. For example, the character information table TBL102 is stored and managed in the respective storage devices of Server 30 and Game Terminal 10 (e.g., RAM 13, auxiliary storage device 14, RAM 33, auxiliary storage device 34, database DB, etc.). The character information table TBL102 stored in Server 30 and Game Terminal 10 is basically the same. For example, if the game operator changes the character information table TBL102 on Server 30, the changed information is distributed from Server 30 to Game Terminal 10 via Network N.

[0076] The character information table TBL102 includes fields such as "Original ID," "Profile ID," "Name," "Rarity," "Maximum Level," "Position," "Abilities," and "Event" for each event character.

[0077] The Original ID is identification information assigned to each event character (player name). The Profile ID is identification information assigned according to the rarity of the event character. Event characters with the same name will have the same Original ID. Event characters with the same name will have different Profile IDs if their rarities are different. For example, event characters with the same name but different rarities will only differ in the first digit of their Profile IDs. In the character information table TBL102, the Profile ID is the information that uniquely identifies an event character.

[0078] Event characters with the same name but different rarities have the same ability parameter values, but different maximum levels. Here, the maximum level is the upper limit of the event character's level. The initial level when a user obtains an event character is "Level 1". After obtaining it, the user can increase the event character's level up to the aforementioned maximum level through the enhancement process in the enhancement mode described above. The higher the rarity of the event character, the higher the maximum level is set, allowing the event character to reach a higher level. In addition, a limit break effect may be activated when certain conditions are met, which may increase the event character's maximum level.

[0079] Each event character, like the players being developed, has a defensive position and ability parameters. The ability parameters of event characters are the same as those of the players being developed (protagonist characters) as exemplified in Figure 3, and for fielders, they include basic abilities such as trajectory, contact, power, speed, arm strength, fielding ability, and catching, as well as special abilities. Similarly, for pitchers, the ability parameters of event characters are the same as those of the players being developed, including basic abilities such as ball speed, control, stamina, and breaking balls, as well as special abilities.

[0080] The abilities of event characters reflect their rarity and level. For example, if there are event characters with the same name but different rarities, the ability parameters will be adjusted so that the higher the rarity, the higher the ability value. Furthermore, for example, in the case of event characters with the same name but different rarities, the ability parameters are adjusted so that the higher the level, the higher the ability values. Therefore, by increasing the level of the event characters included in the event character order in enhancement mode, users can strengthen the team in the event character order.

[0081] The "Events" field in the character information table TBL102 stores information about events associated with event characters. This information in the "Events" field is used in training mode when an event character is set in the event deck. However, when an event character is used in modes other than training mode, such as real-time battle mode, the effect of triggering events associated with that event character does not occur, so the information in the "Events" field is not referenced.

[0082] Although not shown in Figure 8, other fields are also included in the character information table TBL102. For example, fields such as image information and initial evaluation of event characters are included in the character information table TBL102.

[0083] When the real-time battle mode is run for the first time, a default event character order is set. For example, when the real-time battle mode is run for the first time, a tutorial on how to play the mode is executed, and the default event character order is set during the user operation in this tutorial. For example, from all the training players associated with the user's user ID at that time (i.e., all event characters that the user already possesses through the lottery acquisition mode, etc., and a predetermined number of event characters given to the user during the initial execution as described above), the CPU 11 of game system 1 automatically selects the event characters it deems optimal, and the default event character order is automatically set.

[0084] The top screen G300 of the real-time battle mode in Figure 4 includes an event character order editing button B302 for editing the event character order. When the user taps the event character order editing button B302, an event character order editing screen similar to the aforementioned player training order editing screen G400 (see Figure 5) is displayed. On this event character order editing screen, the event character order can be edited in the same way as the aforementioned player training order. That is, if the user selects the "Auto" button, the game system 1 will automatically assemble the optimal order for the user's event character team. For example, the event character with the highest overall player strength (ability) in each position will be automatically selected from all event characters associated with the user's user ID at that time. It is also possible for the user to manually change the members of the event character order.

[0085] In this way, the event character order can be strengthened by swapping in event characters owned by the user. For example, if a user acquires an event character with higher ability parameters in the lottery acquisition mode, or improves the level of an event character in the enhancement mode, they can strengthen their team by editing the event character order.

[0086] Please note that players included in the training player order and event characters included in the event character order will be locked so that they cannot be sold or used as enhancement materials.

[0087] Furthermore, the top screen G300 of the real-time battle mode in Figure 4 includes a search settings button B303 for setting game conditions (matching search conditions) equivalent to the rules of a real-time battle and searching for a matching opponent. When the user taps the search settings button B303, the user is taken to the search settings screen G500, as illustrated in Figure 6.

[0088] The search settings screen G500 in Figure 6 includes a usage order condition setting area A510 for setting conditions regarding the team order used in real-time battle mode. This usage order condition setting area A510 includes options P511 to P513. Option P512 is for setting the game condition to use the aforementioned training player order. Option P513 is for setting the game condition to use the aforementioned event character order. The "Auto" option P511 is for setting the game condition that either the training player order or the event character order can be used for the battle. In other words, the "Auto" option P511 is for delegating the selection of the battle order to the game system 1.

[0089] Users can set their order conditions by tapping one of the options P511 to P513. Figure 6 shows an example where option P511, "Leave it to us," is selected. Alternatively, you could set one of the options P511 to P513 as the default setting. For example, to increase the chances of finding a match in the game, you could set option P511, "Random Matching," as the default setting.

[0090] The search settings screen G500 in Figure 6 includes an inning count condition setting area A520 where the user can set conditions regarding the number of innings in a real-time battle mode match. This inning count condition setting area A520 includes options P521 to P524. Option P522 is for setting the game condition to "up to the bottom of the 3rd inning". Option P523 is for setting the game condition to "up to the bottom of the 6th inning". Option P524 is for setting the game condition to "up to the bottom of the 9th inning". The "Automatic" option P521 is for setting the game condition to "up to the bottom of the 3rd inning", "up to the bottom of the 6th inning", or "up to the bottom of the 9th inning". In other words, the "Automatic" option P521 is for delegating the number of innings in a match to game system 1.

[0091] Users can set the inning count condition by tapping one of the options P521 to P524. Figure 6 shows an example where option P522, "Up to the bottom of the 3rd inning," is selected. Alternatively, you could set one of the options P521 to P524 as the default setting. For example, to increase the chances of finding a match in the game, you could set the "Random Matching" option P521 as the default setting.

[0092] When the user taps the confirmation button B530, the game conditions for searching for a match (in this embodiment, the order conditions and inning count conditions mentioned above) are confirmed, and the user transitions to the top screen G300 in Figure 4. To check the current game conditions and return to the top screen G300, the user taps the back button B540.

[0093] The top screen G300 in Figure 4 includes a matching button B304 for making a matching request. When the matching button B304 is tapped, a matching request with the aforementioned conditions is sent from the user's game terminal 10 to the server 30.

[0094] Here, we will describe an example of matching processing on server 30. Figure 9 shows a data structure including a queue and buffer, and is a diagram illustrating an example of matching processing using the queue and buffer. To simplify the explanation, we will describe an example of matching processing targeting each user's matching request, which includes the game condition of "up to the bottom of the 3rd inning".

[0095] The queue QU3 shown in Figure 9 is a queue for executing queuing using data from each user's matching request, which includes the game condition "up to the bottom of the 3rd inning". When the server 30 receives a matching request with the game condition set from each user's game terminal 10, it enqueues the matching requests in queue QU3 in the order they were received. Each matching request includes the user ID of the user who made the matching request.

[0096] In Figure 9, matching requests are indicated by a serial number + [Order Condition] which shows the order of enqueue. Here, [A] in [Order Condition] is the condition to use an event character order, [B] is the condition to use a training player order, and [all] is the "random" condition which means either an event character order or a training player order is acceptable. For example, Matching Request 1 [A] is the first matching request enqueued in queue QU3, with the condition to use an event character order. Matching Request Data 2 [all] is the second matching request enqueued in queue QU3, with the "random" condition which means either an event character order or a training player order is acceptable. Matching Request 3 [B] is the third matching request enqueued in queue QU3, with the condition to use a training player order.

[0097] Here, we will continue our explanation assuming that, as shown in (A) in Figure 9, five matching requests 1[A], 2[all], 3[B], 4[A], and 5[all] are enqueued in this order in queue QU3.

[0098] Buffer BU[A] has an area for temporarily storing matching requests dequeued from queue QU3 with the condition setting of using an event character order. Buffer BU[B] has an area for temporarily storing matching requests dequeued from queue QU3 with the condition setting of using a training player order. Buffer BU[all] has an area for temporarily storing matching requests dequeued from queue QU3 with the condition setting of "random," which allows either an event character order or a training player order.

[0099] In Figure 9 (A), the processing of matching request 1[A] dequeued from queue QU3 is as follows: For the dequeued matching request 1[A], matching requests stored in buffer BU[A] and buffer BU[all] are the targets for matching. Server 30 checks whether a matching request is stored in either the target buffer BU[A] or buffer BU[all]. The order of checking in this case is, for example, random. Alternatively, a priority order may be set in advance to prioritize checking either buffer BU[A] or buffer BU[all]. In the case of Figure 9 (A), since no matching request is stored in either the target buffer BU[A] or buffer BU[all], as shown in Figure 9 (B), matching request 1[A] is temporarily stored in buffer BU[A] and waits for a match to be established with any matching requests dequeued thereafter.

[0100] Next, in (B) in Figure 9, the processing for matching request 2[all] dequeued from queue QU3 is as follows: For the dequeued matching request 2[all], all matching requests stored in buffers BU[A], BU[B], and BU[all] are subject to matching. Server 30 checks whether a matching request is stored in any of the target buffers BU[A], BU[B], or BU[all]. The order of checking in this case is, for example, random. Note that a priority order for checking each buffer may be set in advance. Alternatively, for example, every predetermined period (for example, 24 hours), the number of matching requests with the condition of using a training player order and the number of matching requests with the condition of using an event character order may be counted, and the buffer storing the matching requests with fewer matching requests may be checked (searched) with priority over the buffer storing the matching requests with more matching requests.

[0101] In the case of (B) in Figure 9, since Matching Request 1[A] is stored in Buffer BU[A], Server 30 matches the user of Matching Request 1[A] with the user of Matching Request 2[all], as shown in (C) in Figure 9.

[0102] Next, in Figure 9 (C), the processing of the matching request 3[B] dequeued from queue QU3 is as follows: For the dequeued matching request 3[B], the matching requests stored in buffer BU[B] and buffer BU[all] are the targets for matching. Server 30 checks whether a matching request is stored in either the target buffer BU[B] or buffer BU[all]. The order of checking in this case is, for example, random. Alternatively, a priority order may be set in advance to prioritize checking either buffer BU[B] or buffer BU[all]. In the case of Figure 9 (C), since no matching request is stored in either the target buffer BU[B] or buffer BU[all], as shown in Figure 9 (D), matching request 3[B] is temporarily stored in buffer BU[B] and waits for a match to be established with any subsequent matching requests that are dequeued.

[0103] Next, in Figure 9 (D), the processing of the matching request 4[A] dequeued from queue QU3 is as follows: For the dequeued matching request 4[A], the matching requests stored in buffer BU[A] and buffer BU[all] are the targets of the matching. In the case of Figure 9 (D), since no matching requests are stored in either the target buffer BU[A] or buffer BU[all], the matching request 4[A] is temporarily stored in buffer BU[A], as shown in Figure 9 (E).

[0104] Next, in (E) in Figure 9, the processing for matching request 5[all] dequeued from queue QU3 is as follows. For the dequeued matching request 5[all], all matching requests stored in buffers BU[A], BU[B], and BU[all] are subject to matching. In the case of (E) in Figure 9, matching request 4[A] is stored in buffer BU[A] and matching request 3[B] is stored in buffer BU[B], so if the checking order is random, there is a possibility that matching request 5[all] will be matched with either of these. For example, if buffer BU[A] is checked (searched) first, server 30 will match the user of matching request 4[A] with the user of matching request 5[all]. On the other hand, if buffer BU[B] is checked (searched) first, as shown in (F) in Figure 9, server 30 will match the user of matching request 3[B] with the user of matching request 5[all].

[0105] The matching process described above is just one example and is not limited to it; various matching processes using existing algorithms can be applied.

[0106] Furthermore, when matching users who have set both the order of play and the number of innings to "automatic," the order of play and the number of innings may be determined randomly, or they may be determined according to a pre-set priority.

[0107] Furthermore, while the above matching process does not currently prioritize matching users with similar game levels or team ranks, such matching priorities may be implemented. For example, users whose total number of real-time matches, cumulative win rate, or recent win rate (e.g., win rate over the last 10 matches, win rate over the last week) falls within a predetermined range may be prioritized for matching. Alternatively, users whose team rank in CPU battle mode (i.e., other game modes) falls within a predetermined range may be prioritized for matching.

[0108] Server 30 transmits matching information to the game terminals of both users who have successfully matched. The matching information includes information on the game conditions under which the match was successful and information on the opponent. In this embodiment, the information on the game conditions under which the match was successful includes the order of players to be used and the number of innings to be played. The information on the opponent includes the opponent's username, the order of players to be used corresponding to the game conditions under which the match was successful, the leader character, the communication strength, and whether the player is going first or second. The leader character and communication strength will be described later.

[0109] The display unit 17 of the game terminal 10 of the user (usernamed User A) who has received matching information from server 30 displays the pre-match confirmation screen G600 as exemplified in Figure 7. In Figure 7, it is assumed that server 30 has matched the user with the opponent user (usernamed User B), and that the user will go first and the opponent will go second.

[0110] The pre-match confirmation screen G600 displays information about the user and the opponent. User information includes the username P611, the leader character image P612, and communication strength information P613. Here, the leader character is a specific character arbitrarily set by the user from among the event characters they own. For example, a predetermined character within the user's team, such as the cleanup hitter or starting pitcher in the lineup, may be automatically set as the leader character.

[0111] The communication strength information P613 visualizes the radio wave strength of the wireless communication of the user's game terminal 10 (for example, the radio wave strength between the user and a mobile communication base station, or the radio wave strength between the user and a wireless network access point or router). In this embodiment, an example is shown in which antenna icons that visualize the radio wave strength in multiple stages (for example, 5 stages) are displayed as the communication strength information P613. The communication strength information P613 may also be displayed using numbers, symbols, or characters (for example, weak, weak, normal, strong, strongest). For example, the value of the received signal strength indicator (RSSI) measured in a game terminal 10 with wireless communication capabilities, such as a smartphone, can be applied as the communication strength information P613.

[0112] Additionally, the information about the opponent displayed on the pre-match confirmation screen G600 includes the opponent's username P621, an image of their leader character P622, and communication strength information P623.

[0113] For example, when each user sends a matching request from their game terminal 10, the server 30 sends the matching request along with information about the current communication strength. Then, when the server 30 sends matching information to both users after a successful match, it may include information about the communication strength of both users (at least the communication strength of the other user) in the matching information.

[0114] Alternatively, the game terminals 10 of both users, having received matching information from the server 30, can communicate directly via P2P connection or the like, exchanging information on each other's communication strength in real time at regular intervals, so that the opponent's communication strength information P623 is displayed on the pre-match confirmation screen G600. For example, the game terminals 10 of both matched users measure their own communication strength at regular intervals (for example, every frame: 1 / 60th of a second) and send the measured communication strength information to each other. As a result, the communication strength information P613 of the user's own game terminal 10 and the communication strength information P623 of the opponent's game terminal 10 are updated at regular intervals on the pre-match confirmation screen G600.

[0115] Alternatively, data exchange between the two matched users' game terminals 10 can be conducted via the server 30, and information on each other's communication strength can be exchanged via the server 30 at regular intervals in real time. In this case as well, similar to the direct communication via P2P connection described above, the communication strength information P613 of the user's own game terminal 10 and the communication strength information P623 of the opponent's game terminal 10 are updated at regular intervals on the pre-match confirmation screen G600.

[0116] The user can check the communication strength information P613 of their own game terminal 10 or the communication strength information P623 of their opponent's game terminal 10, which is displayed on the pre-match confirmation screen G600, and decide whether or not to start a match with the matched opponent.

[0117] In addition to the information mentioned above, the user and opponent information displayed on the G600 pre-match confirmation screen may also include other information such as the user's and opponent's game levels, team rank, total number of real-time matches played, cumulative win rate, or recent win rate.

[0118] Furthermore, the pre-match confirmation screen G600 displays information P631 regarding the game conditions for which the match was made (in the example in Figure 7, the use of event character orders and the number of innings being up to the bottom of the 3rd inning). The pre-match confirmation screen G600 also displays the match start button B632 and a gauge B633 that visualizes the time limit. If each user does not tap the match start button B632 within the time limit after the match is made (for example, after the pre-match confirmation screen G600 is displayed), the match with the matched opponent will be automatically canceled. Even within the time limit, if the user taps the back button B640, the match will be canceled and the user will return to the real-time match top screen G300 in Figure 4. If both matched users tap the match start button B632 within the time limit, the match with the game conditions for which the match was made will begin. In this match, both users will use the orders corresponding to the game conditions for which the match was made. In the example in Figure 7, the match with the game condition of using event character orders has been made, so a match using event character orders will be executed.

[0119] Once the match ends, the match results are displayed on the display unit 17. Both users are also awarded rewards such as points and items based on the match results. A league ranking reflecting the awarded points may also be displayed. After a match, users can save the match as a replay by performing a predetermined operation. There is a limit to the number of replays that can be saved; if the limit is exceeded, the oldest replay will be deleted.

[0120] Once the reward has been received and operations such as saving the replay have been completed, the game transitions to the top screen G300 of the real-time battle shown in Figure 4. The top screen G300 includes a battle record check button B305, a replay button B306, and a back button B307. When the user taps the battle record check button B305, the game transitions to a screen displaying the battle record of the real-time battle to date. When the user taps the replay button B306, the game transitions to a screen displaying a list of playable replays. When the user selects a replay from the list, the selected replay is played. When the user taps the back button B307, the game transitions to the home screen where various game modes can be selected.

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

[0122] As a concrete example of the data stored in the data storage unit 100, we will now describe the data necessary to provide the baseball game described above. The data storage unit 100 stores user information table TBL101, character information table TBL102, game condition table TBL103, team order table TBL104, owned character data DT105, team order data DT106, etc. Note that the character information table TBL102 (see Figure 8) has already been explained, so its explanation will be omitted here.

[0123] For example, various data for running the game stored in the data storage unit 100 can be stored in a database DB or the auxiliary storage device 34 of the server 30, and when the game terminal 10 accesses the server 30, the necessary data can be downloaded to the RAM 13 or auxiliary storage device 14 of the game terminal 10. In addition, information about the results of the game run on the game terminal 10 and changes in data can be transmitted from the game terminal 10 to the server 30 in real time or at a predetermined time, and the data stored in the database DB or the auxiliary storage device 34 of the server 30 can be updated as appropriate. Furthermore, for example, at least a portion of the game can be run offline on each user's game terminal 10 without logging into the server 30, by storing the necessary data in the auxiliary storage device 14 of the game terminal 10.

[0124] Figure 11 shows an example of a user information table TBL101. In the example in Figure 11, the user information table TBL101 stores user information for one user with user ID "U1". However, a user information table TBL101 covering all users registered in the game system 1 is stored in the data storage unit 100 of the game system 1 (for example, a database DB or auxiliary storage device 34). In addition, the storage device of the user's game terminal 10 (for example, auxiliary storage device 14) stores user information associated with that user's user ID.

[0125] The user information table TBL101 includes fields such as "User ID," "User Name," "Training Mode," "CPU Battle Mode," and "Real-Time Battle Mode." The "User ID" is identification information to uniquely identify each user. The "User Name" field shows the user's name. The "Training Mode," "CPU Battle Mode," and "Real-Time Battle Mode" fields store various information related to each game mode. For example, the "Training Mode" field stores information such as the main character currently being trained, event deck information (such as the ID of the event character set in the event deck), and the current turn. For example, the "CPU Battle Mode" field stores information such as the current league level, cumulative points, and league ranking. For example, the "Real-Time Battle Mode" field stores information such as the currently saved matchmaking conditions, battle record, and replay information.

[0126] Regarding information on matching conditions, for example, the matching conditions applied in the previous match may be saved, and the conditions from the previous match may be applied in the next match unless the user changes the conditions. Alternatively, default conditions (for example, "automatic" for the order of players and "automatic" for the number of innings) may be applied each time a match is made, and the user may change the conditions as needed.

[0127] Although not shown in Figure 11, other fields are also included in the user information table TBL101. For example, fields for various in-game points owned by the user, and the user IDs of other users (companions, friends, etc.) associated with the user's user ID are included in the user information table TBL101.

[0128] Figure 12 shows an example of a game conditions table TBL103. This game conditions table TBL103 is a master table for game conditions during matching. The game conditions table TBL103 includes the fields "Condition Type," "Game Condition ID," and "Game Condition." In the baseball game example mentioned above, the "Condition Type" field is set to "Order Used" and "Number of Innings." The "Game Condition ID" is identification information to uniquely identify each game condition. The "Game Condition" field stores information about the game condition.

[0129] Figure 13 shows an example of a team order table TBL104. This team order table TBL104 is the master table for team orders that can be set in this game. The team order table TBL104 includes the fields "Order ID", "Team Order Name", "Corresponding Game Conditions", and "Corresponding League". "Order ID" is identification information to uniquely identify each team order. The "Team Order Name" field stores information about the team order name. The "Corresponding Game Conditions" field stores information about the matching game conditions (e.g., Game Condition ID) associated with the team order. The "Corresponding League" field associates the in-game league associated with the team order.

[0130] Figure 14 shows an example of owned character data DT105. This owned character data DT105 is data that shows information about the characters owned by the user (i.e., characters associated with the user's user ID). In the example in Figure 14, owned character data DT105 is shown that stores information for one person associated with user ID "U1", but owned character data DT105 for all users registered in the game system 1 is stored in the data storage unit 100.

[0131] In the owned character data DT105, event characters and trained players are managed separately. The owned character data DT105 includes fields such as "Character ID," "Profile ID," "Ability Parameters," and "Level." The "Character ID" is identification information that uniquely identifies the character owned by the user. For example, a user may acquire multiple event characters of the same name and rarity through a lottery or other means. In this case, although the profile IDs of these multiple event characters are all the same, each is assigned a different character ID and associated with the user ID. The "Parameters" field stores information on various parameters such as the ability parameters of each character. Parameters that change after acquiring a character are also reflected in the "Parameters" field.

[0132] Figure 15 shows an example of team order data DT106. Team order data DT106 is data for multiple team orders set in this game. In the baseball game example mentioned above, it includes event character order (order ID: OD1) and training player order (order ID: OD2). User team data DT106 is stored for each user (associated with the user ID). User team data DT106 includes the character IDs of pitcher members (starting pitcher, relief pitcher, closer) and fielder members (starting members and reserves). User team data DT106 also includes information on positions and batting order within the team, which are set based on user operations (or automatically set by game system 1).

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

[0134] The control unit 110 includes a registration unit 111 (an example of registration means), a condition setting unit 112 (an example of condition setting means), a matching unit 113 (an example of matching means), and a game execution unit 114 (an example of game execution means). For example, the registration unit 111, the condition setting unit 112, and the game execution unit 114 may be implemented by the CPU 11 of the game terminal 10, and the matching unit 113 may be implemented by the CPU 31 of the server 30.

[0135] The registration unit 111 has the function of registering multiple usage targets, each containing at least one object, based on user operations.

[0136] Here, the term "user" refers, for example, to a person who operates the game terminal 10 to play a game. For example, user identification information (user ID) is set for each user or for each game terminal 10 operated by each user, and each user is identified (specified) by the user identification information.

[0137] Furthermore, the term "object" refers to anything that can be used in a game. For example, game characters, game cards (digital cards), or game items are examples of "objects." For example, game characters or game cards representing people such as athletes, living things such as racehorses, anthropomorphic representations of living things such as racehorses, fictional characters or creatures such as monsters, or non-living things such as robots, cars, motorcycles, and bicycles are examples of "objects." Also, for example, equipment items that are fitted to characters are examples of "objects." For example, an "object" may be a game character or game card that corresponds to a real person or living thing, or it may not correspond to a real person or thing.

[0138] Furthermore, the aforementioned "target for use" refers to an object that may be used by a user in a game executed through matching, and includes at least one object. The games played through matchmaking may be, for example, competitive games where users "compete" against each other, or multiplayer games (also called multiplayer games) that allow for "cooperative play" by multiple users.

[0139] Here, "competitive game" refers to a computer game in which a user competes against an opponent to determine superiority or victory. For example, an online competitive game played between multiple user game terminals 10 connected via a network is an example of a "competitive game." Here, "competition" means determining superiority, victory or defeat, ranking, etc., with an opponent. The result of a competitive game does not necessarily have to be a winner or loser; it may end in a draw. Examples of "competition" include matches in sports games, races such as horse racing, car racing, motorcycle racing, and bicycle racing, and battles in fighting games.

[0140] A user's opponent may be one user or two or more users. The match may be one-on-one, one-on-many, or many-on-many. For example, the aforementioned baseball game in which two users each use multiple player characters from their own baseball team to play a game is an example of a "versus game." Also, for example, a game in which three or more users each use their own objects to battle in the same game space is an example of a "versus game." For example, in a horse racing game, a game in which multiple users enter their own racehorse characters up to a predetermined number and compete for ranking is an example of a "versus game."

[0141] Regarding the aforementioned "objects of use," for example, in a game where a user uses a single object to compete against an opponent, that single object is an example of an "object of use." For example, the player character used in a home run derby in a baseball game is an example of an "object of use." Also, in a horse racing game, the racehorse character used in the race, the anthropomorphic racehorse character, or the jockey character riding the racehorse are examples of "objects of use." Furthermore, in a car racing game, the racing car character used in the race or the driver character riding the racing car are examples of "objects of use."

[0142] Furthermore, for example, in the case of a game in which a user plays against an opponent using two or more objects, the two or more objects or a group containing those two or more objects (deck, team, group, squad, party, guild, etc.) would be an example of a "target for use." A "target for use" may be a group such as a deck or team composed of a predetermined number of objects, a group composed of up to a predetermined number of objects (which the user can arbitrarily set between 1 and a predetermined number), a group composed of more than a predetermined number of objects, or a group composed of n or more objects and up to m or less objects (where n and m are any natural numbers greater than or equal to 1). For example, in the aforementioned baseball game, a team composed of a predetermined number of player characters (e.g., 25 players) (development players or event characters) is an example of an "target for use." Similarly, a team order containing information on the batting order and defensive positions of a predetermined number of player characters is also an example of an "target for use." Furthermore, in the case of horse racing or car racing, a deck composed of a predetermined number of racehorse characters or racing car characters (e.g., no more than 3) participating in the race is an example of an "target for use."

[0143] Regarding the "user operation" in the registration unit 111, the user can perform operations to register multiple targets at any time before making a matching request. For example, in the training player order editing screen G400 illustrated in Figure 5, operating the automatic button B421 to automatically register a training player order as a target is also an example of a "user operation." Furthermore, once a target is registered, the information is saved, and the same registration information for the target may be repeatedly applied in multiple matches until the user changes (edits) the target.

[0144] In the aforementioned baseball game example, the registration unit 111 registers a training player order (an example of the target of use) consisting of a predetermined number (e.g., 25) training players, and an event character order (an example of the target of use) consisting of a predetermined number (e.g., 25) event characters, by storing them in a storage device (e.g., auxiliary storage device 14, auxiliary storage device 34, database DB, etc.) based on the user's operation. The number of targets of use registered by the registration unit 111 may be 3 or more.

[0145] The multiple usage targets registered by the registration unit 111 each correspond to the game conditions used for matching. For example, as shown in Figure 13, the event character order (order ID: OD1) is associated with the event character order usage conditions (game condition ID: GA1). Similarly, the training player order (order ID: OD2) is associated with the training player order usage conditions (game condition ID: GA2).

[0146] The condition setting unit 112 has a function that allows the user to set conditions such that any two or more of the multiple game conditions corresponding to each of the multiple targets for use are acceptable, based on the user's operation. In the baseball game example described above, the condition setting unit 112 allows the user to set an "automatic" condition such that any of the two game conditions (using the event character order, using the training player order) corresponding to the two targets for use, the event character order and the training player order, are acceptable, as shown in Figure 6.

[0147] Here, the aforementioned "game conditions" are the conditions related to the game that will be played through the matching process, which a user can set when searching for a matching partner. These "game conditions" may also be referred to as "matching conditions" or "search conditions," etc. For example, if there are multiple leagues that a user can participate in, the user may be able to set each league they wish to participate in as a "game condition." For example, if two leagues are set, the user may be able to set only one or both of them as a "game condition." Similarly, if three leagues are set, the user may be able to set only one, two of them, or all three of them as a "game condition." The same applies if four or more leagues are set. The same also applies to game conditions other than leagues. For example, if multiple decks corresponding to multiple leagues are pre-registered, users could be allowed to set each deck they wish to use as a "game condition."

[0148] As described above, the condition setting unit 112 can also set conditions by specifying one of the multiple game conditions corresponding to each of the multiple target users, based on user operation.

[0149] In addition to the above, various other conditions can be set in "Game Conditions." For example, in a baseball game, the number of innings in the game (e.g., up to the bottom of the 3rd inning, up to the bottom of the 6th inning, up to the bottom of the 9th inning, etc.), weather (e.g., sunny, cloudy, rainy, snowy, etc.), season (e.g., spring, summer, autumn, winter), stadium (e.g., one or more virtual stadiums corresponding to the stadiums of each professional baseball team in Japan can be selected), user level, team rank, player character parameters (e.g., ability rank), etc. can be set as "Game Conditions" to allow users to find opponents for matching. Additionally, each of the scenarios applied to the aforementioned training (either just one of several scenarios, or two or more) may be set as a "game condition." Furthermore, in games based on real sports, for example, objects corresponding to real players (e.g., player characters, digital cards) are used in the game. In such cases, even if the objects have the same player name, their ability parameters may differ depending on when the user obtained them through a lottery (so-called gacha). For example, player character A from the "2021 Series" and player character A from the "2022 Series" have the same player name, but their ability parameter values ​​are different. Therefore, it may be possible to set differences in the acquisition timing of objects associated with other objects (or the timing of the gacha, the series name indicating the acquisition timing, etc.) as "game conditions." Furthermore, even for objects with the same player name corresponding to real-life players, the values ​​of the ability parameters may differ depending on the object type. For example, object type A may reflect the real-life player's performance in the current season in its ability parameters, object type B may reflect the real-life player's performance during a period when they were in the spotlight in the past in its ability parameters, and object type C may reflect the real-life player's best moment in their career in its ability parameters. Therefore, the differences in the "object type" associated with an object may be set as "game conditions". Furthermore, for example, in a lottery acquisition mode, multiple gacha of different types may be provided so that the types of objects that the user can obtain (or that are easier to obtain) differ depending on the type of gacha executed. Examples of different gacha types include a gacha that can be executed by consuming items or points that are subject to payment, a gacha that can be executed by consuming items or points that are not subject to payment, a gacha that only includes specific types of objects in the draw, a gacha that excludes specific types of objects from the draw, and a gacha that increases (or decreases) the probability of drawing specific types of objects. Therefore, the differences in the "type of gacha" associated with an object (in other words, variations in the routes to obtain the object) may be set as "game conditions". In addition, for horse racing games, the following can be set as "game conditions" to allow users to find opponents to match with: race name (for example, multiple race names corresponding to multiple real-world race names), track surface (for example, turf, dirt), distance (for example, sprint, mile, middle distance, long distance, or a specific numerical distance such as 1200m, 1600m), venue (for example, multiple virtual venues in the game corresponding to multiple real-world racecourses), course characteristics (for example, right-handed, left-handed, straight, inner, outer, outer on the first lap and inner on the second, no inner or outer course), track condition (for example, good, slightly heavy, heavy, poor, etc.), weather (for example, sunny, cloudy, rainy, snowy, etc.), season (for example, spring, summer, autumn, winter), user level, team rank, and parameters of racehorse characters (for example, ability rank).

[0150] Furthermore, the phrase "multiple game conditions corresponding to each of the multiple aforementioned usage targets" means that multiple usage targets (for example, team orders, decks, etc.) corresponding to each of the multiple game conditions are registered.

[0151] Furthermore, the aforementioned "setting of conditions that allows any two or more of the multiple game conditions" includes both "setting of conditions that allow any of the multiple game conditions" and "setting of conditions that allows any of a part (two or more) of the multiple game conditions." For example, if there are two game conditions corresponding to two registered users, setting a condition that allows either game condition to be used is an example of "setting a condition that allows any two or more of multiple game conditions to be used." Furthermore, for example, if there are three game conditions corresponding to three registered users, both "setting the condition so that any of the three game conditions are acceptable" and "setting the condition so that the user can select any two of the three game conditions and either of those two is acceptable" are examples of "setting the condition so that any two or more of the multiple game conditions are acceptable." The same applies if there are four or more registered users, each corresponding to four or more game conditions.

[0152] The following are some embodiments that enable the setting of the above conditions. In addition to the options for selecting multiple game conditions, specific options such as "Leave it to us," "Any of them," "No preference," or "Random" may be provided, allowing users to select one of these options to "set conditions that allow any of the multiple game conditions." One example of this is setting the order conditions by selecting the "Leave it to us" option P511 on the search settings screen G500 in Figure 6 mentioned above.

[0153] Furthermore, by allowing users to simultaneously select multiple matching condition options, it may be possible to set conditions that allow any of the multiple matching conditions to be selected, or conditions that allow any of the (two or more) game conditions to be selected. An example of this is shown in Figure 16. The search setting screen G700 in Figure 16 is a modified version of the search setting screen G500 in Figure 6, and components with the same function are assigned the same component number. The search setting screen G700 includes a league participation condition setting area A710, an innings count condition setting area A720, and a weather condition setting area A730. The league participation condition setting area A710 includes an option P711 to participate in the event character league and an option 712 to participate in the training player league. The user may select either option P711 or P712, or may select both options P711 and P712 simultaneously, as in the example in Figure 16. If both are selected, it has the same meaning as selecting the "random" option as exemplified in Figure 6. The inning count condition setting area A720 includes three game condition options P721 to P723. As shown in the example in Figure 16, selecting options 721 and P722 allows you to set a condition where any of the two of the three game conditions related to the number of innings is acceptable. The weather condition setting area A730 includes the option for sunny weather P731 and the option for rainy weather 732. As shown in the example in Figure 16, you may select only one option.

[0154] Figure 17 shows an example of a team order table TBL204 corresponding to the example in Figure 16. Figure 17 shows an example where a total of six team orders can be registered: three event character orders and three training player orders. "Event Character Order 1 (Order ID: OD11)" is associated with the combined conditions of "Event Character League Participation (Game Condition ID: GC1)" and "Innings up to the bottom of the 3rd inning (Game Condition ID: GB1)". "Event Character Order 2 (Order ID: OD12)" is associated with the combined conditions of "Event Character League Participation (Game Condition ID: GC1)" and "Innings up to the bottom of the 6th inning (Game Condition ID: GB2)". "Event Character Order 3 (Order ID: OD13)" is associated with the combined conditions of "Event Character League Participation (Game Condition ID: GC1)" and "Innings up to the bottom of the 9th inning (Game Condition ID: GB3)". In this way, it is possible to register multiple items of the same type (team order, deck, etc.) composed of the same type of object (in this case, event characters). "Developmental Player Order 1 (Order ID: OD21)" is associated with the combined conditions of "Developmental Player League Participation (Game Condition ID: GC2)" and "Innings up to the bottom of the 3rd inning (Game Condition ID: GB1)". "Developmental Player Order 2 (Order ID: OD22)" is associated with the combined conditions of "Developmental Player League Participation (Game Condition ID: GC2)" and "Innings up to the bottom of the 6th inning (Game Condition ID: GB2)". "Developmental Player Order 3 (Order ID: OD23)" is associated with the combined conditions of "Developmental Player League Participation (Game Condition ID: GC2)" and "Innings up to the bottom of the 9th inning (Game Condition ID: GB3)". The above example shows a compound condition containing two game conditions, but a compound condition containing three or more game conditions is also acceptable.

[0155] In the example in Figure 17, the three event character orders 1-3 are each associated with the aforementioned combined conditions, but they may also be associated with individual game conditions. For example, in a versus mode where only the event character league is available (there is no training player league), "Training Player Order 1" may be associated with the individual game condition "up to the bottom of the 3rd inning," "Training Player Order 2" with the individual game condition "up to the bottom of the 6th inning," and "Training Player Order 3" with the individual game condition "up to the bottom of the 9th inning." As the number of innings in a game increases, the stamina abilities of each player, as well as the roles of relief pitchers, closers, and pinch hitters (reserves), become more important, so it may be possible to register multiple team orders according to the number of innings in a game.

[0156] The matching unit 113 has the function of matching a user with a play partner based on a matching request accompanied by the condition setting (including the condition setting that any two or more of the multiple game conditions corresponding to each of the multiple users may be used). As described above, the matching process by the matching unit 113 can be performed using various existing algorithms. Here, "playing partner" refers to other users (or other users' game terminals 10) who play with the user in a game executed through matchmaking. In the case of a competitive game, other users of the opposing team are an example of "playing partners." There may be more than one "playing partner."

[0157] The game execution unit 114 has the function of executing a game using the target object corresponding to the game conditions for which the matching has been established. In the aforementioned baseball game example, which allows registration of two team orders as illustrated in Figure 13, the game execution unit 114 executes a match using the event character order corresponding to the game condition, for example, when a match is made under the game condition "Use event character order" (any of the inning count conditions in Figure 6 is acceptable). The same game conditions are also applied to the opponent's game terminal 10, and the event character order registered by the opponent user is used in the match against the user. The same applies when a match is made under the game condition "Use training order" (any of the inning count conditions is acceptable).

[0158] Furthermore, in the aforementioned baseball game example where six team orders can be registered as illustrated in Figure 17, the game execution unit 114 executes a match using "Event Character Order 1" corresponding to the game conditions if a match is made with the game conditions "Use Event Character Order" and "Number of innings up to the bottom of the 3rd inning" (any of the weather conditions in Figure 16 is acceptable). Similarly, if a match is made with other game conditions stored in the "Corresponding Game Conditions" field in Figure 17 (any of the weather conditions in this example is acceptable), a match is executed using the team order corresponding to the matched game conditions.

[0159] In the example in Figure 6, the game condition of the number of innings can be included in the matching condition setting, but it is not associated with the event character order or the training player order (see Figure 13). Similarly, in the example in Figure 16, the game condition of the weather can be included in the matching condition setting, but it is not associated with the event character order or the training player order (see Figure 17). As in these examples, the condition setting unit 112 may allow other game conditions different from the game conditions corresponding to the target of use to be included in the condition setting.

[0160] The "game using the object" executed by the game execution unit 114 may be, for example, a game in which the user and the opponent each manipulate the object of the object themselves. Alternatively, the "game using the object" may be a game in which, for example, the computer (CPU 11 or CPU 31) performs simulation processing based on the user's object of the object and the opponent's object of the object to automatically determine the progress of the game, such as a match, and the user and the opponent manipulate their own object of the object only in specific situations. For example, in a baseball game, the game basically progresses in an automatic progression part, and only an overview of the game progress (points of the game) is displayed on the screen. Then, only when the game situation reaches a predetermined state (for example, a situation where there is a runner on third or second base) in the automatic progression part, the game switches from the automatic progression part to an action part, and the user and the opponent perform actions on the player characters.

[0161] Furthermore, the aforementioned "game using the target object" may be, for example, a game in which the computer automatically determines the outcome of a match by performing a simulation process based on the user's target object and the opponent's target object. For example, in a horse racing game, the user's target racehorse character(s) and the opponent's (multiple) target racehorse character(s) participate in a race under game conditions for which a match has been made, and the computer automatically determines the progress of the race and the results such as the order of finish based on the parameters of each racehorse character. In this case, the user may be able to set a strategy (e.g., leading, front-running, sprinting, closing, etc.) for each target racehorse character before the race.

[0162] Furthermore, this game may include multiple in-game leagues that users can participate in. In the baseball game example mentioned earlier, there are "development player leagues" and "event character leagues." Here, the aforementioned "in-game league" refers to a league virtually established within the game where users can compete against each other in games such as matches and races. Multiple in-game leagues are available, and users can participate in any league they choose. An "in-game league" may also refer to multiple "stages" within the game that users can choose to participate in.

[0163] Furthermore, the registration unit 111 has the function of registering multiple users corresponding to multiple in-game leagues based on user operations. In the baseball game example described above, the registration unit 111 stores and registers "training player orders" and "event character orders" corresponding to the "training player league" and "event character league," respectively, in the storage device based on user operations.

[0164] As described above, multiple targets can be associated with each of multiple game conditions. Therefore, when the "automatic" condition setting is used for matching, the target corresponding to the matched game conditions is used, and a game is executed in which the target participates in the in-game league corresponding to that target.

[0165] Furthermore, the game conditions may include "the in-game league that the user wishes to participate in" or "the target of use that corresponds to the in-game league that the user wishes to use." In the aforementioned baseball game example, the game conditions for the participating league (event character league or training player league) in Figure 16 correspond to an example of the game conditions for "the in-game league that the user wants to participate in." Similarly, the game conditions for the order of players used (event character order or training player order) in Figure 6 correspond to an example of the game conditions for "the target players that the user wants to use, corresponding to the in-game league."

[0166] Furthermore, the condition setting unit 112 may enable the setting of conditions that allow any two or more of the multiple in-game leagues to be used, or that allow any two or more of the multiple targets corresponding to each of the multiple in-game leagues to be used, based on user operation. In the aforementioned baseball game example, as shown in Figure 16, it is possible to set a condition that either league is acceptable by selecting both options for participating league (event character league or development player league). Also, as shown in Figure 6, it is possible to set a condition that either lineup is acceptable by selecting the "automatic" option for the lineup to be used (event character lineup or development player lineup).

[0167] Each user registers items (orders, decks, etc.) corresponding to multiple in-game leagues, and plays games in the same in-game league with matched opponents (other users) using items corresponding to that league. Therefore, the game conditions for "the in-game league the user wishes to participate in" have the same meaning as the game conditions for "the items corresponding to the league the user wishes to use."

[0168] Furthermore, the objects included in the aforementioned target of use may include at least two different types of objects: a first object and a second object. In the baseball game example described above, a development player is an example of a first object, and an event character is an example of a second object.

[0169] Here, regarding the aforementioned "first and second objects of different types," examples of differences in object types include: (1) differences in the acquisition route by which the user obtains the object (for example, whether it is cultivated by playing the game or obtained by lottery), (2) differences in the manner of use (for example, whether it is used as an object that can be manipulated or as an object that cannot be manipulated in a predetermined mode within the game), (3) differences in the possibility of changing parameters after acquisition (for example, whether or not parameters can be changed through processes such as enhancement), and (4) differences in the parameters that can be changed.

[0170] Furthermore, the multiple usage targets may include at least a first usage target where the first object is registered and a second usage target where the second object is registered. In the baseball game example described above, the training player order where training players are registered is an example of a "first usage target," and the event character order where event characters are registered is an example of a "second usage target."

[0171] Furthermore, the first object constituting the first target of use may be associated with user identification information and a cultivated object that has been cultivated by changing or setting parameters.

[0172] Here, "object parameters" refer to parameters set for an object. In other words, "object parameters" are parameters associated with an object. "Object parameters" may or may not be numerical parameters. For example, a parameter indicating the overall ability or performance of an object (e.g., overall ability value, level, etc.) is an example of an "object parameter." Also, for example, a parameter indicating the level of a specific ability or performance of an object (e.g., attack power, defense power, etc.) is an example of an "object parameter." Also, for example, a parameter necessary to improve the ability or performance of an object (e.g., experience points, etc.) is an example of an "object parameter." Also, for example, a parameter indicating the condition of an object (e.g., fatigue level, motivation, etc.) is an example of an "object parameter." Also, for example, rarity indicating the scarcity of an object is an example of an "object parameter." Also, for example, information about a special ability possessed by an object is an example of an "object parameter." Also, for example, information about the object's physical characteristics (height, weight, leg length, hand size, etc.), gender information, etc., may be included in "object parameters."

[0173] Furthermore, "changing parameters" refers to altering the parameters set for an object. For example, increasing or decreasing the parameters set for an object is one example of "changing parameters."

[0174] Furthermore, "setting parameters" refers to setting parameters on an object that have not yet been set on that object. For example, adding a special ability that the object did not previously possess (for example, associating information about a special ability with the object) is an example of "setting parameters."

[0175] In the aforementioned baseball game example, the first object that constitutes the first development player order as the first target of use is a user ID associated with a development player (an example of a development object) that has been developed by changing or setting parameters (i.e., a development player owned by the user).

[0176] Furthermore, the second object constituting the second target of use may be one second object, determined by lottery from among a plurality of second objects, associated with user identification information.

[0177] In the aforementioned baseball game example, the second object constituting the event character order as the second target of use is an event character associated with a user ID, which is determined by lottery from among multiple event characters managed within the game (i.e., an event character owned by the user).

[0178] According to the above configuration, two different types of targets, a training player order and an event character order, can be registered according to the game conditions. Here, users with a high level of game proficiency (level of play) tend to be able to train players with high parameters, while users who have just started the game can only create training player orders consisting of relatively low-ability players. In that case, in a training player league using training player orders, it is expected that the number of users participating in the league will be small because users with high game proficiency will be too strong. On the other hand, event characters that can be obtained through lottery have a chance of being obtained with relatively high parameters regardless of the user's game proficiency. Therefore, even users who have just started the game can create an event character order of a certain strength. In this way, by making it possible to register different types of training player orders and event character orders according to different game conditions, it becomes easier for various users to participate in the game regardless of their game proficiency, and the opportunities for matchmaking also increase.

[0179] Furthermore, the second object associated with user identification information may be available as an auxiliary object for changing or setting the parameters of the first object during the development of the first object.

[0180] Here, the term "auxiliary object" refers to an object used auxiliaryly to influence the parameters of other objects used in the game. For example, an "auxiliary object" is a so-called "non-player character" that is not directly controlled by the user in the game, but it influences the parameters of the "player character" that is controlled. For example, if one or more second objects are set in the deck before starting to train the first object, and an event corresponding to the second object occurs during training, and the parameters of the first object are changed or set based on that event, then the second object is an example of an "auxiliary object." Furthermore, "support objects" may be associated with other objects and modify or set the parameters of those other objects. For example, a character associated with a first object as a coach or trainer that improves the parameters of that first object is an example of a "support object." Also, for example, an equipment item that is equipped (associated) with a first object and produces an effect that improves the parameters of that first object is an example of a "support object."

[0181] In the aforementioned baseball game example, an event character used to change or set the ability parameters of a player being trained in training mode is an example of a "support object." With this configuration, the event characters owned by the user are used not only in matchmaking battle modes but also as support objects in training players. This effectively suppresses the increase in the number of characters in the game and allows for the efficient use of character resources.

[0182] [4. Processing] Next, an example of the processing performed by the game system 1 of this embodiment will be described below.

[0183] Figure 18 is a flowchart showing an example of the processing of the game system 1 executing the aforementioned real-time battle mode. Figure 19 is a sequence chart showing an example of the processing of the game system 1 executing the real-time battle mode. The processing described below is realized by the control unit 110 (CPU 11 of the game terminal 10 or CPU 31 of the server 30) executing the game program stored in the memory device (ROM 12, RAM 13, auxiliary memory device 14, ROM 32, RAM 33, or auxiliary memory device 34, etc.).

[0184] Here, as an example, we will describe a scenario where server 30 primarily performs the matching process, and each user's game terminal 10 primarily performs processes other than matching. Therefore, the processes shown in Figure 18 are assumed to be executed by the CPU 11 of each user's game terminal 10.

[0185] In S100, the CPU 11 stores and registers the training player order in a storage device (auxiliary storage device 14, auxiliary storage device 34, database DB, etc.) based on the user's operation. The user can tap the training player order editing button B301 on the top screen G300 of the real-time battle mode, as exemplified in Figure 4, to open the training player order editing screen G400, as exemplified in Figure 5, and edit and register the training player order. This registration of the training player order is possible at any time before a matching request (S106 in Figure 18).

[0186] Once registered, the information for a player development order is stored in non-volatile memory. Therefore, unless the user changes the player development order in subsequent matches, the registered order will be applied. Thus, users do not necessarily need to edit their player development order every time they match. For example, a user only needs to edit their player development order when they have developed a player with high abilities in development mode.

[0187] In S102, the CPU 11 stores and registers the event character order in a storage device (auxiliary storage device 14, auxiliary storage device 34, database DB, etc.) based on the user's operation. The user can open the event character order editing screen by tapping the event character order editing button B302 on the top screen G300 in Figure 4, and edit and register the event character order. This registration of the event character order is also possible at any time before a matching request (S106 in Figure 18).

[0188] Similar to the player development order, the information for the event character order, once registered, is stored in non-volatile memory. Therefore, unless the user changes the event character order in subsequent matches, the registered event character order will be applied. Thus, users do not necessarily need to edit their event character order every time they match. For example, users only need to edit their event character order when they obtain a high-rarity event character in the lottery acquisition mode or when they level up an event character in the enhancement mode.

[0189] In S104, the CPU 11 stores and registers the matching condition settings information in a storage device (auxiliary storage device 14, auxiliary storage device 34, database DB, etc.) based on the user's operation. The user can tap the search setting button B303 on the top screen G300 in Figure 4 to open the search setting screen G500 as exemplified in Figure 6, and set and register the matching game conditions. These matching condition settings can also be done at any time before a matching request (S106 in Figure 18).

[0190] In the game of this embodiment, the game conditions for matching (search conditions for matching opponents) can be set, including the order of players to be used and the number of innings. Regarding the order of players to be used, it is possible to set the condition by selecting the "random" option P511, which allows either the training player order or the event character order to be used in a match (see Figure 6). It is also possible to set the condition by specifying only one of the training player order or the event character order as the order to be used.

[0191] Furthermore, since the matching conditions information, once registered, is stored in a non-volatile storage device, the registered conditions may be applied to subsequent matches unless the user changes the conditions. In this case, the user does not necessarily need to change the matching conditions every time a match is made, and the user may change the conditions as needed. Alternatively, the default conditions (for example, "automatic" for the order of players and "automatic" for the number of innings) may be applied each time a match is made, and the user may change the conditions as needed before requesting a match.

[0192] Note that the processing order of S100, S102, and S104 is not limited to this, and any of the processes may be executed in any order.

[0193] In S106, the CPU 11 sends a matching request, including the matching conditions, to the server 30. The user can make a matching request, including the matching conditions, by tapping the matching button B304 on the top screen G300 in Figure 4. The data of the matching request sent from the game terminal 10 to the server 30 includes the information on the conditions and the user ID. The matching request may also include the aforementioned communication strength information, etc.

[0194] After sending a matchmaking request to the server 30, the game terminal 10 enters a waiting state until a match is made.

[0195] Here, we will explain using the sequence chart in Figure 19. Figure 19 shows an example of the process when matching occurs between the game terminal 10-1 of user user ID: U1 and the game terminal 10-2 of user user ID: U2.

[0196] In the following, the user with User ID: U1 will be referred to as "User A," and the user with User ID: U2 will be referred to as "User B." Furthermore, it will be assumed that User A has set the condition for the order to "automatic," while User B has set the condition to specify either the training player order or the event character order.

[0197] Matching requests with the above-described conditions are sent to the server 30 from User A's game terminal 10-1 and User B's game terminal 10-2 (S200-1 and S200-2). The server 30 receives matching requests from multiple game terminals 10-n, including game terminals 10-1 and 10-2, and executes the matching process (S300). This matching process is deemed to have resulted in a successful match between User A's game terminal 10-1 and User B's game terminal 10-2. In this case, the server 30 sends matching information to User A's game terminal 10-1 and User B's game terminal 10-2, including information about the opponent (opponent's user ID, etc.) and information about the game conditions under which the match was successful (order of players used, number of innings) (S302-1 and S302-2).

[0198] Returning to Figure 18 and continuing the explanation, the CPU 11 of the game terminals 10 for users A and B receives the matching information from the server 30, and if a match is established (YES in S108), it applies the team order corresponding to the game conditions for which the match was established (a pre-registered training player order or event character order) (S110). As a result, for example, the display unit 17 of the game terminal 10 displays the pre-match confirmation screen G600 shown in Figure 7, and users A and B can confirm the opponent's information (opponent's username, leader character image, communication strength information, etc.) and the game conditions for which the match was established. Here, since user A had set the condition for the order to be used to "random," after the match is established, they can confirm which of the two registered orders will be used. In this embodiment, the match starts when either user A or user B who has been matched operates the match start button B632 within the time limit (S112).

[0199] In Figure 19, the versus game can be played, for example, through direct communication between game terminal 10-1 and game terminal 10-2 via P2P connection (S202). The versus game may also be played via server 30. During the versus game, the game progresses as user A and user B each control player characters in the team order corresponding to the game conditions for which the matchmaking was successful.

[0200] Subsequently, when the versus game between user A and user B ends (YES in S114 of Figure 18), the CPUs 11 of both game terminals 10 execute the termination process for the match (S116). That is, as shown in Figure 19, game terminals 10-1 and 10-2 send the results of the versus game to the server 30 (S204-1 and S204-2). Note that if the versus game was executed via the server 30, S204-1 and S204-2 can be omitted.

[0201] Subsequently, the server 30 transmits information to game terminals 10-1 and 10-2 to award rewards such as points and items to user A and user B according to the results of the battle game (S304-1 and S304-2). As a result, the display units 17 of game terminals 10-1 and 10-2 display information about the battle results and rewards.

[0202] [5. Summary] In the game system 1 according to the embodiment described above, multiple team orders and decks corresponding to each of multiple game conditions can be registered in advance. Then, by making a matching request with a condition setting that allows any two or more of the multiple game conditions to be used, a game can be played using the team orders and decks corresponding to the game conditions for which a match has been made. As a result, users who want to play a game under any of the two or more game conditions will have more opportunities to be matched, and the opportunities to be matched will also increase for game conditions that were previously difficult to match. With this configuration, it is possible to use different team orders and decks depending on the game conditions, while increasing the overall opportunities to be matched, especially for game conditions that were previously difficult to match, thereby improving the enjoyment of the game.

[0203] [6. Variant] The present invention is not limited to the embodiments described above.

[0204] [6-1] The above examples show that a training player order (an example of the first target) consisting of a predetermined number of training players (an example of the first object) and an event character order (an example of the second target) consisting of a predetermined number of event characters (an example of the second object) are registered in advance. However, it is also possible to register a mixed order (an example of the third target) that includes at least one training player and at least one event character in advance. Furthermore, the mixed order may also be associated with at least a part of the game conditions for matching, similar to the training player order and the event character order. In addition, it is possible to set an "automatic" condition for the game conditions of the order to be used, which may be any of the training player order, event character order, or mixed order (or any two of the three orders), and a match game using the order corresponding to the game conditions for which matching is achieved may be executed.

[0205] [6-2] The above examples show games using two different types of objects: training players and event characters. However, these examples can also be applied to games using three or more types of objects. That is, multiple usage targets (orders, decks, etc.) containing three or more types of objects can be registered in advance, and each of these usage targets can be associated with at least some of the game conditions for matching. For example, this can be applied to a game using three types of objects that are acquired through training (e.g., training players), objects that can be acquired through lottery (e.g., event characters), and objects that are given to all users in common in tournament events held within the game (e.g., limited-time common objects).

[0206] [6-3] The above examples show the use of a usable object (team order, deck, etc.) composed of objects (training players, event characters, etc.) that the user possesses (i.e., associated with the user's user identification information). However, some of the objects included in the usable object may be objects that the user does not possess. For example, objects possessed by other users associated with the user (i.e., other users whose user identification information is associated with the user's user identification information, and who are referred to as friends, teammates, etc.) may be included in the team order, etc., as a usable object for the user.

[0207] [6-4] While the above does not impose any restrictions on the selection of development players to make up a development player lineup, the following restrictions may be imposed. For example, a restriction may be imposed that costs (assessment values) be set according to the ability level of the development players, and the total cost of the multiple development players that make up a development player lineup must be less than or equal to the maximum team cost. In this case, developing high-ability development players will strengthen the development player lineup, but the cost-effectiveness of each development player will also be important to some extent. Rather than simply forming a lineup with only high-ability development players, it will be necessary to edit the lineup while considering the maximum team cost. Similarly, a cost (assessment value) may be set according to the ability level of the event characters, and a restriction may be imposed that the total cost of the multiple event characters constituting the event character order must be less than or equal to the maximum team cost.

[0208] [6-5] The above examples show that editing (registering) the training player order and event character order is possible at any time before sending a matching request, but it is also possible to allow editing of the order until the match starts. For example, a predetermined period may be set after the match is made but before the match starts during which each matched user can edit their order.

[0209] [6-6] The above describes an example in which, after matching is established, a pre-match confirmation screen G600 as illustrated in Figure 7 is displayed, and the match does not start unless both matched users operate the match start button B632. However, the system is not limited to this. For example, after matching is established, the match may start automatically without the user operating the match start button B632 (i.e., after matching is established, the user cannot cancel the match before the match starts).

[0210] [6-7] If the differences in the aforementioned "scenarios applied to training" are to be set as "game conditions" for matching, the following configuration can be used. For example, if there are multiple "training teams" associated with scenario A applied to training (i.e., "training teams" trained by executing scenario A), the user can specify and register any one of these "training teams" as the target for use. Similarly, for "training teams" associated with scenarios B, C, ..., the user can specify and register one "training team" for each scenario as the target for use. Then, each scenario applied to training can be set as a "game condition," and it is possible to set an "automatic" matching condition that allows any of two or more scenarios, and a competitive game will be executed using the "training team" corresponding to the scenario of the game condition for which matching is achieved.

[0211] [6-8]When setting the differences in the above-mentioned "timing of obtaining an object", "object type", or "type of gacha" as the "game conditions" for matching, the following configuration can be adopted. For example, for each "timing of obtaining an object", the user can pre-register a target for use (a single object, or a team, deck, etc. composed of multiple objects) that includes at least one object. For example, in association with the "2021 series", a deck composed of a predetermined number of objects of the 2021 series can be registered, and in association with the "2022 series", a deck composed of a predetermined number of objects of the 2022 series can be registered. Then, it is possible to set the matching condition of "leave it to chance" such that any of two or more "timings of obtaining an object" can be used, and a game using the deck corresponding to the game conditions for which the matching is established is executed. The same applies when setting the differences in "object type" or "type of gacha" as the "game conditions" for matching. That is, for each "object type" or "type of gacha", it is possible to pre-register a target for use that includes at least one object, enable the above-mentioned "leave it to chance" matching condition setting for these game conditions, and execute a game using the deck corresponding to the game conditions for which the matching is established.

[0212] [6-9]In the above, mainly an example of a baseball game has been described, but the present invention can also be applied to other games. For example, various games can be applied as long as they are "games in which a plurality of targets for use including at least one object can be registered, and the matched users use the targets for use", regardless of the game format or genre, such as other sports games (games themed on soccer, tennis, American football, basketball, ice hockey, volleyball, rugby, etc.), fighting games, combat games, digital card games, role-playing games, simulation games, adventure games, or breeding games.

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

[0214] [6-11] With respect to a configuration having a memory control function for storing various information in a memory device, the memory device itself is not included in the configuration and may be installed anywhere, whether inside or outside the game system 1. For example, the memory device may be a memory device within the game system 1 (e.g., RAM 13, auxiliary memory device 14, RAM 33, auxiliary memory device 34, database DB, etc.), or a file server (online storage) with a separate configuration.

[0215] [6-12] The computer-readable program according to this embodiment is recorded on various computer-readable recording media such as hard disks, optical discs (CD-ROMs, DVD-ROMs, etc.), flexible disks, and semiconductor memory, and is read from the recording media and executed by the CPU of the computer constituting the game system 1 or game control device. Furthermore, the means of providing the program to the computer are not limited to the aforementioned recording media, but can also be done via a communication network such as the Internet.

[0216] [7. Addendum] Based on the above description, the present invention can be understood as follows, for example. For the sake of ease of understanding the present invention, reference numerals in the attached drawings are conveniently added in parentheses, but this does not mean that the present invention is limited to the illustrated embodiments.

[0217] 1) A game system (1) according to one aspect of the present invention includes: registration means (111) for registering a plurality of usage targets (e.g., training player order, event character order) that include at least one object (e.g., training player, event character) based on user operation; condition setting means (112) for enabling the setting of any two or more of a plurality of game conditions (e.g., the condition of using an event character order, the condition of using a training player order) corresponding to each of the plurality of usage targets based on user operation; matching means (113) for matching a player to play with the user based on a matching request accompanied by the condition setting; and game execution means (114) for executing a game using the usage targets corresponding to the game conditions for which the matching has been established.

[0218] 9) A game control device (10 or 30) according to one aspect of the present invention includes: a registration means (111) for registering a plurality of usage targets (e.g., training player order, event character order) that include at least one object (e.g., training player, event character) based on user operation; a condition setting means (112) for enabling the setting of any two or more of a plurality of game conditions (e.g., a condition to use an event character order, a condition to use a training player order) corresponding to each of the plurality of usage targets based on user operation; a matching means (113) for matching a player to the user based on a matching request accompanied by the condition setting; and a game execution means (114) for executing a game using the usage targets corresponding to the game conditions for which the matching has been established.

[0219] 10) A game control device (10) according to one aspect of the present invention includes: a registration means (111) for registering a plurality of usage targets (e.g., training player order, event character order) that include at least one object (e.g., training player, event character) based on user operation; a condition setting means (112) for enabling the setting of any two or more of a plurality of game conditions (e.g., a condition to use an event character order, a condition to use a training player order) corresponding to each of the plurality of usage targets based on user operation; and a game execution means (114) for executing a game using the usage targets corresponding to the game conditions for which a match has been made based on a matching request accompanied by the condition setting.

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

[0221] 12) An information storage medium according to one aspect of the present invention is an information storage medium that is readable by a computer on which the program described in 11) is recorded.

[0222] 13) A control method for a game system (1) or game control device (10 or 30) according to one aspect of the present invention includes: a registration step (S100, S102) for registering a plurality of usage targets (e.g., training player order, event character order) that include at least one object (e.g., training player, event character) based on user operation; a condition setting step (S104) for enabling the setting of any two or more of a plurality of game conditions (e.g., a condition to use an event character order, a condition to use a training player order) corresponding to each of the plurality of usage targets based on user operation; a matching step (S300) for matching the user with a play opponent based on a matching request accompanied by the condition setting; and a game execution step (S110, S112) for executing a game using the usage targets corresponding to the game conditions for which the matching has been established.

[0223] According to the embodiments described in 1), 9) to 13) above, users corresponding to each of multiple game conditions can be registered in advance. Then, by making a matching request with a condition setting that allows any two or more of the multiple game conditions to be used, a game can be executed using the users corresponding to the game conditions for which a match has been made. As a result, users who want to play a game under any of two or more game conditions will have more opportunities to be matched, and the opportunities to be matched will also increase for game conditions that were previously difficult to match. This configuration allows for the use of different users depending on the game conditions, increases the overall opportunities for matching, and in particular increases the opportunities to be matched for game conditions that were previously difficult to match, thereby improving the enjoyment of the game.

[0224] 2) In one aspect of the present invention, in the embodiment described in 1), 9), or 10) above, a plurality of in-game leagues in which a user can participate are set up, and the registration means (111) may register a plurality of the above-mentioned targets corresponding to each of the plurality of in-game leagues based on the user's operation.

[0225] According to the embodiment described in 2) above, multiple in-game leagues and multiple of the aforementioned users correspond to each other. For example, user A is used for gameplay in in-game league A, and user B is used for gameplay in in-game league B. Since multiple users also correspond to multiple game conditions, when the "random" condition setting is used for matching, the user corresponding to the matched game conditions is used, and a game is played in the in-game league corresponding to that user. This makes it possible to use different users depending on the game conditions, while also increasing the chances of matching even in in-game leagues where matching was previously difficult.

[0226] 3) In one aspect of the present invention, in the embodiment described in 2) above, the game conditions include the in-game league in which the user wishes to participate, or the target of use corresponding to the in-game league in which the user wishes to use, The condition setting means (112) may enable the setting of conditions that, based on user operation, any two or more of the multiple in-game leagues may be used, or any two or more of the multiple targets corresponding to each of the multiple in-game leagues may be used.

[0227] Each user registers a target for use in each of multiple in-game leagues, and plays games with opponents (other users) who are matched within the same in-game league. Therefore, the game conditions for "the in-game league the user wishes to participate in" have the same meaning as the game conditions for "the target corresponding to the in-game league the user wishes to use." According to the configuration described in 3) above, it is possible to differentiate the use of targets based on game conditions, while also increasing the chances of matching in in-game leagues where matching was previously difficult.

[0228] 4) In one aspect of the present invention, in the embodiment described in any of 1) to 3), 9), or 10) above, the object may include at least a first object of a different type (e.g., a training player) and a second object (e.g., an event character), and the plurality of uses may include at least a first use where the first object is registered (e.g., a training player order) and a second use where the second object is registered (e.g., an event character order).

[0229] According to the embodiment described in 4) above, two different types of targets can be registered, corresponding to game conditions: a first target for which the first object is registered, and a second target for which the second object is registered. Depending on the type of object, for example, users with a high level of game proficiency (playtime) may be more likely to acquire objects with higher parameters (e.g., the first object). In such cases, a beginner user who has just started playing the game can only use targets consisting of objects with relatively low parameters. However, if there is another type of object (e.g., the second object) that even beginner users can obtain with relatively high parameters, they will be able to use a certain number of targets. As in this example, by allowing the registration of multiple targets composed of different types of objects, the variety of targets increases, making it easier for various users to participate in the game and increasing the opportunities for matchmaking.

[0230] 5) In one aspect of the present invention, in the embodiment described in 4) above, the first object is a training object (e.g., a training player) that has been trained by changing or setting parameters and is associated with user identification information, and the second object is a second object (e.g., an event character) that has been determined by lottery from among a plurality of second objects and is associated with user identification information.

[0231] According to the embodiment described in 5) above, two different types of targets can be registered, each corresponding to game conditions: a first target consisting of training objects obtained by the user through training, and a second target consisting of second objects obtained by the user through a lottery. Training objects are easier to raise the parameters of for users with higher game proficiency, while second objects obtained through a lottery have the potential to be obtained with relatively high parameters by anyone, regardless of their game proficiency. In this way, by allowing the registration of different types of first and second targets, each corresponding to different game conditions, it becomes easier for various users to participate in the game regardless of their game proficiency, and the opportunities for matching increase.

[0232] 6) In one aspect of the present invention, in the embodiment described in 5) above, the second object (e.g., an event character) associated with user identification information may be used as an auxiliary object for changing or setting the parameters of the first object in the development of the first object.

[0233] According to the embodiment described in 6) above, the second object owned by the user is also used as an auxiliary object in the development of the first object. This makes it possible to make effective use of the object resources within the game.

[0234] 7) In one aspect of the present invention, in the embodiment described in any of 1) to 6), 9), or 10) above, the condition setting means (112) may also be able to set conditions by specifying any of the plurality of game conditions corresponding to a plurality of the plurality of targets for use, based on user operation.

[0235] According to the embodiment described in 7) above, not only is it possible to make a matching request that includes a condition setting that allows any two or more of the multiple game conditions corresponding to each of the multiple users to be used, but it is also possible to make a matching request that specifies any one of the multiple game conditions.

[0236] 8) In one aspect of the present invention, in the embodiment described in any of 1) to 7), 9), or 10) above, the condition setting means (112) may also be able to include in the condition setting other game conditions (for example, game conditions relating to the number of innings) that are different from the game conditions corresponding to the target of use (for example, conditions for using the training player order and conditions for using the event character order).

[0237] According to the embodiment described in 8) above, it is possible to make matching requests that include not only game conditions corresponding to the target of use, but also other game conditions that do not correspond to the target of use. [Explanation of symbols]

[0238] 1...Game System, N...Network, DB...Database, 10...Game Terminal, 11...CPU, 13...RAM, 14...Auxiliary Storage Device, 17...Display Unit, 30...Server, 31...CPU, 33...RAM, 34...Auxiliary Storage Device, 100...Data Storage Unit, 110...Control Unit, 111...Registration Unit, 112...Condition Setting Unit, 113...Matching Unit, 114...Game Execution Unit, TBL101...User Information Table, TBL102...Character Information Table, TBL103...Game Condition Table, TBL104...Team Order Table, DT105...Owned Character Data, DT106...Team Order Data

Claims

[Claim 1] A registration means for registering multiple targets for use, each containing at least one object, based on user operations. A condition setting means that enables setting conditions such that any two or more of the multiple game conditions corresponding to each of the multiple aforementioned target objects can be set based on user operations, A matching means for matching a user with a playing partner based on a matching request with the aforementioned conditions, A game execution means that executes a game using the object corresponding to the game conditions for which the matching has been established, A game system that includes this.

Images