JP2023124466A - Game system, game controller and program - Google Patents

Abstract

To make it possible to increase matching opportunities even in a condition which is unlikely to be matched while it is possible to use an object to use differently depending on the game condition.SOLUTION: A registration part registers a plurality of use objects including at least one object on the basis of a user's operation. A condition setting part can set a condition that any two or more of the plurality of game conditions corresponding to a plurality of use objects may be used on the basis of the user's operation. A matching part matches play mates of the user on the basis of a matching request accompanied by the condition setting. A game execution part executes a game that uses the user object corresponding to the game condition where matching occurs.SELECTED DRAWING: Figure 10

Description

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

2. Description of the Related Art Conventionally, there has been known an online game in which matched users can compete with each other via a network. Users can search for opponents by setting matching conditions.

JP 2011-156284 A

For example, if a plurality of leagues are provided in which each user can participate arbitrarily, the user can specify any one of the leagues as a matching condition. In this case, users tend to gather in leagues with a large number of participants. As a result, many people concentrate on one specific league, and for users who want to play in a league with a small number of participants, matching is not easily established and the waiting time becomes long, and the game cannot be enjoyed satisfactorily. can be.

Therefore, one of the objects of the present invention is to increase the chances of matching even under conditions where matching is difficult.

A game system or a game control device according to one aspect of the present invention includes registration means for registering a plurality of usage objects including at least one object based on a user's operation; Condition setting means for enabling setting of any two or more of a plurality of corresponding game conditions; Matching means for matching a user's play partner based on a matching request accompanied by the condition setting; and game execution means for executing a game using the use object corresponding to the game condition for which the matching is established.

A game control device according to another aspect of the present invention comprises registration means for registering a plurality of use objects including at least one object based on a user's operation; condition setting means for enabling setting of any one of two or more of a plurality of corresponding game conditions; and game execution means for executing a game using the object.

1 is a schematic block diagram showing a configuration example of a game system according to one embodiment of the present invention; FIG. FIG. 10 is a diagram showing an example of a display screen of an event deck; FIG. 11 is a diagram showing an example of a main character's ability list screen; It is a figure which shows an example of the top screen of real-time battle mode. It is a figure which shows an example of a training player order setting screen. It is a figure which shows an example of a search setting screen. It is a figure which shows an example of the confirmation screen before a battle. It is a figure which shows an example of a character information table. FIG. 10 is a diagram for explaining an example of matching processing; 1 is a schematic functional block diagram showing an example of a functional configuration of a game system; FIG. It is a figure which shows an example of a user information table. It is a figure which shows an example of a game condition table. It is a figure which shows an example of a team order table. FIG. 4 is a diagram showing an example of possessed character data; It is a figure which shows an example of team order data. FIG. 12 is a diagram showing another example of the search setting screen; It is a figure which shows another example of a team order table. 4 is a flow chart showing an example of processing of the game system; 4 is a sequence chart showing an example of processing of the game system;

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

[1. Game system configuration]
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. FIG. The game terminal 10-n and the server 30 in the game system 1 are connected via a network N such as the Internet so as to be able to communicate with each other. Here, since the plurality of game terminals 10-n have the same configuration, they will be simply referred to as "game terminals 10" when they are not distinguished from each other.

The network N of the present embodiment is not limited to the Internet. Any network that can communicably connect the game terminals 10-n and the server 30 in the game system 1 can be used. It may be a line (telephone line, mobile communication line, etc.), a wired LAN (Local Area Network), a wireless LAN, or the like, or a combination thereof with the Internet.

A game terminal 10 operated by a user is a computer used by the user to play a game. The game terminal 10 is, for example, a home game machine (stationary or portable), a personal computer, a smart phone, a mobile phone terminal, a PHS (Personal Handy-phone System) terminal, a personal digital assistant (PDA: Personal Digital Assistant), These include tablet computers, multifunctional television receivers (so-called smart televisions), and business-use (commercial) game machines installed in amusement facilities and the like.

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

In the game system 1, computer competition (also called CPU competition) and communication competition are possible. In the communication match, for example, user A operating game terminal 10-1 and user B operating game terminal 10-2 can play a match game via network N. FIG. In the case of this communication battle, for example, there is a method in which game terminals 10-1 and 10-2 matched by server 30 directly communicate with each other through a P2P (Peer to Peer) connection or the like. Alternatively, there is also a method of communicating data exchange between game terminals 10-1 and 10-2 via server 30 for communication competition. The communication battle may be conducted by any method.

Communication between the game terminal 10-n and the server 30 uses, for example, HTTP (Hyper Text Transfer Protocol) operating on TCP/IP (Transmission Control Protocol/Internet Protocol) as a base protocol. It can be realized by implementing the specified application protocol on the upper layer.

On the other hand, communication between game terminal 10-1 and game terminal 10-2 connected by P2P or the like is, for example, a communication protocol on the transport layer of the OSI reference model and is implemented mainly on the IP protocol. It can be realized by UDP (User Datagram Protocol). The above UDP is a communication method that does not perform data delivery confirmation or error correction, and is a communication method that keeps sending data to the game terminal of the other party, so the data reliability is low, but the data transfer speed is high. There is Of course, it is also possible to use an existing protocol other than UDP for communication between game terminals 10-1 and 10-2, or to use a new protocol that will be newly defined in the future.

Further, for example, in a game terminal 10-n having a short-range wireless communication function using a predetermined frequency band (for example, a frequency band of 2.4 GHz), direct communication is performed between a plurality of game terminals 10-n. A battle game or the like can also be executed.

(Hardware configuration of game terminal)
The game terminal 10 mainly includes a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM (Random Access Memory) 13, an auxiliary storage device 14, a communication section 15, an operation section 16, a display section 17, and An audio output section 18 is provided, and these are interconnected via bus lines including an address bus, a data bus, a control bus, and the like. An interface circuit, an image processing section, a sound processing section, or the like is interposed between the bus line and each component as necessary, but is omitted from the drawing.

The CPU 11 interprets and executes commands of the game program, and controls the game terminal 10 as a whole. The ROM 12 stores programs, data, etc. necessary for basic operation control of the game terminal 10 . The RAM 13 stores various programs and data and secures a working area for the CPU 11 .

The auxiliary storage device 14 is a storage device that stores game programs, various data, and the like. As the auxiliary storage device 14, for example, a nonvolatile semiconductor memory, a hard disk drive, a solid state drive, or the like can be used.

The communication unit 15 includes 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, a short-range wireless communication function using a predetermined frequency band (for example, a frequency band of 2.4 GHz). and so on. Communication unit 15 transmits a connection signal for connecting game terminal 10 to network N based on a command from CPU 11 , receives information transmitted from a communication partner, and supplies the information to CPU 11 .

The operation unit 16 is used by the user to input various operation instructions 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, and the like. Alternatively, the operation unit 16 may be configured to allow voice input by identifying voice input from a voice input unit such as a microphone.

The display unit 17 is driven based on an image display command from the CPU 11 to display a game screen or the like. Various known display devices such as a liquid crystal display and an organic EL (Electro-Luminescence) display can be applied to the display unit 17 . The display unit 17 can also be a touch panel in which a position input unit having a touch interface is combined with a display device such as a liquid crystal display. 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 indicator such as a finger or a pen touches the screen, the touch input detection unit detects the contact position coordinates on the screen and supplies the coordinate signal to the CPU 11 . Thereby, the contact position on the screen of the display unit 17 is recognized by the CPU 11 . The display unit 17 need not be integrated with the game terminal 10, and may be a television monitor or the like externally connected to the game terminal 10, for example. Thus, in the case of a television monitor or the like to which the display unit 17 is externally connected, the display unit 17 is not included in the configuration of the game terminal 10 .
The voice output unit 18 generates an analog voice signal based on the pronunciation instruction from the CPU 11 and outputs voice or the like from the speaker.

Game terminal 10 may also include 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 medium readers. In this case, a DVD-ROM, a CD-ROM, a hard disk, an optical disk, a flexible disk, a semiconductor memory, or the like is used as the recording medium. 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.

(Server hardware configuration)
The server 30 mainly includes a CPU 31, a ROM 32, a RAM 33, an auxiliary storage device 34, and a communication section 35, which are interconnected via bus lines including an address bus, a data bus, a control bus, and the like. An interface circuit is interposed between the bus line and each component as necessary, but the illustration of the interface circuit is omitted here.

The CPU 31 interprets and executes commands of system software and application software, and controls the server 30 as a whole. The ROM 32 stores programs and the like necessary for basic operation control of the server 30 . The RAM 33 stores various programs and data and secures a working area for the CPU 31 . The auxiliary storage device 34 is a storage device that stores programs, various data, and the like. As the auxiliary storage device 34, for example, a hard disk drive or a solid state drive can be used.

The communication unit 35 has a communication interface (not shown) and controls communication with each game terminal 10-n via the network N. FIG. The communication unit 35 also controls communication with other servers (not shown) connected to the network N. FIG. For example, in a system configuration in which the server 30 is incorporated into a social networking service (SNS), the communication section 35 of the server 30 controls communication with the SNS server. Also, for example, the server 30 controls communication with a video distribution server that distributes game videos played by users to spectators. Note that the server 30 can also have a moving image distribution function.

The server 30 can be composed of a single computer, but it can also be configured as a function distribution type in which each function of the server 30 is distributed to a plurality of servers. Alternatively, a plurality of servers 30 may be provided on the network N for redundancy (multiplexing), thereby providing a load-sharing configuration. Also, the server 30 may be configured as a cloud server using cloud computing technology.

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

In addition, below, the case where the game terminal 10 is a smart phone or a tablet computer provided with a touch panel is assumed.

[2. Overview of an example of a game]
An overview of an example game is provided below.
The game system 1 can execute various games. For example, various games such as sports games (baseball, soccer, tennis, American football, etc.), racing games, fighting games, combat games, digital card games, etc. can be executed regardless of game format and genre.

For example, in a baseball game, various game modes including training and competition are executed based on one or more objects (eg, game characters, game cards, game items, etc.). In the following, as an example of the game executed by the game system 1, a baseball game mainly based on baseball will be described, and other games will be mentioned as necessary.

The baseball game of this embodiment includes various game modes such as training mode, team training mode, lottery acquisition mode, strengthening mode, CPU battle mode, and real-time battle mode.

The training mode is a character training mode in which the user trains a training target character to create his own original game character. In this embodiment, a pitcher or a fielder (including a catcher) character can be trained in the training mode. Hereinafter, the game character created by the user in training mode will be referred to as a "training player". Training players can be used in other game modes such as team training mode, CPU battle mode, and real-time battle mode. The team training mode is a game mode for training a team composed of a plurality of player characters.

The lottery acquisition mode is a game mode in which an "event character", which will be described later, can be obtained by lottery and can be used as an auxiliary object when training a character to be trained in the breeding mode. In this lottery acquisition mode, for example, a lottery (so-called gacha) for an event character given to the user from among all event characters in the game is performed. A user may require, for example, a predetermined amount of in-game points, billable items, etc., in order to enter the lottery acquisition mode.
The enhancement mode is a mode in which the level of the event character can be enhanced by synthesizing the event characters obtained in the lottery acquisition mode or the like.

The CPU battle mode is also called a computer battle mode. For example, the CPU battle mode may be given a name such as "stadium". In this CPU battle mode, the user performs a batting operation, a pitching operation, a defense operation, or the like on the player characters of his/her own team organized by the trained players trained in the training mode, and competes against the opponent's team automatically controlled by the CPU. For example, the opponent team automatically controlled by the CPU is a team made up of training players trained by another user in training mode.

The real-time battle mode is a mode in which the user can compete online with another user in a remote location via the network N. FIG. In this real-time competition, for example, a game between a user's team and an opponent's team (another user's baseball team on the network N) progresses in a communication competition based on the operation of each game terminal 10 . For example, if the user is on the defensive side and the opponent user is on the offensive side, the player character pitches or defends according to the user's operation (throwing operation or defensive operation) of the opponent, and the user's operation (hitting operation) is performed. or base-running operation), the player character performs batting or base-running. In such an action game, the game situation in the game is updated based on each user's operation on the player character. This real-time competition is a competition method that is also used in e-sports (electronic sports).

In the real-time battle mode of the present embodiment, at least two types of objects can be used: training players trained in the training mode by the user and event characters also used in the training mode.
In the following, the training mode will be described first, and then the real-time battle mode using training players and event characters will be described in more detail.

(2-1. Training mode)
In the training mode, the main character to be trained practices baseball in high school, and through various events, the main character is trained as a pitcher or a fielder. In addition, a plurality of scenarios are prepared in the training mode of the present embodiment, and the high school to be advanced to differs depending on the scenario. In the game of this embodiment, the user selects one of the scenarios to determine the high school that the main character will attend.

When a scenario is selected, the user first determines basic information about the main character. The basic information includes the name, position, dominant arm, batting form, and pitching form in the case of a pitcher. For positions, choose from pitcher, catcher, first baseman, second baseman, third baseman, shortstop, and outfielder. Hereinafter, positions other than pitcher will be described as fielders.

After the basic information of the main character is determined, the event deck is set. Here, the event deck is a deck for setting event characters who will be teammates with whom the main character goes to high school to practice together. An event character is a character that affects the training of the main character (has an advantageous effect for the user) when an event occurs in the process of training the main character. Select the event character to set for the deck. The event character can be acquired as a reward for winning in the CPU battle mode or the real-time battle mode, or through a lottery in the above-described lottery acquisition mode.

The event character acquired by the user in the game is associated with the user ID as the user's possessed character, stored in a storage device (database DB, auxiliary storage device 14, auxiliary storage device 34, etc.) and managed in the game system 1. be. There is an upper limit to the number of event characters that each user can possess. The user can sell the event character that the user possesses as needed. If you sell the event character, it will be converted into points that can be used in the game or in-game currency.

In addition, the user can select one base character and one or more reinforcement material characters from among the event characters possessed, and synthesize the reinforcement material characters with the base character to strengthen the base character. . This strengthening process can improve the level of the event character selected as the base character. On the other hand, the event character used as the strengthening material character is no longer owned by the user.

Before starting the scenario in breeding mode, it is desirable for the user to previously raise the level of the event character through the strengthening process in the strengthening mode. This is because the higher the level of the event character, the higher the increase in the hero character's ability through practice, the higher the initial evaluation of the hero character, and the like.

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

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

The display area A111 displays the rarity of each event character. Rarity represents the difficulty of obtaining, and the types of rarity are "normal (N)", "powerful normal (PN)", "rare (R)", "powerful rare (PR)", There are 6 types of "Super Rare (SR)" and "Powerful Super Rare (PSR)". The rarity increases in the order of N, PN, R, PR, SR, and PSR. Also, the level of the event character is displayed in the display area A113.

Also, each event character may be associated with a special practice. An event for practicing may occur.

The display area A114 displays a list of the event character's favorite exercises. Types of practice include "hitting", "strength", "base running", "shoulder strength", "ball speed", "control", "stamina", "breaking ball", "defense", and "mental". . When the event character is set in the event deck, the display area A115 displays the multiples of the event character that are good practice. In the example shown in FIG. 4, there is one event character whose specialty is batting, two event characters who are good at strength training, one event character who is good at base running, and one character who is good at shoulder strength. It shows that one event character is set to practice and one event character is set to practice mental skill. It should be noted that one event character may have two or more types of good practices.

When setting the event character to the event deck is completed as described above, next, items that can be used in the breeding mode are selected. Items can be obtained as rewards for winning in the battle mode or by lottery. For example, the user can use up to two items in the training mode. The types of items include items that increase the rate of event occurrence, items that restore physical strength, and items that lower the rate of injury.

When the selection of game items is finished as described above, the scenario is started. Here, before explaining the contents of the scenario, the ability parameters of the main character to be trained will be explained. FIG. 3 shows an example of an ability list screen G200 when the main character is trained as a fielder. An image of the main character is displayed in the display area A210.

The display area A211 displays the name of the main character. The display area A212 displays the position number of the main character. The display area A213 displays the batting form and dominant arm of the main character. The display area A214 displays the defense positions of the main character.

The display areas A215 to A221 display basic abilities as a fielder. In addition, the basic abilities displayed in the display areas A216 to A221 are displayed in eight evaluation ranks of S, A, B, C, D, E, F, and G, and if the ability value is 90 or more, S, 80 A for up to 89, B for 70 to 79, C for 60 to 69, D for 50 to 59, E for 40 to 49, F for 20 to 39, F for 19 or less In that case, it will be G.

In the display area A215, the basic ability related to "ballistics" is displayed, and is represented by numerical values 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. The display area A216 displays the basic ability related to "Meat", and the higher the ability of "Meat", the easier it is to hit the ball with the bat, and the easier it is to hit. The display area A217 displays the basic ability related to "power", and the higher the ability of "power", the easier it is to hit long hits. In the display area A218, the basic ability related to "running ability" is displayed. The display area A219 displays the basic ability related to "shoulder strength", and the higher the "shoulder strength" ability, the faster the ball can be thrown in defense. The display area A220 displays the basic ability related to "defensive ability", and the higher the "defensive ability", the wider the defensive range. The display area A221 displays the basic ability related to "ball catching", and the higher the "ball catching" ability, the easier it is to catch the ball skillfully in defense and the less likely an error will occur.

The display area A222 displays a list of special abilities related to the fielders possessed by the main character. In the example shown in FIG. 3, the main character has five types of special abilities: "infield hit", "pinch hitter", "in-course", "throw", and "stable condition". In other words, the main character should be able to hit infield easily, increase his ability value when appearing as a pinch hitter, be good at batting "in-course", be able to throw the ball accurately when defending, and have a stable condition. showing.

Note that the example shown in FIG. 3 shows the case where the main character is a fielder, so the basic abilities and special abilities of the fielder are displayed. If the main character is a pitcher, the pitcher's basic abilities (for example, ball speed, control, stamina, etc.) and special abilities are displayed.

Next, progress of the scenario in breeding mode will be described. For example, a scenario is composed of four sections, the first to third sections are composed of 12 turns each, and only the fourth section is composed of 15 turns. For each turn, the user can select an arbitrary practice command from a plurality of practice command options to have the hero character practice, or select a rest command to have the hero character rest. In addition, since the high school baseball preliminaries and the high school baseball game at Koshien are included from the middle of the 4th section, if you lose the game in the middle and are eliminated, the 4th section will be forced to end. may

In each turn of each section, a plurality of teammates appear in addition to the main character, which greatly affects the development effect of the main character. The teammates include event characters set in the event deck, predetermined event characters specific to the scenario, and other default characters (non-event characters).

Also, there are cases where a pre-event and a post-event occur across one turn. Events that occur include an event corresponding to an event character set in the event deck, an event corresponding to a combination of a plurality of event characters set in the event deck, a scenario event specific to the scenario, and the like. Whether the event to occur is a previous event or a subsequent event is determined in advance by the contents of the scenario event and the event character, and the occurrence condition of each event occurs when the event occurrence lottery is won. When these events occur, the main character is given training effects corresponding to the events that have occurred.

Based on the execution results of practice commands selected by the user in each turn, the results of events that have occurred, etc., the player can acquire the experience values necessary to increase the ability value of the main character or acquire special abilities. The user considers which ability parameter to increase and which special ability to acquire within the range of the acquired experience value.

It should be noted that the ability value of the main character may be improved or a special ability may be acquired according to the execution result of a practice command selected by the user, the result of an event that has occurred, etc., without going through the experience value.

Basically, the training of the main character is completed by the end of one scenario. A main character that has been trained is evaluated based on its basic abilities, special abilities, etc., and a player's overall strength value is calculated, and a player rank is determined based on the player's overall strength value. A main character that has been trained in the training mode is registered as a "training player" that can be used by the user in game modes other than the training mode in association with the user ID. Also, the "training player" may be associated with information on the scenario applied to training. After the scenario ends, another "training player" can be created by starting the scenario again from the beginning and training the main character. That is, by repeating training in the training mode, the user can create a plurality of "training players" having various abilities.
Also, a team development mode may be provided in which a scenario selected by the user from a plurality of scenarios is progressed to develop a team (a group composed of a plurality of objects). In this case, one team can be created by executing one scenario. A team trained in this team training mode is also registered in association with the user ID as a "trained team" that can be used by the user in other game modes such as the real-time battle mode. Also, the "training team" may be associated with information on the scenario applied to training.

(2-2. Real-time battle mode)
A real-time battle mode using the training player (an example of the first object) and the event character (an example of the second object) will be described below.

In the real-time battle mode of this embodiment, two in-game leagues are provided in which each user can arbitrarily participate. In one of the in-game leagues, each user uses a "training player order" (an example of a first use target) organized by a predetermined number (25 in this embodiment) of training players possessed by each user. It is a “training player league” where you can play against each other. Another in-game league is an “event character order (hereinafter referred to as “event character order”)” (second It is an "event character league" in which users can compete against each other by using each of them).

(Regarding training player orders)
The training player order is composed of 25 training players owned by the user (for example, 8 starting fielders, 8 reserve fielders, 3 starting pitchers, 5 intermediate pitchers, and 1 closing pitcher).

From the start of the game, each user is given a predetermined number (for example, 25) of default training players. Normally, the default ability value of a player to be trained is set to be lower than that of a player to be trained by the user in the training mode. The default training player ability parameters are common to all users. That is, each user can organize a player-to-be-trained order including default players to be trained, before training 25 or more players in the training mode.

When the real-time battle mode is executed for the first time, a default training player order is initially set. For example, when the real-time battle mode is executed for the first time, a tutorial on how to play the mode is executed, and a default training player order is initially set in the user's operation of this tutorial. For example, the CPU 11 of the game system 1 selects from among all training players associated with the user's user ID at that time (that is, all training players trained in the training mode by the user and all default training players). A training player determined to be optimal is automatically selected, and a default training player order is automatically set.

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

FIG. 4 shows an example of the real-time battle mode top screen G300 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 edit button B301 for editing the training player order. When the player-to-be-trained order edit button B301 is tapped, the screen changes to the player-to-be-trained order edit screen G400 illustrated in FIG.

In an area A410 of the training player order edit screen G400 in FIG. 5, fielder training orders for the user's team are displayed. The players to be trained included in the player to be trained order are displayed separately for the members of the starting order and for the backup members. The members can be exchanged by dragging the part P411 in which the player name of a certain member is written to the part P411 in which the player name of another member is written. Also, when replacing a trained player who is not included in the current order with a member, by dragging the part P411 to the part P412, a list of interchangeable trained players is displayed. The button B421 is a random button, and when the user taps the button B421, the game system 1 automatically organizes the optimum order for the user's training player team. For example, a trained player with the highest overall player strength at each position is automatically selected from all trained players associated with the user's user ID at that time.

The button B430 is a button for switching to an edit screen for a training player order for a pitcher. As with the fielders described above, the training player orders for pitchers can also be edited.
An area A440 displays the team rank and overall team strength in the current training player order. For example, the team rank and overall team strength are calculated based on the ability parameters of all the players to be trained included in the player to be trained order. When the player-to-be-developed order has been edited, the area A440 displays changes in the team rank and overall team strength before and after editing. When the user taps the decision button B422, the edited content of the training player order is confirmed, and the screen transitions to the top screen G300 of FIG. To return to the top screen G300 without confirming and editing the current training player order, tap the return button B450.

As described above, the player-to-be-trained order can be strengthened by replacing it with a player-to-be-trained owned by the user. For example, if a training player with a higher ability parameter can be trained in the training mode, the user can strengthen his/her own team by editing the training player order.

(About event character order)
The event character order consists of 25 event characters owned by the user (eg, 8 starting fielder members, 8 backup fielders, 3 starting pitchers, 5 intermediate pitchers, and 1 closing pitcher).

When executing the real-time battle mode for the first time, each user is given a predetermined number (for example, 27) of default event characters. Then, the default event character order is initialized. For example, when the real-time battle mode is executed for the first time, a tutorial on how to play the mode is executed, and a predetermined number (for example, 27) of event characters are given to the user through user operations in this tutorial. The event character given here is common to each user.
As a variation, the predetermined number of event characters given to each user when the real-time battle mode is executed for the first time may be determined by a lottery similar to the lottery acquisition mode. In this case, the predetermined number of event characters that can be acquired for the first time differs depending on the user.

Here, event characters handled in the game provided by the game system 1 will be described. FIG. 8 shows an example of the character information table TBL102. The character information table TBL102 is master data for managing all event characters handled in the game provided by the game system 1. FIG. Initial data of all event characters are stored in the character information table TBL102 as reference parameters. For example, the character information table TBL102 is stored and managed in storage devices (for example, RAM 13, auxiliary storage device 14, RAM33, auxiliary storage device 34, database DB, etc.) of the server 30 and the game terminal 10, respectively. The character information table TBL102 stored in the server 30 and the game terminal 10 are basically the same. For example, when the game management side changes the character information table TBL102 in the server 30, the changed information 30 to the game terminal 10 .

The character information table TBL102 includes fields such as "original ID", "profile ID", "name", "rarity", "limit level", "position", "ability", and "event" of each event character.

The original ID is identification information given to each event character name (player name). A profile ID is identification information given according to the rarity of an event character. The same original ID is given to event characters with the same name. Different profile IDs are assigned to event characters with the same name if they have different rarities. For example, event characters with the same name but different rarities have different profile IDs only in the first digit. Information that uniquely identifies an event character in the character information table TBL102 is a profile ID.

Event characters with the same name but different rarities have the same ability parameter values but different limit levels. Here, the limit level is the upper limit of the level of the event character. The initial level when the user obtains the event character is "level 1". After obtaining this, the user can improve the level of the event character up to the limit level by the strengthening process of the strengthening mode described above. The higher the rarity of the event character is, the higher the limit level is set, and the level of the event character can be raised to a higher level. By satisfying a predetermined condition, the limit breakthrough effect may be activated and the limit level of the event character may be improved.

Each event character also has a defensive position and ability parameters set in the same manner as the training player. The ability parameters of the event character are similar to the training player (main character) illustrated in FIG. including. Also, in the case of a pitcher, the event character's ability parameters include the ball speed, control, stamina, basic ability of breaking balls, and special ability, similar to the training player.

The event character's ability reflects the event character's rarity and level. For example, for event characters with the same name but different rarities, the ability parameters are corrected such that the higher the rarity, the higher the ability value.
Further, for example, in the case of event characters with the same name but different rarities, the ability parameters are corrected such that the higher the level, the higher the ability value. Therefore, the event character included in the event character order can be strengthened by the user by increasing the level of the event character in the strengthening mode.

The "event" field of the character information table TBL102 stores information on events associated with event characters. Information in this "event" field is used when an event character is set in the event deck in breeding mode. When an event character is used in a mode other than the breeding mode such as the real-time battle mode, there is no effect of generating an event associated with the event character, so the information in the "event" field is not referred to.

Although omitted in FIG. 8, other fields are also included in the character information table TBL102. For example, the character information table TBL 102 includes fields such as image information and initial evaluation of the event character.

When the real-time battle mode is executed for the first time, the default event character order is initially set. For example, when the real-time battle mode is executed for the first time, a tutorial on how to play the mode is executed, and the default event character order is initialized in the user's operation of this tutorial. For example, all training players associated with the user's user ID at that time (that is, all event characters already possessed by the user in the lottery acquisition mode and the predetermined number given to the user at the time of the above-mentioned first execution) event characters), an event character judged to be optimal by the CPU 11 of the game system 1 is automatically selected, and a default event character order is automatically set.

The top screen G300 of the real-time battle mode in FIG. 4 includes an event character order edit button B302 for editing event character orders. When the user taps the event character order edit button B302, an event character order edit screen similar to the above-described training player order edit screen G400 (see FIG. 5) is displayed. On this event character order edit screen, the event character order can be edited in the same way as the training player order described above. That is, if the Random button is selected, the game system 1 automatically organizes the optimum order for the user's event character team. For example, an event character with the highest overall player strength (ability) at each position is automatically selected from among all event characters associated with the user ID of the user at that time. It is also possible for the user to manually replace the members of the event character order.

In this way, the event character order can be strengthened by replacing it with the event character owned by the user. For example, if an event character with a higher ability parameter is obtained in the lottery acquisition mode, or if the level of the event character is improved in the strengthening mode, the user can strengthen his or her team by editing the event character order.

It should be noted that the training player included in the training player order and the event character included in the event character order are locked so that they cannot be sold or used as enhancement materials.

In addition, the real-time battle mode top screen G300 of FIG. 4 includes a search setting button B303 for setting game conditions (matching search conditions) corresponding to the rules of the real-time battle match and searching for a matching partner. . When the user taps the search setting button B303, the screen transitions to the search setting screen G500 illustrated in FIG.

The search setting screen G500 of FIG. 6 includes a use order condition setting area A510 for the user to set the conditions related to the team order used in the battle in the real-time battle mode. This use order condition setting area A510 includes options P511 to P513. Option P512 is an option for setting a game condition to use the above-described training player order. Option P513 is an option for setting the game condition to use the aforementioned event character order. The option P511 of "Omakase" is an option for setting a game condition in which either a training player order or an event character order can be used for the order used in the match. In other words, the option P511 of "leave it to me" is an option of entrusting the game system 1 with the order used in the battle.

The user can set the use order conditions by tapping any of the options P511 to P513. FIG. 6 shows an example in which the option P511 of "automatic" is selected.
Note that any one of the options P511 to P513 may be initialized by default. For example, in order to increase the chances of matching in the game, the option P511 of "Random" is initially set.

The search setting screen G500 of FIG. 6 includes an innings condition setting area A520 for the user to set a condition regarding the number of innings for the match in the real-time battle mode. The innings condition setting area A520 includes options P521 to P524. Option P522 is an option for setting a game condition that the number of innings in the game is "up to the bottom of the third inning". Option P523 is an option for setting the game condition that the number of innings in the game is "up to the bottom of the 6th inning". Option P524 is an option for setting a game condition in which the number of innings in the game is "up to the bottom of the 9th inning". The option P521 of "Random" is an option for setting a game condition that any of "until the bottom of the 3rd inning", "until the bottom of the 6th inning", or "until the bottom of the 9th inning" is acceptable. In other words, the “leave it to me” option P521 is an option to delegate the number of innings for the game to the game system 1 .

The user can set conditions for the number of innings by tapping any of the options P521 to P524. FIG. 6 shows an example in which the option P522 of "until the bottom of the third inning" is selected.
Any of the options P521 to P524 may be initialized by default. For example, in order to increase the chances of matching in the game, the option P521 of "Random" is initially set.

When the user taps the confirm button B530, the game conditions for matching search (in the present embodiment, the use order condition and the number of innings conditions described above) are confirmed, and the screen transitions to the top screen G300 of FIG. To return to the top screen G300 after confirming the condition setting of the current game conditions, tap the return button B540.

The top screen G300 of FIG. 4 includes a matching button B304 for requesting matching. When the matching button B304 is tapped, the user's game terminal 10 sends a matching request with the aforementioned condition setting to the server 30 .

Here, an example of matching processing in the server 30 will be described. FIG. 9 shows a data structure including queues and buffers, and is a diagram for explaining an example of matching processing using the queues and buffers. In order to simplify the explanation, an example of matching processing for each user's matching request including the game condition of the number of innings "up to the bottom of the third inning" will be explained.

The queue QU3 shown in FIG. 9 is a queue for executing queuing having elements of matching request data of each user including a game condition of the number of innings "up to the bottom of the third inning". When the server 30 receives a matching request in which the game condition is set from each user's game terminal 10, the server 30 enqueues the matching request in the queue QU3 in the order received. Each matching request contains the user ID of the user who made the matching request.

In FIG. 9, the matching request is indicated by the serial number indicating the enqueuing order+[usage order condition]. Here, [A] of [Use order condition] is the condition that the event character order is used, [B] is the condition that the training player order is used, and [all] can be either the event character order or the training player order. It is a condition of "Omakase". For example, matching request 1[A] is a matching request with a conditional setting of using the Evechara order that was first enqueued in queue QU3. Matching request data 2 [all] is a matching request that is enqueued second in queue QU3 and accompanies a condition setting of "Random" that either event character order or training player order is acceptable. Matching request 3[B] is a matching request that enqueues third in queue QU3 and is accompanied by a conditional setting of using a player-in-training order.

Here, as shown in FIG. 9A, queue QU3 has five matching requests 1[A], 2[all], 3[B], 4[A], and 5[all]. The explanation is continued assuming that they are enqueued in order.

The buffer BU[A] has an area for temporarily storing a matching request with a condition setting of using the event character order dequeued from the queue QU3. The buffer BU[B] has an area for temporarily storing a matching request dequeued from the queue QU3 and accompanied by a conditional setting of using a training player order. The buffer BU[all] has an area for temporarily storing a matching request dequeued from the queue QU3 and accompanied by a condition setting of "Random", which can be either an event character order or a training player order.

In (A) of FIG. 9, the processing for the matching request 1[A] dequeued from the queue QU3 is as follows. For the dequeued matching request 1[A], the matching requests stored in the buffer BU[A] and the buffer BU[all] are matched. The server 30 checks whether a matching request is stored in any of the target buffers BU[A] and BU[all]. The confirmation order in this case is, for example, random. Note that a priority may be set in advance so that either buffer BU[A] or buffer BU[all] is preferentially checked. In the case of (A) in FIG. 9, since no matching request is stored in the target buffer BU[A] or buffer BU[all], as shown in (B) in FIG. 1[A] is temporarily stored in the buffer BU[A], and waits for matching with matching requests to be dequeued thereafter.

Next, in (B) of FIG. 9, the processing for the matching request 2[all] dequeued from the queue QU3 is as follows. For the dequeued matching request 2[all], matching requests stored in all buffers BU[A], BU[B], and BU[all] are matched. The server 30 checks whether a matching request is stored in any of the target buffers BU[A], BU[B], and BU[all]. The confirmation order in this case is, for example, random. Note that the order of priority for checking each buffer may be set in advance. Also, for example, for each predetermined period (for example, 24 hours), the number of matching requests with the condition setting of using the training player order and the number of matching requests with the condition setting of using the event character order are counted. Buffers containing fewer matching requests may be checked (searched) with priority over buffers containing more matching requests.

In the case of (B) in FIG. 9, the matching request 1[A] is stored in the buffer BU[A], so as shown in (C) in FIG. ] and matching request 2 [all].

Next, in (C) of FIG. 9, the processing for the matching request 3[B] dequeued from the queue QU3 is as follows. For the dequeued matching request 3[B], the matching requests stored in the buffer BU[B] and the buffer BU[all] are matched. The server 30 checks whether a matching request is stored in any of the target buffers BU[B] and BU[all]. The confirmation order in this case is, for example, random. Note that a priority may be set in advance so that either buffer BU[B] or buffer BU[all] is preferentially checked. In the case of (C) in FIG. 9, since no matching request is stored in the target buffer BU[B] or buffer BU[all], as shown in (D) in FIG. 3[B] is temporarily stored in the buffer BU[B], and waits for matching with matching requests to be dequeued thereafter.

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

Next, in (E) of FIG. 9, the processing for the matching request 5[all] dequeued from the queue QU3 is as follows. For the dequeued matching request 5[all], matching requests stored in all buffers BU[A], BU[B], and BU[all] are matched. In the case of (E) in FIG. 9, matching request 4[A] is stored in buffer BU[A] and matching request 3[B] is stored in buffer BU[B]. , and matching request 5[all] may be matched. For example, if the buffer BU[A] is confirmed (searched) first, the server 30 matches the user of matching request 4[A] with the user of matching request 5[all]. On the other hand, if buffer BU[B] is confirmed (searched) first, as shown in FIG. to match.

The matching process described above is an example, and the present invention is not limited to this, and various matching processes based on existing algorithms can be applied.

In addition, when matching users who have set both the use order condition and the number of innings condition to "Random", for example, the use order and the number of innings may be determined randomly, or may be set in advance. The order of use and the number of innings may be determined according to priority.

In addition, in the above-mentioned matching process, matching priority setting such as preferential matching of users with similar game levels and team ranks is not performed, but such matching priority setting is performed. may For example, users whose total number of real-time matches, cumulative winning rate, or recent winning rate (for example, winning rate in the last 10 games, winning rate in the last week, etc.) are within a predetermined range may be preferentially matched. . Also, users whose team rank in the CPU battle mode (that is, another game mode) is within a predetermined range may be preferentially matched.

The server 30 transmits matching information to the game terminals of both users with whom matching has been established. The matching information includes information on game conditions under which matching is established and information on opponents. Here, the information of the game conditions for which matching is established is the use order condition and the number of innings condition in this embodiment. The opponent's information includes the opponent's user name, the use order corresponding to the game conditions in which matching is established, the leader character, the communication strength, the first attack or second attack information, and the like. The leader character and communication strength will be described later.

A pre-fight confirmation screen G600 illustrated in FIG. In FIG. 7, it is assumed that the server 30 matches the user with the opponent user (whose user name is User B), and the user is determined to go first and the opponent to go second.

Information about the user and information about the opponent are displayed on the pre-fight confirmation screen G600. The user information includes a user name P611, a 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 possessed by the user. Note that, for example, a predetermined character in the user's team, such as the character of the fourth batter ordered to be used or the character of the starting pitcher, may be automatically set as the leader character.

The communication strength information P613 indicates the radio field strength of wireless communication of the user's game terminal 10 (for example, the radio field strength with respect to a mobile communication base station, or the radio field strength with respect to a wireless network access point or router, etc.). It is a visualization. In the present embodiment, an example is shown in which an antenna icon that visualizes the radio wave intensity in multiple stages (eg, 5 stages) is displayed as the communication intensity information P613. The communication strength information P613 may be displayed using numerical values, symbols, characters (for example, weak, weak, normal, strong, and strongest). For example, a Received Signal Strength Indicator (RSSI) value measured by a game terminal 10 having a wireless communication function such as a smartphone can be applied as the communication strength information P613.

The information about the opponent displayed on the pre-fight confirmation screen G600 includes the opponent's user name P621, the leader character image P622, and the communication strength information P623.

For example, when transmitting a matching request from the game terminal 10 of each user, the matching request includes information on the current communication strength and is transmitted to the server 30 . Then, when the server 30 transmits matching information to both users for whom matching has been established, the matching information may include information on the communication strength of both users (at least information on the communication strength of the other user). good.

Alternatively, the game terminals 10 of both users that have received the matching information from the server 30 directly communicate with each other through a P2P connection or the like, and exchange information on their communication strengths in real time at regular intervals to display the pre-fight confirmation screen. Information P623 of the opponent's communication strength may be displayed in G600. For example, the game terminals 10 of both matched users measure the communication strength of their own terminals at regular intervals (for example, every 1 frame: every 1/60th of a second), and send information on the measured communication strength to each other. Send. 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 in the pre-fight confirmation screen G600.

Alternatively, it is possible to exchange data between the game terminals 10 of the two matched users via the server 30, and exchange information on the communication strength between each other via the server 30 in real time at regular intervals. You can match. In this case as well, as in the case of direct communication by P2P connection or the like, information P613 on the communication strength of the user's own game terminal 10 and information P623 on the communication strength of the opponent's game terminal 10 are displayed on the pre-fight confirmation screen G600. is updated at regular intervals.

The user confirms the communication strength information P613 of the user's own game terminal 10 or the communication strength information P623 of the opponent's game terminal 10 displayed on the pre-fight confirmation screen G600, and starts a match with the matched opponent. can be determined whether to start

In addition to the above information, the information about the user and the information about the opponent displayed on the pre-fight confirmation screen G600 include, for example, the game level of the user and the opponent, the team rank, the total number of real-time battles, the total number of real-time battles, Information such as win rate or most recent win rate may be included.

In addition, information P631 of the game conditions under which matching is established (in the example of FIG. 7, the use of an event character order and the number of innings is up to three innings) is displayed on the pre-fight confirmation screen G600. The pre-fight confirmation screen G600 also displays a 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 matching is established (for example, after the pre-match confirmation screen G600 is displayed), the match with the matched opponent is automatically canceled. be done. If the user taps the return button B640 even within the time limit, the battle is canceled and the real-time battle top screen G300 of FIG. 4 is returned to. When both of the matched users tap the match start button B632 within the time limit, the match under the matching game conditions is started. In this competition, both users use orders corresponding to game conditions in which matching is established. In the example of FIG. 7, since the matching game condition of using the event character order is established, a battle using the event character order is executed.

When the battle ends, the result of the battle is displayed on the display section 17. - 特許庁Also, both users are given rewards such as points and items according to the result of the battle. Also, a league ranking reflecting the given points may be displayed. After the battle, the user can save the content of the current battle as a replay by performing a predetermined operation. There is an upper limit to the number of replays that can be saved, and if the limit is exceeded, the oldest replay will be deleted.

When operations such as receiving the reward and saving the replay are completed, the screen transitions to the top screen G300 of the real-time battle shown in FIG. The top screen G300 includes a battle record confirmation button B305, a replay button B306, and a return button B307. When the user taps the battle record confirmation button B305, the screen transitions to a screen displaying the battle record of real-time battles so far. When the user taps the replay button button B306, the screen transitions to a screen displaying a list of replays that can be played. When the user selects a Replay from within the list, the selected Replay is played. When the user taps the return button B307, the screen transitions to the home screen of this game where various game modes can be selected.

[3. Functional Configuration of Game System]
FIG. 10 is a schematic functional block diagram showing an example of the functional configuration of the game system 1. As shown in FIG. As shown in FIG. 10, game system 1 includes data storage section 100 . For example, the data storage unit 100 is implemented by at least one of the database DB, ROM12, RAM13, auxiliary storage device 14, ROM32, RAM33, and auxiliary storage device . The data storage unit 100 stores data necessary for providing games.

As a specific example of the data stored in the data storage unit 100, data necessary for providing the baseball game described above will be described. The data storage unit 100 stores a user information table TBL101, a character information table TBL102, a game condition table TBL103, a team order table TBL104, possessed character data DT105, team order data DT106, and the like. Since the character information table TBL102 (see FIG. 8) has already been explained, the explanation thereof is omitted here.

For example, various data for executing a game stored in the data storage unit 100 are stored in the database DB or the auxiliary storage device 34 of the server 30, and when the game terminal 10 accesses the server 30, Required data can be downloaded to the RAM 13 or the auxiliary storage device 14 of the game terminal 10 . In addition, information about the results of games executed on the game terminal 10 and changes in data is transmitted from the game terminal 10 to the server 30 in real time or at a predetermined timing, and stored in the database DB or the auxiliary storage device 34 of the server 30. The stored data can be updated accordingly. Further, for example, necessary data is stored in the auxiliary storage device 14 of the game terminal 10 or the like so that at least a part of the game can be executed offline without logging in to the server 30 at the game terminal 10 of each user. You can leave it as is.

FIG. 11 shows an example of the user information table TBL101. The example of FIG. 11 shows the user information table TBL101 in which the user information for one user with the user ID "U1" is stored. The TBL 101 is stored in the data storage unit 100 (for example, database DB, auxiliary storage device 34, etc.) of the game system 1 . User information associated with the user ID of the user is stored in the storage device (for example, the auxiliary storage device 14 or the like) of the game terminal 10 of the user.

The user information table TBL101 includes fields such as "user ID", "user name", "training mode", "CPU battle mode", and "real time battle mode". "User ID" is identification information for uniquely identifying each user. The "username" field indicates the name of the user. Various information about each game mode is stored in the "training mode", "CPU battle mode" and "real time battle mode" fields. For example, the "training mode" field stores information on the main character currently being trained, information on the event deck (ID of the event character set in the event deck, etc.), information on the current turn, and the like. For example, in the "CPU battle mode" field, information such as current league level, total points, league ranking, etc. is stored. For example, in the "real-time battle mode" field, currently saved matching condition setting information, battle record information, replay information, and the like are stored.

Regarding the matching condition setting information, for example, the matching condition setting information applied in the previous matching is saved, and if the user does not change the condition setting in the next matching, the previous matching condition setting is applied. You may do so. Alternatively, default condition settings (for example, use order “Random”, number of innings “Random”) may be applied each time matching is performed, and the user may change the condition settings as necessary.

Although omitted in FIG. 11, other fields are also included in the user information table TBL101. For example, the user information table TBL101 includes fields for various points in the game owned by the user and user IDs of other users (friends, friends, etc.) associated with the user's user ID.

FIG. 12 shows an example of the game condition table TBL103. This game condition table TBL103 is a master table regarding game conditions for matching. The game condition table TBL103 includes fields of "condition type", "game condition ID" and "game condition". In the example of the baseball game described above, the "use order" and "number of innings" are set in the "condition type" field. "Game condition ID" is identification information for uniquely identifying each game condition. Information on game conditions is stored in the "game conditions" field.

FIG. 13 shows an example of the team order table TBL104. This team order table TBL104 is a master table regarding team orders that can be set in this game. The team order table TBL104 includes fields of "order ID", "team order name", "corresponding game condition" and "corresponding league". "Order ID" is identification information for uniquely identifying each team order. Information on the team order name is stored in the "team order name" field. The "corresponding game condition" field stores information on the matching game condition (for example, game condition ID) associated with the team order. The "corresponding league" field is associated with the in-game league associated with the team order.

FIG. 14 shows an example of possessed character data DT105. This possessed character data DT105 is data indicating information of a character possessed by the user (that is, a character associated with the user's user ID). The example of FIG. 14 shows possessed character data DT105 in which information for one person associated with user ID "U1" is stored. Possessed character data DT105 is stored in the data storage unit 100. FIG.

In possessed character data DT105, event characters and training players are separately managed. Possessed character data DT105 includes fields such as "character ID", "profile ID", "ability parameter" and "level". “Character ID” is identification information that uniquely identifies a character possessed by the user. For example, a user may acquire a plurality of event characters with the same name and the same rarity through lottery or the like. In this case, the profile IDs of the plurality of event characters are all the same, but different character IDs are assigned to them and associated with the user ID. In the "parameter" field, information on various parameters such as ability parameters of each character is stored. Parameters that have changed after obtaining the character are also reflected in the "parameter" field.

FIG. 15 shows an example of team order data DT106. The team order data DT106 is data of a plurality of team orders set in this game. The example of the baseball game described above includes an event character order (order ID: OD1) and a training player order (order ID: OD2). User team data DT106 is stored for each user (associated with the user ID). The user team data DT106 includes character IDs of pitcher members (starting pitcher, middle pitcher, closing pitcher) and fielder members (starting member and backup). The user team data DT106 also includes position information and batting order information within the team set based on the user's operation (or automatically set by the game system 1).

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

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 .

The registration unit 111 has a function of registering a plurality of usage targets including at least one object based on a user's operation.

Here, the "user" is, for example, 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 the game terminal 10 operated by each user, and each user is identified (specified) by the user identification information.

Also, the "object" is something that can be used in a game. For example, a game character, a game card (digital card), a game item, or the like corresponds to an example of the "object". For example, people such as athletes, creatures such as racehorses, personified creatures such as racehorses, fictional characters and creatures such as monsters, game characters representing non-living things such as robots, cars, motorcycles, bicycles, etc. A game card corresponds to an example of an "object". Also, for example, an equipment item equipped on a character corresponds to an example of an “object”. For example, the "object" may be a game character or game card corresponding to a real person or creature, or may not be a real person or the like.

Also, the "usable object" is an object that can be used by a user in a game executed by matching, and includes at least one object.
The game executed by matching may be, for example, a competitive game in which users "compete", or a multiplayer game (also referred to as a multiplayer game) in which "cooperative play" by a plurality of users is possible. may

Here, a "competitive game" is, for example, a computer game in which a user competes with an opponent to determine the winner or loser. For example, an online competitive game played between game terminals 10 of a plurality of users connected via a network corresponds to an example of a "competitive game". Here, the term "competition" refers to determining superiority, victory or defeat, ranking, etc. with an opponent. The result of the competitive game does not necessarily have to be a victory or defeat, and may result in a draw. Matches in sports games, races of horse races, cars, motorcycles, bicycles, etc., battles in fighting games, etc., correspond to examples of "battles".

A user's opponent may be one user, or may be two or more. It may be a one-to-one match, a one-to-many match, or a many-to-many match.
For example, the above-mentioned baseball game in which two users each play a match using a plurality of player characters of their own baseball team corresponds to an example of a "fight game". Also, for example, a game in which three or more users fight using their own objects in the same game space corresponds to an example of a "battle game." For example, in a horse racing game, a game in which a plurality of users compete for rank by having their own racehorse characters run within a predetermined number corresponds to an example of a "fighting game."

Regarding the above-mentioned "use object", for example, in the case of a game in which the user uses one object to play against an opponent, the one object corresponds to an example of the "use object". For example, a player character used in a homerun competition in a baseball game corresponds to an example of a "use target." Further, when competing in a horse race, a racehorse character used in a horse race, a personified character of a racehorse, or a jug character riding a racehorse corresponds to an example of the 'use object'. Further, when competing in a car race, a racing car character used in a car race or a driver character riding in a racing car corresponds to an example of the "use target".

Also, for example, in the case of a game in which the user uses two or more objects to play with a player such as an opponent, the two or more objects or a group (deck, team, group, corps, party, guild, etc.) correspond to an example of the "use target". The "usage target" may be a group such as a deck or team composed of a predetermined number of objects, or may be composed of objects within a predetermined number (a user can arbitrarily set between 1 and a predetermined number). may be a group consisting of a predetermined number or more of objects, or a group consisting of n or more and m or less objects (where n and m are any natural numbers equal to or greater than 1). It can be a group.
For example, in the case of the baseball game described above, a team composed of a predetermined number (for example, 25) player characters (training players or event characters) corresponds to an example of the "usage target". A team order including information on the batting order and defensive positions of a predetermined number of player characters is also an example of the "use target". Further, in the case of a horse race or car race, a deck composed of racehorse characters or racing car characters within a predetermined number (for example, within three) who participate in the race corresponds to an example of the "use target".

Regarding the "user operation" in the registration unit 111, a user operation for registering a plurality of usage targets can be performed at an arbitrary timing before a matching request is made. For example, on the player-to-be-trained order edit screen G400 illustrated in FIG. 5, operating the auto button B421 to automatically register a player-to-be-developed order to be used also corresponds to an example of "user operation". In addition, the information on the used object once registered may be saved, and the same registered information on the used object may be repeatedly applied in multiple matchings until the user changes (edits) the used object.

In the example of the baseball game described above, the registration unit 111, based on the user's operation, creates a training player order (an example of a target to be used) consisting of a predetermined number (for example, 25) of training players and a predetermined number (for example, 25) of training players. An event character order (an example of an object to be used) composed of an event character (name) is stored and registered in a storage device (eg, auxiliary storage device 14, auxiliary storage device 34, database DB, etc.). The number of usage targets registered by the registration unit 111 may be three or more.

A plurality of use objects registered by the registration unit 111 correspond to game conditions used for matching. For example, as shown in FIG. 13, event character order (order ID: OD1) is associated with event character order usage conditions (game condition ID: GA1). Also, the training player order (order ID: OD2) is associated with the training player order use condition (game condition ID: GA2).

The condition setting unit 112 has a function of enabling setting of any two or more of a plurality of game conditions respectively corresponding to the plurality of use objects, based on a user's operation. In the example of the baseball game described above, the condition setting unit 112 sets two game conditions (use event character order, training player order) corresponding to the event character order and training player order as two objects to be used, as shown in FIG. It is possible to set the conditions of "Random" that any of (order use) can be used.

Here, the "game condition" is a condition regarding a game executed by matching, which can be set when the user searches for a matching partner. This "game condition" may also be referred to as a "matching condition", a "search condition", or the like.
For example, if there are a plurality of leagues in which the user can participate, each league that the user wishes to participate in may be set as a "game condition". For example, if two leagues are set, only one or two of them (any of them) may be set as "game conditions". Also, for example, if three leagues are set, only one, two (any of them), or three (any of them) may be set as "game conditions". . The same applies when four or more leagues are set. The same applies to game conditions other than leagues.
For example, if a plurality of decks corresponding to a plurality of leagues are registered in advance, each deck that the user wishes to use may be set as a "game condition".

As described above, the condition setting unit 112 also enables the condition setting in which any one of the plurality of game conditions respectively corresponding to the plurality of use objects is designated based on the user's operation.

In addition, various conditions can be set in the "game condition". For example, in the case of a baseball game, the number of innings in the game (for example, the bottom of the 3rd, the bottom of the 6th, the bottom of the 9th, etc.), the weather (such as fine, cloudy, rainy, snowy, etc.), the season (such as spring) , summer, autumn, winter), stadium (for example, one or more virtual stadiums corresponding to the stadiums of each Japanese professional baseball team can be selected), user level, team rank, player character parameters (for example, ability rank ) or the like may be set as the “game condition” so that the user can search for a matching partner.
Also, each scenario applied to the breeding described above (only one of a plurality of scenarios, or any of two or more) may be set as a "game condition".
For example, in the case of a game themed on real sports, objects corresponding to real players (eg player characters, digital cards) are used in the game. In such a case, even objects with the same player name may have different ability parameters depending on when the user obtained them through lottery (so-called gacha) or the like. For example, player character A in the “2021 series” and player character A in the “2022 series” have the same player name but different ability parameter values. Therefore, it may be possible to set the difference in acquisition timing of an object associated with an object (or timing of gacha, series name indicating acquisition timing, etc.) as a "game condition".
Also, for example, even objects with the same player name corresponding to a real player may have different ability parameter values depending on the object type. For example, an object type A in which the actual player's performance in the current season is reflected in the ability parameter, an object type B in which the actual player's performance in the past when he was in the limelight is reflected in the ability parameter, and a career record of the actual player. The object type C or the like reflects the moment of the moment in the ability parameter. Therefore, the difference in the "object type" associated with the object may be set as the "game condition".
Further, for example, in the lottery acquisition mode, a plurality of gachas of different types may be provided so that the object type that the user can obtain (or that is easier to obtain) differs depending on the type of gacha to be executed. Examples of different types of gacha include a type of gacha that can be executed by consuming billable items or points, a type of gacha that can be executed by consuming items or points that are not billable, and only a specific object type. There are types of gachas that are targeted for lottery, gachas that exclude only specific object types from the lottery, and gachas that increase (or decrease) the lottery probability of specific object types. Therefore, the difference in the "type of gacha" associated with the object (in other words, the variation in the acquisition route of the object) may be set as the "game condition".
In the case of a race in a horse racing game, race names (for example, multiple race names corresponding to multiple race names that actually exist), riding grounds (for example, turf, dirt), distances (for example, short distance, mile, middle distance, long distance) , or a specific numerical distance such as 1200m, 1600m), the venue (for example, multiple virtual venues in the game that correspond to multiple venues on a real racecourse), course features (for example, right Round, counterclockwise, straight, inner circle, outer circle, 1st outer circle 2nd inner circle, no inner and outer circle), track condition (ex. good, slightly heavy, heavy, bad, etc.), weather (ex. fine, cloudy, rain, snow, etc.) ), season (e.g. spring, summer, autumn, winter), user level, team rank, racehorse character parameters (e.g. ability rank), etc. are set as "game conditions", and the user can search for a matching partner. You may make it possible.

The above-mentioned "plurality of game conditions respectively corresponding to the plural use objects" means that plural use objects (for example, team orders, decks, etc.) respectively corresponding to the plural game conditions are registered. .

Further, the above-mentioned "condition setting that allows any of two or more of the plurality of game conditions" includes "condition setting that allows any of the plurality of game conditions" and "part of the plurality of game conditions ( 2 or more)".
For example, if there are two game conditions respectively corresponding to the two registered usage objects, the condition setting that any game condition can be used is "a condition that any two or more of the plurality of game conditions can be used. This is an example of "Settings".
Further, for example, when there are three game conditions respectively corresponding to the three registered use objects, the condition setting that any of the three game conditions may be used is not the same as the condition setting for any two of the three game conditions. is an example of "condition setting in which any one of two or more of a plurality of game conditions is acceptable". The same is true when there are four or more game conditions respectively corresponding to four or more registered use objects.

Modes that enable the setting of conditions as described above include the following mode.
In addition to options for selecting each of a plurality of game conditions, specific options such as "random", "any", "no specification", and "random" are provided, and the user selects the specific options. By making a selection, it may be possible to "set any of a plurality of game conditions". An example of this is setting the use order conditions by selecting the option P511 of "automatically" on the search setting screen G500 of FIG.

In addition, by allowing the user to simultaneously select a plurality of options for a plurality of matching conditions, it is possible to "set a condition that any of the plurality of matching conditions may be used" or "among a portion (two or more) of a plurality of game conditions It may be possible to set a condition that any of An example of this is shown in FIG. The search setting screen G700 of FIG. 16 is a modified example of the search setting screen G500 of FIG. 6, and components having the same function are given the same member numbers. The search setting screen G700 includes a participating league condition setting area A710, an innings condition setting area A720, and a weather condition setting area A730. The participating league condition setting area A710 includes an option P711 of participating in the event character league and an option 712 of participating in the training player league. The user may select either one of the options P711 and P712, or may select both options P711 and P712 at the same time as in the example of FIG. It has the same meaning as selecting the "Omakase" option. The innings condition setting area A720 includes three game condition options P721 to P723. If the options 721 and P722 are selected as in the example of FIG. It is possible to set a condition that any one of them is acceptable. The weather condition setting area A730 includes a sunny option P731 and a rainy option 732, and as in the example of FIG. 16, only one option may be selected.

FIG. 17 shows an example of the team order table TBL204 corresponding to the example of FIG. FIG. 17 shows an example in which a total of 6 team orders, ie, 3 event character orders and 3 training player orders, can be registered.
"Eve-chara order 1 (order ID: OD11)" is associated with the compound condition of "participating in the event-chara league (game condition ID: GC1)" and "up to three innings (game condition ID: GB1)". ing. "Event character order 2 (order ID: OD12)" is associated with the compound condition of "participation in event character league (game condition ID: GC1)" and "up to 6 innings (game condition ID: GB2)". ing. "Eve-chara order 3 (order ID: OD13)" is associated with the compound condition of "participating in the event-chara league (game condition ID: GC1)" and "up to the bottom of the ninth inning (game condition ID: GB3)". ing. In this manner, a plurality of objects of the same type (team orders, decks, etc.) composed of objects of the same type (here, event characters) may be registered.
The "training player order 1 (order ID: OD21)" is associated with the compound condition of "training player league participation (game condition ID: GC2)" and "up to 3 innings (game condition ID: GB1)". ing. The "training player order 2 (order ID: OD22)" is associated with the compound condition of "training player league participation (game condition ID: GC2)" and "up to 6 innings (game condition ID: GB2)". ing. The "training player order 3 (order ID: OD23)" is associated with the compound condition of "training player league participation (game condition ID: GC2)" and "up to the bottom of the ninth inning (game condition ID: GB3)". ing.
Although an example of a compound condition including two game conditions is shown above, a compound condition including three or more game conditions may be used.

In the example of FIG. 17, the three event character orders 1 to 3 are each associated with the aforementioned compound conditions, but they may be associated with individual game conditions. For example, in the case of a battle mode in which players can only participate in the event character league (there is no training player league), "training player order 1" is associated with a single game condition of "up to 3 innings", and "training player order 2 ” may be associated with the single game condition “until the bottom of the 6th inning”, and “training player order 3” may be associated with the single game condition of “up to the bottom of the 9th inning”. As the number of innings in a game increases, the stamina ability of each player and the roles of intermediate pitchers, closing pitchers, and substitute hitters (reserves) become more important, so multiple team orders are made according to the number of innings in the game. You may enable registration.

The matching unit 113 selects the play partner of the user based on the matching request accompanied by the condition setting (including the condition setting that any of two or more game conditions corresponding to the plurality of usage targets may be set). It has a function to match As described above, various existing algorithms can be applied to the matching processing by the matching unit 113 .
Here, the "play partner" is another user (or another user's game terminal 10) who plays with the user in the game executed by matching. In the case of a competitive game, another user of the opponent corresponds to an example of the "play partner". The “playing partner” may be not only one person but also a plurality of persons.

The game execution unit 114 has a function of executing a game using the use object corresponding to the game condition for which the matching is established.
In the example of the aforementioned baseball game in which two team orders can be registered as illustrated in FIG. ), a match using the event character order corresponding to the game condition is executed. The same game conditions are applied to the opponent's game terminal 10, and the event character order registered by the opponent's user is used for the battle with the user. The same is true when matching is established under the game condition of "use breeding order" (the condition for the number of innings may be any).

Further, in the example of the baseball game described above in which six team orders can be registered as illustrated in FIG. If it is established (any weather condition in FIG. 16 is acceptable), a battle using "Eve character order 1" corresponding to the game condition is executed. Similarly, when matching is established under other game conditions stored in the "corresponding game conditions" field in FIG. The match used is executed.

The game condition of the number of innings in the example of FIG. 6 can be included in the matching condition setting, but is not associated with the event character order and training player order (see FIG. 13). Also, the weather game condition in the example of FIG. 16 can be included in the matching condition setting, but it is not associated with the event character order and training player order (see FIG. 17). As in these examples, the condition setting unit 112 may allow the condition setting to include another game condition different from the game condition corresponding to the use object.

The “game using the use object” executed by the game execution unit 114 may be, for example, a game in which the user and the play partner operate the use object by themselves. In addition, the above-mentioned "game using the use object" is, for example, a computer (CPU 11 or CPU 31) executing simulation processing based on the object used by the user and the object used by the play opponent, such as a battle. The game may be a game in which the progress of the game is automatically determined, and the user and the play partner operate their own objects only in specific scenes. To give an example, in a baseball game, the game basically progresses in an automatic progression part, and only an overview of the progress of the game (points of the game) is displayed on the screen. Then, only when the game situation becomes a predetermined situation (for example, a situation in which a runner is on third base or second base) during the automatic progress part, the automatic progress part is switched to the action part, and the user and the play partner operate the player characters. I do.

In addition, in the above-mentioned "game using the object to be used", for example, the computer executes a simulation process based on the object to be used by the user and the object to be used by the play opponent, so that the match result is automatically determined. It may be a game that is played. As an example, in a horse race game, a racehorse character to be used by a user (may be plural) and a racehorse character to be used by a play partner (may be plural) are used. ) will run in the race under the game conditions for which matching has been established, and the progress of the race and results such as the order of finish will be automatically determined by the computer based on the parameters of each racehorse character. In this case, the user may be allowed to perform an operation of setting a strategy (escape, lead, lead, rush, etc.) for each racehorse character to be used before starting the race.

In addition, the game may set a plurality of in-game leagues in which the user can participate. In the example of the baseball game described above, a "training player league" and an "event character league" are provided.
Here, the above-mentioned "in-game league" is a league that is virtually provided in the game and in which users can play games such as matches and races. A plurality of in-game leagues are provided, and the user can participate in any league. The “in-game league” may be a “stage” that is provided in the game and that the user can participate in at will.

The registration unit 111 has a function of registering a plurality of usage objects respectively corresponding to the plurality of in-game leagues based on a user's operation. In the example of the baseball game described above, the registration unit 111 stores "training player orders" and "event character orders" corresponding to the "training player league" and "event character league", respectively, based on the user's operation. to store and register.

Here, as described above, a plurality of use objects can be associated with a plurality of game conditions, respectively, so that matching is established with the condition setting of "Random", and the use object corresponding to the established game condition is used. As a result, the game in which the player participates in the in-game league corresponding to the use object is executed.

In addition, the game condition may include "the in-game league that the user wants to participate in" or "the usage target corresponding to the in-game league that the user wants to use".
In the example of the baseball game described above, the game conditions for the participation league (event character league or training player league) in FIG. In addition, the game condition of the use order (event character order or training player order) in FIG. 6 corresponds to an example of the game condition of "use object corresponding to in-game league that user wants to use".

Then, the condition setting unit 112 sets a condition that any two or more of the plurality of in-game leagues may be set based on the user's operation, or sets a plurality of the plurality of in-game leagues corresponding to each of the plurality of in-game leagues. It may be possible to set a condition that any one of two or more of the objects to be used may be used.
In the example of the baseball game described above, as shown in FIG. 16, by selecting both of the two options for participating leagues (event character league or training player league), it is possible to set a condition that either is acceptable. Also, as shown in FIG. 6, it is possible to set a condition that any order can be used by selecting an option of "Random" for the use order (event character order or training player order).

Each user registers usage objects (orders, decks, etc.) corresponding to each of multiple in-game leagues, and also uses matching play partners (other users) and usage corresponding to in-game leagues in the same in-game league Play a game with an object. Therefore, the game condition "the in-game league that the user wants to participate in" has the same meaning as the game condition "use object corresponding to the in-game league that the user wants to use".

Further, the objects included in the usage target may include at least a first object and a second object of different types. In the example of the baseball game described above, the training player is an example of the first object, and the event character is an example of the second object.

Here, with respect to the above-mentioned "first object and second object of different types", examples of the difference in the types of objects are (1) the difference in acquisition route by which the user acquires the object (for example, the object raised by playing the game) (2) Differences in usage (for example, in a predetermined mode in the game, it may be used as an object to be operated or an object not to be operated) (3) Differences in changeability of parameters after acquisition (for example, whether or not parameters can be changed by processing such as strengthening), (4) Differences in changeable parameters, and the like.

The plurality of usage objects may include at least a first usage object to which the first object is registered and a second usage object to which the second object is registered. In the example of the baseball game described above, the training player order in which the training player is registered is an example of the "first use object", and the event character order in which the event character is registered is an example of the "second use object".

Further, the first object constituting the first use object may be associated with a breeding object trained by changing or setting a parameter and user identification information.

Here, "parameters of an object" are parameters set in an object. In other words, a "parameter of an object" is a parameter associated with an object. A "parameter of an object" may or may not be a numeric parameter. For example, a parameter (for example, a total ability value, a level, etc.) indicating the overall ability or performance of an object corresponds to an example of the "object parameter". Also, for example, a parameter indicating the level of a specific ability or performance of an object (for example, offensive power, defensive power, etc.) corresponds to an example of an "object parameter." Also, for example, a parameter (for example, an experience value, etc.) necessary for improving the ability or performance of an object corresponds to an example of an "object parameter." Also, for example, a parameter indicating the state of the object (for example, fatigue level, motivation, etc.) corresponds to an example of the "object parameter". Also, for example, a rarity level indicating the rarity of an object corresponds to an example of an "object parameter." Also, for example, information on the special ability possessed by the object corresponds to an example of the "parameter of the object". Also, for example, body shape information (height, weight, leg length, hand size, etc.), sex information, etc. of the object may be included in the "parameters of the object".

Also, "changing a parameter" means changing a parameter set in an object. For example, improving or lowering a parameter set for an object corresponds to an example of "changing a parameter."

Also, "setting a parameter" means, for example, setting a parameter that has not yet been set to the object to the object. For example, adding a special ability that the object did not have to the object (for example, associating information about the special ability with the object) corresponds to an example of "setting a parameter."

In the example of the baseball game described above, the first object that constitutes the training player order as the first object to be used is a training player (an example of a training object) trained by changing or setting a parameter and a user ID associated with each other. (ie, a training player possessed by the user).

Further, the second object constituting the second use object may be associated with at least one second object determined by lottery from among a plurality of second objects and user identification information.

In the example of the baseball game described above, the second object constituting the event character order as the second use object is at least one event character determined by lottery from among the plurality of event characters managed in the game. It is associated with the user ID (that is, the event character possessed by the user).

According to the above configuration, it is possible to register two different types of use objects, training player orders and event character orders, in correspondence with game conditions. Here, there is a tendency that the higher the game proficiency (degree of engagement) the user can train training players with higher parameters, and the user who has just started the game can only create training player orders for training players with relatively low abilities. do not have. In that case, it is expected that fewer users will participate in the training player league that uses the training player order, since users with high levels of game proficiency are too strong. On the other hand, event characters that can be obtained by lottery may be obtained by anyone with relatively high parameters regardless of the user's game proficiency level. Therefore, even a user who has just started playing the game can create an event character order with a certain level of strength. In this way, by making it possible to register training player orders and event character orders of different types in association with different game conditions, it becomes easier for various users to participate in the game regardless of their level of proficiency in the game. will also increase opportunities for

Also, the second object associated with the user identification information may be usable as an auxiliary object for changing or setting the parameters of the first object in training the first object.

Here, the "auxiliary object" is an object that is used in an auxiliary way to affect the parameters of other objects used in the game. For example, the "supporting object" is a so-called "non-player character" that is not directly operated by the user in the game, but affects the parameters of the "player character" that is the target of the operation. For example, if one or more second objects are set in the deck before starting the training of the first object, an event corresponding to the second object occurs during training, and the parameters of the first object are generated based on the event. is changed or set, the second object corresponds to an example of an "auxiliary object".
Also, the "auxiliary object" may be associated with another object to change or set parameters of the other object. For example, a character that is associated with a first object as a coach or trainer and improves the parameters of the selected first object corresponds to an example of a "supporting object." Also, for example, an equipped item that is equipped (associated) with a first object and produces an effect of improving the parameter of the selected first object corresponds to an example of the "supporting object".

In the example of the baseball game described above, the event character for changing or setting the ability parameters of the trained player in the training mode corresponds to an example of the "supporting object." According to this configuration, the event character possessed by the user is used not only in the battle mode involving matching, but also as an assisting object in the training of training players. As a result, it is possible to effectively suppress the increase in the number of characters in the game and effectively utilize character resources.

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

FIG. 18 is a flow chart showing an example of processing of the game system 1 that executes the real-time battle mode described above. Also, FIG. 19 is a sequence chart showing an example of processing of the game system 1 that executes the real-time battle mode. In the processing described below, a game program stored in a storage device (ROM 12, RAM 13, auxiliary storage device 14, ROM 32, RAM 33, or auxiliary storage device 34, etc.) is executed by the control unit 110 (CPU 11 of the game terminal 10 or server 30 is realized by the execution of the CPU 31).

Here, as an example, an example will be described in which the server 30 mainly executes the matching process, and each user's game terminal 10 mainly executes other than the matching process. Therefore, it is assumed that the processing illustrated in FIG. 18 is executed by the CPU 11 of the game terminal 10 of each user.

In S100, the CPU 11 stores and registers training player orders 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 player-to-be-trained order edit button B301 on the top screen G300 of the real-time battle mode illustrated in FIG. 4 to open the player-to-be-trained order edit screen G400 illustrated in FIG. 5, edit and register the player-to-be-trained order. This registration of training player orders is possible at any time before the matching request (S106 in FIG. 18).

Once registered, information on player-to-be-developed orders is stored in a non-volatile storage device, so if the user does not change the player-to-be-developed order in subsequent matching, the registered player-to-be-developed order will be applied. become. Therefore, the user does not necessarily need to edit the training player order each time matching is performed. For example, the user may edit the player-to-be-trained order when a player with high ability is trained in the training mode.

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 tap the event character order edit button B302 on the top screen G300 of FIG. 4 to open the event character order edit screen, edit and register the event character order. This event character order registration is also possible at any time before the matching request (S106 in FIG. 18).

As with training player orders, once registered event character order information is stored in a non-volatile storage device, so if the user does not change the event character order in subsequent matching, the registered event character order will be deleted. Character order is applied. Therefore, the user does not necessarily have to edit the event character order each time matching is performed. For example, the user may edit the event character order when obtaining an event character of high rarity in the lottery acquisition mode or when increasing the level of the event character in the strengthening mode.

In S104, the CPU 11 stores and registers matching condition setting 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 of FIG. 4 to open the search setting screen G500 illustrated in FIG. 6, set and register matching game conditions. This matching condition setting is also possible at any time before the matching request (S106 in FIG. 18).

In the game of the present embodiment, the use order and the number of innings can be set as matching game conditions (matching partner search conditions). Regarding the conditions of the use order, it is possible to set the condition by selecting the option P511 of "Random", which indicates that the order to be used in the match can be either a training player order or an event character order (see FIG. 6). Also, it is possible to set a condition in which only one of the training player order and the event character order is designated as the use order.

Once registered, the matching condition setting information is stored in a non-volatile storage device, so if the user does not change the condition setting in subsequent matching, the registered condition setting will be applied. You may do so. In this case, the user does not necessarily have to set matching conditions each time matching is performed, and the user may change the condition settings as necessary. Alternatively, basically default condition settings (for example, use order "Random", number of innings "Random") are basically applied each time matching is performed, and the user changes the condition settings as necessary before requesting matching. good too.

The processing order of S100, S102, and S104 is not limited to this, and any processing may be executed first.

In S<b>106 , the CPU 11 transmits to the server 30 a matching request accompanied by the setting of matching conditions. By tapping the matching button B304 on the top screen G300 of FIG. 4, the user can make a matching request accompanied by the matching condition setting. The matching request data transmitted from the game terminal 10 to the server 30 includes the condition setting information and the user ID. Also, the matching request may include information such as the aforementioned communication strength.

After transmitting the matching request to the server 30, the game terminal 10 enters a standby state until matching is established.

Here, the sequence chart of FIG. 19 is also used for explanation. FIG. 19 shows an example of processing when matching is performed between the game terminal 10-1 of the user with the user ID: U1 and the game terminal 10-2 of the user with the user ID: U2.

Hereinafter, the user with user ID: U1 is called "user A", and the user with user ID: U2 is called "user B". In addition, it is assumed that user A has set the conditions for the use order "Random", and user B has set conditions specifying either one of training player order or event character order.

At user A's game terminal 10-1 and user B's game terminal 10-2, matching requests with the above-described condition settings are sent to server 30 (S200-1 and S200-2). Server 30 receives matching requests from a plurality of game terminals 10-n including game terminals 10-1 and 10-2, and executes matching processing (S300). It is assumed that matching between user A's game terminal 10-1 and user B's game terminal 10-2 is established by this matching process. In this case, the server 30 sends the game terminal 10-1 of the user A and the game terminal 10-2 of the user B with the information of the opponent (such as the user ID of the opponent) and the game conditions (usage order) under which the matching is established. , number of innings) is transmitted (S302-1 and S302-2).

Returning to FIG. 18, the CPU 11 of the game terminals 10 of the users A and B, when receiving the matching information from the server 30 and matching is established (YES in S108), sets the game conditions under which the matching is established. (S110). As a result, for example, the pre-fight confirmation screen G600 of FIG. strength information, etc.) and the game conditions under which matching was established. Here, since the user A has set the conditions for the use order "Random", it can be confirmed which of the two registered use orders will be used after the matching is established. In the present embodiment, the match is started when both of the matched users A and B operate the match start button B632 within the time limit (S112).

In FIG. 19, the competitive game can be executed by direct communication such as P2P connection between game terminals 10-1 and 10-2 (S202). Note that the battle game may be executed via the server 30 . During the competitive game, the user A and the user B operate the team-ordered player characters corresponding to the game conditions in which matching is established, thereby progressing the game.

After that, when the battle game between user A and user B ends (YES in S114 of FIG. 18), the CPUs 11 of both game terminals 10 execute the battle ending process (S116). That is, as shown in FIG. 19, game terminal 10-1 and game terminal 10-2 transmit the result of the competitive game to server 30 (S204-1 and S204-2). Incidentally, when the competitive game is executed via the server 30, S204-1 and S204-2 can be omitted.

After that, the server 30 transmits to the game terminal 10-1 and the game terminal 10-2 information for giving rewards such as points and items to the user A and the user B according to the result of the battle game (S304). -1 and S304-2). As a result, information on the match result and the reward is displayed on the display units 17 of the game terminals 10-1 and 10-2.

[5. summary]
In the game system 1 according to the embodiment described above, multiple team orders and decks corresponding to multiple game conditions can be registered in advance. Then, by issuing a matching request accompanied by setting any of two or more of the plurality of game conditions, it is possible to execute a game using team orders and decks corresponding to the game conditions in which matching is established. As a result, a user who wants to play a game with any of two or more game conditions will have more chances of matching, and it is possible to increase the chances of matching even under game conditions that have been difficult to match. With this configuration, it is possible to increase the chances of overall matching while enabling team orders and proper use of decks depending on the game conditions, and it is possible to increase the chances of matching even under game conditions that were particularly difficult to match, improving the interest of the game. can be achieved.

[6. Modification]
The invention is not limited to the embodiments described above.

[6-1] In the above, from a training player order (an example of a first use object) composed of a predetermined number of training players (an example of a first object) and a predetermined number of event characters (an example of a second object) An example of pre-registering an event character order to be configured (an example of a second use object) has been shown, but a mixed order (an example of a third use object) including at least one training player and at least one event character may be registered in advance. Then, the hybrid order may be associated with at least part of the matching game conditions in the same manner as the training player order and event character order. In addition, regarding the game conditions of the use order, it is possible to set the conditions of "Random" such as training player order, event character order, mixed order (or any two of the three orders). , a competitive game may be executed using an order corresponding to a game condition in which matching is established.

[6-2] In the above, an example of a game using two different types of objects, ie, a training player and an event character, is shown, but the game can also be applied to games using three or more types of objects. That is, even if multiple use objects (orders, decks, etc.) each containing three or more types of objects can be registered in advance, and each of the multiple use objects is associated with at least part of the matching game conditions. good. As an example, objects that can be acquired by training (for example, training players), objects that can be acquired by lottery (for example, event characters), objects that are commonly given to all users at competition events held in the game (for example, limited-time It can be applied to a game using three types of objects with different acquisition methods (common objects).

[6-3] In the above, an example of using objects (team orders, decks, etc.) composed of objects (training players, bent characters, etc.) possessed by the user (that is, associated with the user's user identification information) , an object not possessed by the user may be included as part of the objects included in the usage target. For example, an object possessed by another user associated with the user (that is, another user whose user identification information is associated with the user identification information, and is called a friend, associate, etc.) may be used by the user. You may enable it to be included in the team order etc. as.

[6-4] In the above description, there are no restrictions on the selection of athletes to be trained that constitute the athlete-to-be-developed order, but the following restrictions may be imposed. For example, the cost (assessed value) is set according to the ability of the training player, and the total cost of multiple training players that make up the training player order must be less than the maximum team cost. may be provided. In this case, if training players with high abilities can be trained, the training player order can be strengthened, but the cost performance of each training player is also important to some extent. Instead of simply creating an order for highly capable training players, it is required to edit the order considering the maximum team cost.
Similarly, the cost (assessed value) is set according to the level of the event character's ability, and the total cost of the multiple event characters that make up the event character order must be less than the maximum team cost. may be provided.

[6-5] In the above example, editing (registration) of training player orders and event character orders is possible at any time before sending a matching request. Editing may be allowed. For example, after the matching is established and before the match starts, a predetermined period in which each matched user can edit the order may be provided.

[6-6] In the above description, after matching is established, the pre-fight confirmation screen G600 illustrated in FIG. 7 is displayed, and the match is not started unless both matched users operate the match start button B632. but not limited to this. For example, after matching is established, the match may be automatically started without operating the game start button B632 (that is, after matching is established, the matching cannot be canceled at will by the user before the match starts).

[6-7] If the difference in the above-mentioned "scenario applied to breeding" can be set as the "game condition" of 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), use any one “training team” from among them. Allow the user to specify and register as a target. Similarly, with respect to the "training teams" associated with the scenarios B, C, . Then, with each scenario applied to training as a "game condition", it is possible to set conditions for "automatic" matching in which any of two or more scenarios can be used, and "training" corresponding to the scenario of the game condition in which matching is established is possible. A match game using "Team" is to be executed.

[6-8] If the differences in the above-mentioned "object acquisition time", "object type" or "gacha type" can be set as the "game condition" of matching, the following configuration can be used. can.
For example, the user can register in advance a use object (a single object, a team or deck consisting of a plurality of objects, etc.) that includes at least one object for each "object acquisition period". For example, a deck composed of a predetermined number of 2021 series objects can be registered in association with the "2021 series", and a deck composed of a predetermined number of 2022 series objects can be associated with the "2022 series". You can register decks. Then, it is possible to set conditions for ``automatic'' matching in which any of two or more ``object acquisition times'' are acceptable, and a game using a deck corresponding to the game conditions in which matching is established is executed. . The same applies when the difference between the "object type" or the "gacha type" is used as the "game condition" for matching. That is, for each "object type" or "gacha type", it is possible to register in advance a use target including at least one object, and for these game conditions, it is possible to set the above-mentioned "automatic" matching conditions. , the game is executed using the deck corresponding to the game condition in which the matching is established.

[6-9] Although the example of the baseball game has been mainly described above, the present invention can also be applied to other games. For example, other sports games (games based on soccer, tennis, American football, basketball, ice hockey, volleyball, rugby, etc.), fighting games, fighting games, digital card games, role-playing games, simulation games, adventure games or Like breeding games, regardless of the game format or genre, it can be applied to various games as long as it is a game in which multiple usage objects containing at least one object can be registered and matched users can use the usage objects. can.

[6-10] The game terminal 10 and the server 30 can communicate with each other to transmit and receive various data, and both are information processing devices (computers) equipped with a CPU, a ROM, a RAM, an auxiliary storage device, a communication unit, and the like. They have basically the same hardware configuration. Therefore, part of the various 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 various functions described above may be implemented by the CPU 11 of the game terminal 10 . Alternatively, all of the various functions described above may be implemented by the CPU 31 of the server 30 .

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

[6-12] The computer-readable program according to the present embodiment is recorded on various computer-readable recording media such as hard disks, optical disks (CD-ROM, DVD-ROM, etc.), flexible disks, semiconductor memories, etc. It is read from the recording medium and executed by the CPU of the computer that constitutes the game system 1 or the game control device. Moreover, the means for providing the program to the computer is not limited to the recording medium described above, and can be performed via a communication network such as the Internet.

[7. Note]
From the above description, the present invention can be grasped, for example, as follows. In order to facilitate understanding of the present invention, reference numerals in the accompanying drawings are added in parentheses for convenience, but the present invention is not limited to the illustrated embodiments.

1) A game system (1) according to one aspect of the present invention selects a use object (for example, player-in-training order, event character order) including at least one object (for example, player-in-training, event character) based on a user's operation. A registration means (111) for registering a plurality of players, and 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 use objects based on user's operation. and a matching means (113) for matching the user's play partner based on the matching request accompanied by the condition setting. and game execution means (114) for executing a game using the use object corresponding to the game condition for which the matching is established.

9) The game control device (10 or 30) according to one aspect of the present invention can be used to create objects (for example, training player orders, event characters) including at least one object (for example, training players, event characters), based on user operations. A registration means (111) for registering a plurality of orders), and a plurality of game conditions (for example, a condition to use an event character order, a training player order to be used) corresponding to each of the plurality of use objects based on the user's operation. and condition setting means (112) for enabling setting of any two or more of the above conditions, and matching means ( 113), and game execution means (114) for executing a game using the use object corresponding to the game condition for which the matching is established.

10) The game control device (10) according to one aspect of the present invention, based on the user's operation, uses objects (for example, training player orders, event character orders) including at least one object (for example, training players, event characters). and a plurality of game conditions (e.g., the condition of using an event character order, the condition of using a trained player order, ), a condition setting means (112) capable of setting two or more conditions among the above; and game execution means (114) for executing a game using the .

11) A program according to an aspect of the present invention is a computer as the game system (1) according to any one of 1) to 8) or the game control device (10 or 30) according to 9) or 10). It's a program that makes it work.

12) An information storage medium according to an aspect of the present invention is a computer-readable information storage medium recording the program according to 11).

13) A control method for a game system (1) or a game control device (10 or 30) according to an aspect of the present invention is a method for controlling at least one object (for example, a training player, an event character) based on a user's operation. A registration step (S100, S102) for registering a plurality of objects (for example, training player orders, event character orders), and a plurality of game conditions (for example, event character orders) respectively corresponding to the plurality of use objects based on the user's operation. a condition setting step (S104) for enabling setting of any two or more of the condition of using the training player order and the condition of using the training player order); , a matching step (S300) of matching a user's playing partner, and a game execution step (S110, S112) of executing a game using the use object corresponding to the game condition in which the matching is established.

According to the aspects described in 1), 9) to 13) above, it is possible to register in advance use objects corresponding to each of a plurality of game conditions. Then, by making a matching request accompanied by condition setting that any two or more of the plurality of game conditions are acceptable, a game can be executed using the use object corresponding to the game condition in which matching is established. As a result, a user who wants to play a game with any of two or more game conditions will have more chances of matching, and it is possible to increase the chances of matching even under game conditions that have been difficult to match. With this configuration, it is possible to increase the chances of overall matching while making it possible to selectively use the objects to be used depending on the game conditions, and it is possible to increase the chances of matching even under the game conditions that were particularly difficult to be matched, thereby improving the interest of the game. .

2) In one aspect of the present invention, in the aspect described in 1), 9) or 10) above, a plurality of in-game leagues in which the user can participate are set, and the registration means (111) A plurality of the use objects corresponding to the plurality of in-game leagues may be registered based on the operation.

According to the aspect described in 2) above, the plurality of in-game leagues correspond to the plurality of usage targets, and for example, the corresponding usage target A is used for game play in in-game league A, A corresponding use object B is used for game play in in-game league B. Since multiple usage targets also correspond to multiple game conditions, matching is established with the condition setting of "Random", and by using the usage target corresponding to the established game condition, the usage target A game that participates in the in-game league corresponding to is executed. As a result, it is possible to increase the chances of matching even in in-game leagues that have been difficult to match, while making it possible to selectively use the use objects depending on the game conditions.

3) In one aspect of the present invention, in the aspect described in 2) above, the game conditions include the in-game league that the user wants to participate in, or the use target corresponding to the in-game league that the user wants to use,
The condition setting means (112) sets a condition that any two or more of the plurality of in-game leagues may be set based on a user's operation, or a plurality of the plurality of the above-mentioned leagues corresponding to the plurality of in-game leagues, respectively. It may be possible to set a condition that any one of two or more of the objects to be used may be used.

Each user registers a use object corresponding to each of a plurality of in-game leagues, and plays a game with a matched play partner (another user) in the same in-game league. Therefore, the game condition "the in-game league that the user wants to join" has the same meaning as the game condition "use object corresponding to the in-game league that the user wants to use". According to the aspect described in 3) above, it is possible to increase matching opportunities even in in-game leagues in which matching has been difficult, while making it possible to selectively use the use targets depending on the game conditions.

4) In one aspect of the present invention, in the aspect described in any one of 1) to 3), 9), and 10) above, the objects include a first object (for example, a training player) and a second object of different types. (for example, an event character), and the plurality of use objects include a first use object (for example, training player order) in which the first object is registered and a second use object in which the second object is registered ( For example, event character order) may be included at least.

According to the aspect described in 4) above, two different types of the first use object to which the first object is registered and the second use object to which the second object is registered are registered in correspondence with the game conditions. can. Depending on the type of object, for example, a user with a higher level of proficiency (experience) in the game is more likely to obtain an object with a higher parameter (for example, the first object). In such a case, a novice user who is just starting the game can only use objects consisting of relatively low-parameter objects, while novice users can obtain objects of a different kind (e.g., second object) will allow you to use a certain amount of usage. As in this example, by enabling registration of multiple usage targets consisting of different types of objects, the variation of usage targets will increase, making it easier for various users to participate in the game and creating opportunities for matching. To increase.

5) In one aspect of the present invention, in the aspect described in 4) above, the first object is associated with a training object (for example, training player) trained by changing or setting parameters and user identification information. The second object may be associated with at least one second object (for example, an event character) determined by lottery from among a plurality of second objects and user identification information. .

According to the aspect described in 5) above, there are different types of the first use object composed of the training object obtained by the user through training and the second use object composed of the second object obtained by the user through lottery. Each of the two can be registered in correspondence with the game conditions. While the higher the user's game proficiency level, the higher the user's game proficiency level, the higher the user's game proficiency level, the more likely it is that the second object that can be obtained by lottery can be obtained by anyone with relatively high parameters regardless of the user's game proficiency level. In this way, by enabling registration of different types of first use objects and second use objects in association with different game conditions, it becomes easier for various users to participate in the game regardless of their level of proficiency in the game. , the matching opportunities also increase.

6) In one aspect of the present invention, in the aspect described in 5) above, the second object (for example, an event character) associated with the user identification information is a parameter of the first object in training the first object. may be used as an auxiliary object for changing or setting the

According to the aspect described in 6) above, the second object possessed by the user is also used as an auxiliary object in training the first object. This makes it possible to effectively utilize object resources in the game.

7) In one aspect of the present invention, in the aspect described in any one of 1) to 6), 9), and 10) above, the condition setting means (112) sets the plurality of usage conditions based on the user's operation. It may also be possible to set the condition by designating one of the plurality of game conditions corresponding to each target.

According to the aspect described in 7) above, not only is a matching request accompanied by a condition setting that two or more of a plurality of game conditions respectively corresponding to a plurality of use objects may be acceptable, but also a matching request for the plurality of game conditions. A matching request specifying either one is also possible.

8) In one aspect of the present invention, in the aspect described in any one of 1) to 7), 9), and 10) above, the condition setting means (112) sets the game condition (for example, The condition settings may include other game conditions (for example, game conditions regarding the number of innings) different from the conditions for using the player-development order and the conditions for using the event character order).

According to the aspect described in 8) above, it is possible to make a matching request including not only the game conditions corresponding to the use object but also other game conditions not corresponding to the use object in the condition setting.

DESCRIPTION OF SYMBOLS 1... Game system N... Network DB... Database 10... Game terminal 11... CPU 13... RAM 14... Auxiliary storage device 17... Display part 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 TBL 101 User information table TBL 102 Character information table TBL 103: game condition table, TBL 104: team order table, DT 105: possessed character data, DT 106: team order data

Claims (11)

registration means for registering a plurality of usage targets including at least one object based on a user's operation;
condition setting means for setting any one of two or more of a plurality of game conditions respectively corresponding to the plurality of use objects based on a user's operation;
matching means for matching a user's playing partner based on the matching request with the condition setting;
game execution means for executing a game using the use object corresponding to the game condition for which the matching is established;
game system, including There are multiple in-game leagues that users can join,
2. The game system according to claim 1, wherein said registration means registers a plurality of said use objects respectively corresponding to a plurality of said in-game leagues, based on a user's operation. The game conditions include the in-game league that the user wants to join or the use object corresponding to the in-game league that the user wants to use,
The condition setting means sets a condition that any one of two or more of the plurality of in-game leagues may be set based on a user's operation, or sets a plurality of the usage targets corresponding to the plurality of in-game leagues. 3. A game system according to claim 2, wherein it is possible to set a condition that any of two or more of them may be used. The objects include at least a first object and a second object of different types,
4. The plurality of usage objects according to any one of claims 1 to 3, wherein the plurality of usage objects includes at least a first usage object to which the first object is registered and a second usage object to which the second object is registered. game system. The first object is an object in which a training object trained by changing or setting a parameter is associated with user identification information,
5. The game system according to claim 4, wherein the second object is associated with at least one second object determined by lottery from among a plurality of second objects and user identification information. 6. A method according to claim 5, wherein said second object associated with user identification information can be used as an auxiliary object for changing or setting parameters of said first object in raising said first object. game system. 7. The condition setting device according to any one of claims 1 to 6, wherein the condition setting means also enables the condition setting by designating one of the plurality of game conditions respectively corresponding to the plurality of use objects, based on a user's operation. The game system described in . 8. The game system according to any one of claims 1 to 7, wherein said condition setting means enables said condition setting to include another game condition different from said game condition corresponding to said use object. registration means for registering a plurality of usage targets including at least one object based on a user's operation;
condition setting means for setting any one of two or more of a plurality of game conditions respectively corresponding to the plurality of use objects based on a user's operation;
matching means for matching a user's playing partner based on the matching request with the condition setting;
game execution means for executing a game using the use object corresponding to the game condition for which the matching is established;
Game controller including. registration means for registering a plurality of usage targets including at least one object based on a user's operation;
condition setting means for setting any one of two or more of a plurality of game conditions respectively corresponding to the plurality of use objects based on a user's operation;
game execution means for executing a game using the use object corresponding to the game condition for which matching is established based on the matching request with the condition setting;
Game controller including. A program for causing a computer to function as the game system according to any one of claims 1 to 8 or the game control device according to claim 9 or 10.

Images