Program, Communication Terminal, and Game System

Abstract

The player easily starts a battle game. 【Solution means】The program causes a computer that executes a battle game in which players battle against each other to perform a construction process of constructing a battle deck for use in the battle game based on the player's operation input, and in response to receiving an operation input related to the start of playing the battle game, a matching request for an opponent, and a transmission process of transmitting a matching request including information about the battle deck constructed in the construction process to a matching server. The battle game features a first type of game element and a second type of game element different from the first type of game element. The battle deck can register the first type of game element and the second type of game element. The matching request is transmitted to the matching server in the transmission process on the condition that the first type of game element is registered in the battle deck.

Description

Technical Field

[0001] The present invention relates to a program, a communication terminal, and a game system, and particularly to an electronic game for matching opponents online.

Background Art

[0002] There are electronic games that match players online (Patent Document 1). Among such electronic games, there are those themed on trading card games (TCGs). In a TCG played in the real world, each player constructs a deck in advance that contains a plurality of cards based on a desired strategy, and can start a game play with an opponent using the deck.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] By the way, it takes a certain amount of time to match opponents and construct a deck. An electronic TCG game that matches opponents online has an aspect that the time until a player can actually play the game can be prolonged.

[0005] An object of the present invention is to provide a program, a communication terminal, and a game system that enable a player to easily start a battle game.

Means for Solving the Problems

[0006] A program according to an aspect of the present invention causes a computer that executes a battle game in which players battle against each other to perform a construction process of constructing a battle deck to be used in the battle game based on a player's operation input, and in response to receiving an operation input related to the start of playing the battle game, a transmission process of transmitting a matching request for a battle opponent, which includes information about the battle deck constructed in the construction process, to a matching server. In the battle game, a first type of game element and a second type of game element different from the first type of game element appear, and it is possible to register the first type of game element and the second type of game element in the battle deck. The matching request is transmitted to the matching server in the transmission process on the condition that the first type of game element is registered in the battle deck.

Advantages of the Invention

[0007] According to the present invention, it becomes possible for a player to easily start a battle game.

Brief Description of the Drawings

[0008]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Embodiments for Carrying Out the Invention

[0009] [Embodiment 1] Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. Note that the following embodiments do not limit the invention according to the claims, and not all combinations of the features described in the embodiments are essential for the invention. Two or more of the features described in the embodiments may be arbitrarily combined. Also, the same or similar configurations are denoted by the same reference numerals, and duplicate explanations are omitted.

[0010] One embodiment described below is an example of a game system in which a server that communicates with a player terminal (communication terminal or game device) used by each player matches two players who are connected at the same time and provides a service (battle service) that realizes a battle game in which both players participate. An example of applying the present invention to a game system will be described. However, the present invention is applicable to a system realized with any device configuration capable of advancing an electronic game in which a plurality of players participate. Also, in this specification, the "player" is described as referring to a user who logs in to and uses the battle service provided by server 200 in this game system.

[0011] 《Configuration of the Game System》 FIG. 1 is a diagram showing the configuration of the game system according to the present embodiment. As shown in the figure, in the game system, the server 200 and a plurality of player terminals 100 can be communicatively connected via the network 300. Further, in the present embodiment, the server 200 matches two players of the connected player terminals 100 as players of a battle game, provides a communication session for transmitting and receiving various information related to the battle game, and provides a battle service for realizing a battle game in which the two players participate.

[0012] Each player can log in to the battle service by starting a predetermined client application on the player terminal 100 used by the player. In the client application, the player can perform various settings and preparations for the executed battle game, set the player profile, and play the battle game (battle, play). Although details will be described later, the battle game (electronic game) in which game play is possible in the battle service of the present embodiment is assumed to be a trading card game (TCG) that progresses while arranging game elements such as cards in a predetermined game field. Further, the player terminal 100 can be any communication terminal having a communication function such as a PC or a smartphone.

[0013] 〈Hardware Configuration of Player Terminal〉 Subsequently, the hardware configuration of the player terminal 100 will be described with reference to FIG. 2. FIG. 2 is a block diagram illustrating the hardware configuration of the player terminal 100.

[0014] The control unit 101 is a processor such as a CPU, and performs various controls including operation control of each hardware included in the player terminal 100. Specifically, the control unit 101 performs the corresponding control by reading a necessary program stored in the storage device 102, expanding it in the memory 103, and executing it.

[0015] The storage device 102 is a device capable of storing permanent information, such as a non-volatile memory or an HDD. The storage device 102 stores, in addition to the operating system for operating the player terminal 100 and programs related to various applications, information on parameters necessary for realizing various controls and various data used for display and communication functions related to the browser. The memory 103 is a storage device used for temporarily storing data, such as a volatile memory. The memory 103 may be used not only as a deployment area for each program but also as a storage area for temporarily storing data output during the operation of various hardware and various controls.

[0016] The GPU 104 is a rendering device that executes various rendering processes related to the generation of a display screen related to the player terminal 100. The GPU 104 also executes the rendering process of the game screen during the execution of the battle game. The GPU 104 includes a GPU memory (not shown), expands various graphics data read from the storage device 102, and performs predetermined operations to generate various images including the screen. The screen and images generated by the GPU 104 are presented to the player by being displayed on, for example, the display 110 included in the player terminal 100. The display 110 is a device for performing information display that is included in the player terminal 100 or detachably connected to the player terminal 100, such as a liquid crystal display. The display 110 displays the screen generated by the GPU 104.

[0017] The operation I / F 105 is a user interface that receives operation inputs provided in the player terminal 100. When detecting that an operation input has been made, the operation I / F 105 outputs a control signal corresponding to the operation input to the control unit 101. In one aspect, the operation I / F 105 includes, for example, operation members such as buttons provided on the exterior of the player terminal 100 and various sensors. Further, the display 110 included in the player terminal 100 of the present embodiment is configured to be able to detect touch inputs, and the operation I / F 105 includes a touch input detection sensor provided on the display 110.

[0018] The communication I / F 106 is a communication interface with an external device provided in the player terminal 100. Information communication between the communication I / F 106 and the external device may be performed via a wide area network (WAN) such as the Internet, or via a LAN or the like. Information communication performed by the communication I / F 106 will be described as being performed wirelessly, but this does not exclude wired information communication.

[0019] The speaker 120 is an audio output interface provided in the player terminal 100. The speaker 120 outputs various types of audio information including audio related to the client application.

[0020] <Server hardware configuration> 3 is a block diagram showing the hardware configuration of the server 200 according to this embodiment. In the following description, the hardware configuration that realizes the same functions as the player terminal 100 will be prefixed with "server" to clearly distinguish it from the configuration of the player terminal 100.

[0021] The server control unit 201 is a processor such as a CPU, and performs control related to the realization of various functions including operation control of each piece of hardware included in the server 200, player management related to the battle service, a matching function between players, and information transmission and reception and information sharing regarding the battle game being executed. Specifically, the server control unit 201 performs the relevant control by, for example, reading out a necessary program stored in the server storage device 202, expanding it in the server memory 203, and executing it.

[0022] The server storage device 202 is a device capable of permanently storing information, such as a non-volatile memory or HDD. The server storage device 202 stores an operating system for operating the server 200 and a program related to matching, as well as parameter information required for implementing various controls and various data required for providing a matching function. The server storage device 202 also has a database function for managing information on each player registered as a player of the game system. The server memory 203 is a storage device used for temporary data storage, such as a volatile memory. The server memory 203 may be used not only as an area for developing each program, but also as a storage area for temporarily storing data output during the operation of various hardware and various controls.

[0023] The server communication I / F 204 is a communication interface with an external device provided in the server 200. Information communication between the server communication I / F 204 and the external device may be performed via a wide area network (WAN) such as the Internet, or via a LAN or the like. Information communication performed by the server communication I / F 204 may be performed either wired or wirelessly.

[0024] Overview of the match game The following provides an overview of a competitive game in which a play experience is provided in the game system of this embodiment.

[0025] <Service Login> When the client application is executed on the player terminal 100, a game window related to service use is displayed on the display 110 of the player terminal 100. The player can perform procedures related to service login by, for example, entering a player ID and a password in the game window. Through this procedure, a service login request is sent from the player terminal 100 to the server 200 together with the input information. When the server control unit 201 receives the service login request, it checks the authenticity of the input information by referring to, for example, player information registered in association with the player ID, and manages the player as being in a logged-in state when the authenticity is recognized. A player in a logged-in state can use various functions provided by the service for playing a battle game through the game window.

[0026] 〈Deck Construction〉 The functions provided by the service include a deck construction function.

[0027] The battle game is played using a predetermined field defined in the game. Each player can construct a "deck" in which a set of game elements is registered for the battle game, and play the battle game using the constructed deck.

[0028] For deck construction, the player needs to obtain game elements, for example, by using a lottery function available by paying a cost. That is, the game elements that the player can include in the constructed deck are limited to, for example, the game elements that the player has already obtained. Also, the decks that the player can construct are not limited to one, and a plurality of decks with at least some of the registered game elements being different may be constructible.

[0029] Information on game elements obtained by the player and the deck constructed by the player is managed by being registered in the server storage device 202 in association with identification information (player ID) that uniquely identifies the player. More specifically, the server storage device 202 also functions as a database (DB) that manages various types of information related to each player as player information. In the player information, which is one record of the DB, the player ID is associated with information on game elements obtained by the player and information on the deck constructed by the player and managed.

[0030] For example, for game elements obtained by the player, the element ID that uniquely identifies the game element and its quantity are included in the player information, enabling management of the state of how many of the game elements the player owns. Also, for example, for the deck constructed by the player, the identification information (deck ID) of the deck and the element IDs of the game elements included in the deck are included in the player information, and thus it is managed as information on the deck (deck information) that the player has constructed.

[0031] As described above, the battle game in which the play experience is provided by the battle service of the present embodiment is a TCG, and the game elements given to the player and registered in the deck and usable are (virtually) cards that can be owned in the electronic game. In the battle game of the present embodiment, the cards that the player can use are classified into two types: leader cards and member cards, which have different roles in the battle game. It is conditional that one leader card is included in the deck. In other words, the deck is constructed of one leader card and (one or more) a plurality of member cards. For each card, for example, a cost is determined according to the degree of advantageously advancing the battle game, and the player needs to register a group of cards included in the deck so that the total cost of the deck becomes a specified value.

[0032] Here, the leader card and the member card are cards provided with different roles in the battle game and have differences such as the following, for example.

[0033] The leader card has an aspect of restricting the member cards that can be included in the deck, and determines the direction of the deck (the strategic direction to be taken to win in the battle game). That is, by including one leader card in the deck, to a certain extent, it is determined what kind of game progression the battle game using the deck will be. On the other hand, basically, the member card does not restrict other cards that can be included in the deck.

[0034] The battle game is composed of turns. In each player's action turn, it progresses while sequentially placing the cards registered in the deck used by the player on the field. The leader card is placed on the field at the start of the battle game and is always placed on the field during the execution of the battle game. On the other hand, the member card is randomly added to the player's hand from the deck and is placed on the field at the player's discretion in each action turn. That is, the leader card and the member card differ in whether the placement on the field is mandatory or optional.

[0035] Here, in the battle game, a specified value of life (a parameter indicating the number of times durable against attack actions on the leader card) is set for each player's leader card at the start of the battle game. In the battle game of this embodiment, in order to ensure fairness between players, the life is set to a fixed 8 for any leader card. The battle game ends when the life of the leader card belonging to either one of the players becomes 0, or when the deck (hand cards, deck cards, and member cards on the field) of either one of the players becomes 0. That is, the player can win against the opponent by reducing the life of the opponent's leader card to 0 or by making the opponent's deck 0 first. Also, the player will lose to the opponent when the life of their own leader card becomes 0 or when the deck becomes 0 before the opponent.

[0036] In addition, each card has an effect that is activated when it is placed on the field in a battle game. However, the member card has one type of effect that does not change according to the progress parameters of the battle game. On the other hand, the leader card is different from the member card in that it has multiple types of effects that change according to the progress parameters of the battle game. Here, the progress parameters of the battle game may be, for example, the life of the leader card, and with the life being halved, an effect that makes the progress of the battle game more advantageous may be set to be activatable.

[0037] Therefore, when the player selects the menu of "Construct New Deck" or "Edit Existing Deck" related to the deck construction function, the editing state of one deck is entered, and a list of cards managed as the player's acquisition status is displayed in the game window. The player can select the cards to be registered in the deck to be edited by performing an operation input to select the desired card from the list. Specifically, the identification information (card ID) related to the card selected to be registered in the deck is added to the deck information related to the deck to be edited. The deck information related to the deck to be edited is temporarily held, for example, in the memory 103 of the player terminal 100 and is updated each time a card to be registered is selected.

[0038] Here, when the menu of "Construct New Deck" is selected, new deck information is generated and held in the memory 103 as the deck information related to the deck to be edited. On the other hand, when the menu of "Edit Existing Deck" is selected, the deck information related to the corresponding deck is downloaded from the server 200 to the player terminal 100 and held in the memory 103 as the deck information related to the deck to be edited.

[0039] Then, in response to an operation input related to the completion of construction, the deck information related to the deck to be edited is uploaded from the player terminal 100 to the server 200 and included in the player information related to the player for management. At this time, in the case of a new deck, in the server 200, a new deck ID is numbered for the player, and the deck ID is associated with the uploaded deck information and added to the player information of the player. Also, in the case of a constructed deck, since a deck ID is already associated with the deck information related to the deck to be edited, the deck information having the same deck ID as the uploaded deck information among the player information of the player is updated based on the uploaded deck information.

[0040] Note that in order to avoid occupying the storage area related to the DB due to the inclusion of deck information in which no cards are registered in the player information, the upload of the deck information related to the deck to be edited is performed on the condition that one or more cards are registered at the time when an operation input related to the completion of construction is made. That is, the completion of the construction of the deck does not necessarily require that the deck be in a state where it can be used in a battle game. For example, even in a state where one or more cards that are temporarily being considered for use are registered, the player can save the deck information as if the construction is completed.

[0041] 〈Matching〉 By using the deck constructed by the deck construction function, the player can play a battle game. In the battle game of this embodiment, since two players play against each other, the player needs to send a matching request from the player terminal 100 to the server 200 at the start of the game play. When the server control unit 201 receives the matching request, it performs a process of matching two players who are in a logged-in state and making a matching request at the same time.

[0042] Therefore, the client application is provided with a game play function and is configured to receive a play start request for a battle game from a player when using the function. The player can perform an operation input related to the play start request by selecting one deck from the constructed decks as the battle deck for the battle game (to be implemented later). Although details will be described later, in the game system of this embodiment, in order to enhance the interestingness of the battle game, matching of opponents is performed in consideration of the decks used by the players. Therefore, when an operation input related to the play start request is made, the control unit 101 transmits a matching request including information on the battle deck to the server 200 via the communication I / F 106.

[0043] The matching request includes, for example, the player ID of the player and information indicating the battle deck used by the player. The information indicating the battle deck can be, for example, a deck ID, and the server control unit 201 can refer to the deck information related to the battle deck from the corresponding player information based on the player ID and the deck ID, and can specify the cards registered in the battle deck.

[0044] As described above, how the battle game unfolds depends on the battle deck used by the player, particularly on one leader card included in the battle deck. The characteristics of each leader card are mainly determined by the effects that can be activated by the leader card, but in order to enable various play styles, there are advantageous / disadvantageous compatibilities between the characteristics. For this reason, when continuously matched with other players using decks with disadvantageous compatibilities, there is a risk that the player's interest in the battle game will decrease. Therefore, in the game system of this embodiment, the matching request includes information on the battle deck and is referred to in the matching process described later performed by the server control unit 201.

[0045] By the way, in constructing a battle deck for realizing suitable game development, it is necessary to consider the effects and costs set for each leader card and member card, which takes time. Also, in order to provide a highly interesting play experience of a battle game and match a suitable opponent for a player who has made a matching request, the matching process may also take time depending on the time zone and the like. That is, if the specification is such that a play start request for a battle game is accepted on the condition that the construction of the battle deck is completed, the time required for a player who has logged in to the service to start playing the battle game may be prolonged.

[0046] Therefore, in the game system of the present embodiment, it is configured to accept a play start request with the deck as a battle deck on the condition that at least a leader card is registered in the deck. That is, the transmission of the matching request from the player terminal 100 to the server 200 is transmitted on the condition that at least one leader card is included in the deck selected as the battle deck.

[0047] Therefore, in the game window related to the client application, the player can display and confirm the content of the battle deck even after performing an operation input related to the play start request, and the battle deck is further configured to be editable. Here, the deck to be edited is limited to the battle deck. Although details will be described later, in the server 200, the matching process is executed based on the information of the leader card of the battle deck by the matching request. Therefore, after the play start request, only the member cards other than the leader card in the battle deck, that is, only the member cards are controlled to be editable. Such editing of the battle deck is controlled to be possible only during the period until the matching of the opponent is completed.

[0048] (Matching Process) Hereinafter, an outline of the matching process executed in the server 200 regarding matching will be described.

[0049] In the game system of this embodiment, since the battle game in which a play experience is provided is a TCG in which two players battle, when the server control unit 201 receives a matching request from the player terminal 100 related to one player, it executes matching processing and determines another player (opponent) who battles with the one player. The matching processing is a process of matching players who have made matching requests at the same time among the players in the logged-in state. In order to provide a highly interesting play experience, a plurality of types of matching criteria are provided in the matching processing of this embodiment, and players to be opponents are extracted based on them. Each of the matching criteria defines the conditions of the players to be extracted as opponents. The server control unit 201 extracts players who meet the conditions from among the players who have received matching requests at the same time, and determines one of them as the opponent. A priority order is defined for each of the plurality of types of matching criteria. Basically, the server control unit 201 extracts players who meet the conditions related to all the matching criteria, and determines one of them as the opponent. However, when there are no players who meet all the conditions, the process of excluding the matching criteria with lower priority in order and repeating the extraction of players is repeated.

[0050] The first matching criterion of the matching processing of this embodiment relates to the matching frequency with the same player. The victory or defeat of a battle game is also affected by factors such as the experience and play skills of the player, or the cards in the possession state of the player. In particular, regarding play skills, there is an aspect that depends on the number of times of playing a battle game. When there is a clear difference between players, even if they play in a series, the player with higher play skills is more likely to win. As a result, the player with lower play skills is likely to lose continuously, and the player's interest in the battle game may decrease. Also, in a mode where the same players continuously match, for example, by repeating game play during a time period when the number of logged-in players is small, it is possible to intentionally match with the same player. For example, by one player repeatedly declaring defeat intentionally, it is also possible to illegally manipulate the winning rate of the other player.

[0051] Therefore, in the first matching criterion, the opponent to be matched with the player who has made a matching request is conditioned not to be the opponent of the player in a predetermined number of recent battle games played by the player. For the sake of easy understanding of the invention, in this embodiment, the aspect in which the predetermined number is set to 1 will be described so as to avoid consecutive battles with the same player. That is, hereinafter, the first matching criterion is defined on the condition that it is not the player who was most recently matched with the player who has made a matching request. However, the implementation of the present invention is not limited to this. For example, a player who has been matched once may be controlled not to be matched again until two or more predetermined numbers of battle games with other players as opponents are carried out.

[0052] The second matching criterion of the matching process in this embodiment relates to the matching frequency with players who use decks containing the same leader card. As described above, the game progression of the battle game may depend on the leader card included in the deck. For this reason, if consecutive battles with a deck containing the same leader card are enabled, the player will be continuously provided with the playing experience of a battle game with a similar game progression. As a result, there is a possibility that the player will get bored with the game play. In particular, when having consecutive battles with a deck containing a leader card with an unfavorable compatibility, the player may be forced into a game progression that is difficult to recover from, and thus may lose interest in the battle game.

[0053] Therefore, in the second matching criterion, the opponent to be matched with the player who made the matching request is conditioned on the leader card being different from the deck of the opponent used in a predetermined number of recent battle games played by the player. To facilitate understanding of the invention, in this embodiment, the case where the predetermined number is set to 1 will be described for avoiding consecutive battles with players using decks including the same leader card. That is, hereinafter, the second matching criterion is defined on the condition that the leader card is different from the deck of the player's most recent battle. However, the implementation of the present invention is not limited to this. For example, regarding the leader card used in the deck of an opponent in a battle once, it may be controlled not to match until a predetermined number of two or more battle games with opponents using decks of other leader cards are performed.

[0054] The third matching criterion for the matching process of this embodiment is conditioned on the opponent to be matched with the player who made the matching request being a player who uses a deck including a leader card different from that of the player. Each player constructs a deck considering the characteristics related to the leader card. However, when battling against a deck including the same leader card, it is difficult to make use of the characteristics, and there is a possibility that the game development will become monotonous. Therefore, in the third matching criterion, the opponent to be matched with the player who made the matching request is conditioned on using a deck with a leader card different from the battle deck used by the player.

[0055] The server control unit 201 determines another player to be matched with the player who made the matching request based on such three types of matching criteria. The priority order of the matching criteria is set to decrease in the order of the first matching criterion, the second matching criterion, and the third matching criterion. The server control unit 201 appropriately rearranges these matching criteria to extract players in order to determine an opponent from among the players who made matching requests at the same time.

[0056] For example, in a mode where player A battles player B who uses a deck containing the leader card b most recently, and uses a battle deck containing the leader card a in the next battle game, when the server control unit 201 receives a matching request from player A, it first extracts players who meet all the matching criteria. That is, the server control unit 201 extracts players who are different from player B (the first matching criterion), and use a deck containing leader cards other than leader card a and leader card b (the second and third matching criteria). At this time, if there are players who meet all the matching criteria (one or more players are extracted), the server control unit 201 determines an opponent from among these players. On the other hand, if there are no players who meet all the matching criteria, the server control unit 201 excludes the lowest-priority matching criterion (in this case, the third matching criterion) and extracts players who match again. Specifically, the server control unit 201 extracts players who are different from player B (the first matching criterion) and use a deck containing leader cards other than leader card b (the second matching criterion). If the server control unit 201 cannot extract players who match even under this condition, it further relaxes the conditions (excluding the second matching criterion) and performs re-extraction.

[0057] In this way, the server control unit 201 determines an opponent to match with the player who made the matching request while extracting players based on predetermined conditions to provide a suitable playing experience and relaxing the conditions as necessary. If there are no players who meet only the first matching criterion, the server control unit 201 may, for example, randomly determine one player from among the players who are making matching requests at the same time as the opponent, or extend the search period until a predetermined timeout time is reached and search again for players who meet the matching criteria.

[0058] When the matching of players is completed, the server control unit 201 provides a communication session for transmitting and receiving various information related to the battle game in which the two matched players participate. The information of the communication session is transmitted to each player terminal 100 used by each of the two players, together with, for example, the information of the matching result. When the control unit 101 of the player terminal 100 receives the information of the communication session, it starts a process for connecting to the communication session.

[0059] 〈Gameplay〉 By connecting the player terminals 100 of each player who battles in the communication session, the gameplay of the battle game in which the two matched players participate can be started. In the client application being executed on each player terminal 100, when the player terminals 100 of both players connect to the communication session, the processing related to the play of the battle game is started and the game screen is displayed.

[0060] Here, the battle game is executed on the condition that one leader card and one or more member cards are included in the battle deck. When the processing related to the play of the battle game is started, the battle deck is controlled to be uneditable in order to ensure fairness. Therefore, if no member card is included in the battle deck used by the player before the start of the processing related to the play of the battle game, an operation input related to the selection of at least one member card may be accepted, and the processing related to the play of the battle game may be executed when the member card is added and the deck information is updated.

[0061] In the process related to the play of the battle game executed on each player terminal 100, various pieces of information for game progress are configured based on the operation input made by the player regarding the battle game and are transmitted to the server 200. The server 200 manages various pieces of information for game progress for each communication session and performs a process of transmitting (sharing) the information received from the player terminal 100 to other player terminals 100 participating in the communication session. In the process related to the play of the battle game, when the server 200 receives information for game progress related to the opponent in the battle, display control of the game screen is performed based on the information. By doing so, the game system can provide a play experience in which players in remote locations battle through the server 200.

[0062] 《Client Processing》 Hereinafter, the client processing executed in the player terminal 100 of the present embodiment regarding the client application will be specifically described using the flowchart of FIG. 4. The process corresponding to the flowchart can be realized by the control unit 101 reading out the corresponding processing program stored in the storage device 102, for example, and expanding and executing it in the memory 103. Note that this client processing will be described as starting, for example, when the client application is executed in the player terminal 100 and the player's service login is completed. Also, in the description of this client processing, the player terminal 100 executing the processing is used, and the player who has logged in to the service is referred to as the "target player".

[0063] In S401, the control unit 101 determines whether an operation input related to the use of the deck construction function has been made. If the control unit 101 determines that an operation input related to the use of the deck construction function has been made, the process proceeds to S402, and if it determines that no such input has been made, the process proceeds to S403.

[0064] In S402, the control unit 101 executes the processing related to the deck construction function. Although the details of the processing related to the deck construction function are omitted in this embodiment, as described above, by using the deck construction function, deck information can be added / updated to the player information related to the target player.

[0065] In S403, the control unit 101 determines whether an operation input related to the play start request of the battle game has been made. If the control unit 101 determines that an operation input related to the play start request has been made, the process proceeds to S404, and if it determines that no operation input has been made, the process proceeds to S411.

[0066] In S404, the control unit 101 accepts the selection of the deck (battle deck) that the target player uses for the battle game. The selection of the battle deck is made based on an operation input for selecting any one of the decks constructed for the target player. Prior to the selection, the control unit 101 acquires the deck information registered for the player from the server 200 and causes the display 110 to display the corresponding decks so that they can be selected.

[0067] In S405, the control unit 101 determines whether a leader card is registered in the deck selected in S404. If the control unit 101 determines that a leader card is registered in the selected deck, the process proceeds to S406, and if it determines that no leader card is registered, the process returns to S404. In the latter case, the server control unit 201 may, for example, cause the display 110 to display a notification instructing the selection of a deck in which a leader card is registered.

[0068] In S406, the control unit 101 transmits a matching request including the deck ID of the deck selected in S404 as the deck ID of the battle deck to the server 200. By this matching request, matching processing is executed in the server 200, and a determination is made of the player who is the opponent in the battle (hereinafter referred to as the opponent player).

[0069] In S407, the control unit 101 determines whether the opponent player has been matched. The determination in this step can be made based on whether information on the matching result has been received from the server 200. If the control unit 101 determines that the opponent player has been matched, the process proceeds to S408. If it determines that the player has not been matched, the process of this step is repeated.

[0070] In S408, the control unit 101 establishes a communication connection with the communication session via the communication I / F 106 based on the information on the destination communication session included in the matching result information.

[0071] In S409, the control unit 101 executes processing related to the play of the battle game.

[0072] In S410, the control unit 101 determines whether the processing related to the play of the battle game started in S409 has been completed. Here, the processing related to the play of the battle game ends when the end condition is satisfied in the executed battle game and the battle result is determined. If the control unit 101 determines that the processing related to the play of the battle game has been completed, the process proceeds to S411. If it determines that the processing has not been completed, the process of this step is repeated.

[0073] In S411, the control unit 101 determines whether an operation input related to the termination of the client application has been made. If the control unit 101 determines that an operation input related to the termination of the client application has been made, this client processing is completed. If it determines that no such input has been made, the process returns to S401.

[0074] 《Matching Process》 Next, the matching process executed by the server 200 of the present embodiment will be specifically described using the flowchart of FIG. 5. The process corresponding to the flowchart can be realized by the server control unit 201 reading out the corresponding processing program stored in the server storage device 202, for example, and expanding and executing it in the server memory 203. Note that this matching process will be described as starting when a matching request is received from any one of the player terminals 100, for example. Also, in the description of this matching process, the player who received the matching request is referred to as the "target player", other players who are making matching requests at the same time are referred to as "waiting players", and the player who is matched with the target player is referred to as the "opponent player".

[0075] In S501, the server control unit 201 acquires information (extraction information) for extracting the opponent player. In the present embodiment, the server control unit 201 acquires, as the extraction information, the player ID of the player who was most recently matched with the target player (hereinafter referred to as the previous player), the card ID of the leader card related to the previous player in the most recent battle game, and the card ID of the leader card of the target player's battle deck. Here, various types of information related to the previous player may be obtainable, for example, from the battle history information included in the player information of the target player.

[0076] In S502, the server control unit 201 determines whether there is a player who meets all types of matching criteria among the waiting players based on the extraction information. That is, the server control unit 201 sets three types of matching criteria as extraction conditions and attempts to extract players who meet the extraction conditions from the waiting players. If the server control unit 201 determines that there is a player who meets all types of matching criteria among the waiting players, the process proceeds to S505, and if it determines that there is no such player, the process proceeds to S503.

[0077] In S503, the server control unit 201 sets new extraction conditions by excluding the matching criterion with the lowest priority among the matching criteria set in the current extraction conditions.

[0078] In S504, the server control unit 201 determines whether there is a player who matches the new extraction conditions among the waiting players based on the extraction information. If the server control unit 201 determines that there is a player who matches the new extraction conditions among the waiting players, the process proceeds to S505. If it determines that there is no such player, the process returns to S503. Note that when no conditions related to any matching criteria are set as the extraction conditions, the server control unit 201 determines that all waiting players match the new extraction conditions.

[0079] In S505, the server control unit 201 extracts players who match the extraction conditions from the waiting players and determines one of these players as the opponent player. Here, the determination of the opponent player may be performed, for example, by a lottery process. The server control unit 201 returns the player ID of the determined opponent player to the player terminal 100 used by the target player as information on the matching result, thereby completing this matching process. At this time, the server control unit 201 also transmits information on the matching result indicating that the target player has been matched to the player terminal 100 used by the opponent player.

[0080] As described above, according to the communication terminal of the present embodiment, a player can easily start a battle game. Also, according to the information processing apparatus of the present embodiment, it is possible to provide a highly interesting matching.

[0081] [Modification Example 1] In the above-described embodiments, the first matching criterion was described as being determined on the condition that the target player was not an opponent in a predetermined number of recent battle games. However, the implementation of the present invention is not limited to this. For example, when the difference in play skills between the target player and the opponent player is small, it is difficult to assume a situation where the game development becomes one-sided even if these players play again. In other words, when the difference in play skills between the target player and the opponent player is large, the game development can be the same even if these players play again in a short period of time. On the other hand, it is highly likely that the game development will not necessarily be the same among players with a small difference in play skills.

[0082] Therefore, in an aspect where attribute information such as game level, number of plays, and rank based on game performance is included in and managed in player information, the predetermined number of times until the target player can be matched with an opponent player may be increased or decreased based on the attribute information of these target players and the attribute information of the opponent player. For example, multiple types of value ranges can be set for the difference in the number of plays between players, and the predetermined number of times can be changed according to which value range the difference falls into. In this case, it may be determined that the predetermined number of times increases as the value range with a larger difference.

[0083] [Modification Example 2] In the above-described embodiments and modification examples, in order to match an opponent player who has played against the target player once, an aspect was described where it is a condition that the target player did not match with the opponent player in a predetermined number of battle games played by the target player, that is, an aspect where the number of plays of the battle game is a condition for matching between the same players. However, the implementation of the present invention is not limited to this, and it may also be a condition that a predetermined time has elapsed.

[0084] [Modification Example 3] In the above-described embodiments and modifications, although the mode in which the battle deck can be edited only for the member card even after the transmission of the matching request has been described, the implementation of the present invention is not limited to this. In one aspect, on the condition that the battle deck is completed at the time of transmission of the matching request (for example, the difference between the total cost and the cost upper limit value is within the threshold value), it may be configured to control so that the battle deck cannot be edited after the transmission of the matching request. Such an aspect is assumed to be adopted for the optimization of evaluation in a game mode or the like premised on a so-called serious match between players, such as evaluating players according to the battle results of a battle game and ranking them.

[0085] [Embodiment 2] In the above-described Embodiment 1, in response to receiving a matching request, the server control unit 201 selects one player from among the players who made the matching request at the same time and matches the player with the player related to the matching request. That is, in the game system of the above-described embodiment, a matching method is adopted in which the prescribed number of players who play in a battle game is determined by a matching process executed in the server 200 without going through the intention of the player. However, the matching method in an online battle game is not limited to the method in which the opponent is forcibly determined by the server control unit 201. For example, there is also a matching method in which some players wait in a state of accepting battle applications, and other players who are not in the waiting state select a desired player from among the players in the waiting state and make a battle application. In this matching method, since a player who is not in the waiting state can make a battle application to a desired player, unlike Embodiment 1, matching through the intention of the player is realized. In the present embodiment, a method for realizing highly interesting matching in such a matching method will be described.

[0086] 《Matching》 In the game play function of the client application according to this embodiment, when a play start request for a battle game is received, a selection is accepted as to whether to wait for a battle application from another player (hereinafter referred to as a request waiting for application) or to make a battle application to other players waiting (hereinafter referred to as a request for application). In either case, in the client application, selection of a battle deck is then accepted in the same manner as in Embodiment 1, and a matching request is transmitted from the player terminal 100 to the server 200.

[0087] In the game play function of this embodiment, the transmission timing of the matching request varies depending on whether the target player selects the request waiting for application or the request for application.

[0088] Specifically, when the target player selects the request waiting for application, when the subsequent selection of the battle deck is made, a matching request including the player ID of the target player, the deck ID of the battle deck, and the request waiting for application is transmitted from the player terminal 100 to the server 200. When receiving the matching request, the server control unit 201 adds the target player to the waiting players who are in the waiting state for a battle application and manages them.

[0089] On the other hand, when the target player selects the request for application, when the subsequent selection of the battle deck is made, a "candidate acquisition request" including the player ID of the target player, the deck ID of the battle deck, and the request for application is transmitted from the player terminal 100 to the server 200. When receiving the candidate acquisition request, the server control unit 201 returns information on matching candidates including a plurality of waiting players to the player terminal 100 in order to further allow the player making the battle application to select the target player. When receiving the information on the matching candidates, on the player terminal 100 used by the target player, an application screen is displayed in the game window related to the client application, displaying each of the matching candidate players in a manner capable of accepting a battle application.

[0090] Fig. 6 shows a configuration example of an application screen. In the example of Fig. 6, in the application screen 600, three waiting players included in the information of matching candidates are arranged as matching candidates 601a to 601c, and for example, by making an operation input for each area, an application for a battle against the corresponding waiting player can be accepted. That is, the matching candidates 601a to 601c show matching candidates that the target player can match with, and in response to an operation input for selecting any one of the matching candidates by the target player, a matching request including the player ID of the waiting player of the matching candidate is transmitted to the server 200. When receiving the matching request, the server control unit 201 executes a process of matching the waiting player specified by the player ID included in the matching request and the target player.

[0091] Details will be described later, but the matching candidate 601 does not display all the waiting players waiting for a battle application at the same time, but displays waiting players equal to or less than the upper limit number (3) of accepting a battle application from the target player, which is selected by the server control unit 201. By limiting the number of players displayed as the matching candidate 601 in this way, it is possible to avoid prolonging the matching time due to the target player being confused about which waiting player to battle with.

[0092] On the other hand, by limiting the number of waiting players displayed as the matching candidate 601, an impression that the number of players interested in the battle game is small may be given to the target player. Therefore, in the application screen 600, in addition to the matching candidates 601a to 601c shown in the figure, non-candidate players 602a to 602g are arranged as lively elements. Therefore, when the server control unit 201 returns the information of the matching candidate to the player terminal 100, it also transmits the information of the players to be displayed as the non-candidate players 602 together.

[0093] Here, since the players displayed as non-candidate players 602 are lively elements, they may be selected from standby players who were not selected as matching candidates, for example, or may be selected based on a predetermined rule from among the logged-in players, or may be selected from among all players including logged-out players.

[0094] The matching candidates 601 and the non-candidate players 602 differ in that, on the application screen 600, the former is displayed in a state where the target player can apply for a battle, while the latter is displayed in a state where the target player cannot apply for a battle. Also, as shown in the figure, the matching candidates 601 are displayed with a larger display size than the non-candidate players 602. Further, in order to be a reference when the target player selects a standby player to whom to apply for a battle from among the matching candidates 601, the information of the matching candidates includes detailed information of each standby player such as the player name, battle record, and attribute information. Therefore, detailed display icons 603a to 603c are displayed for each of the matching candidates 601a to 601c, and the detailed information of the corresponding standby player can be displayed in response to an operation input to the icon, which also differs from the non-candidate players 602. That is, as shown in the figure, the detailed display icons 603 are not displayed for the non-candidate players 602a to 602g, and the target player is configured not to be able to view the detailed information.

[0095] The game system of this embodiment is configured to enable players at various geographical locations to play against each other. For this reason, the server 200 may be configured not only as a single server but also as a plurality of server groups that work together. In such a mode, in order to create an effect that the target player can play against players in various regions, on the application screen 600, a map image imitating the earth is displayed as the background image 604. Here, the map image of the background image 604 may be changed in the position in the centrally shown map image based on the geographical information associated with the player terminal 100 (for example, the geographical location information of the player terminal 100). That is, when a player in Japan makes a candidate acquisition request, the map image of the background image 604 is displayed in a mode centered on Japan, and when a player in the United States makes a candidate acquisition request, the map image of the background image 604 is displayed in a mode centered on the United States.

[0096] Since the battle game in which the game experience is provided by the game system of this embodiment is a TCG, in the example of FIG. 6, both the matching candidates 601 and the non-candidate players 602 arranged on the application screen 600 display the players in a card type mode, but it will be easily understood that the implementation of the present invention is not limited to this.

[0097] So that a suitable battle game can be played, the server control unit 201 extracts players to be matching candidates from among the waiting players based on a plurality of types of matching criteria in the same manner as in the first embodiment. When extracting players to be matching candidates, the server control unit 201 sets extraction information based on the information included in the candidate acquisition request. In this embodiment, the server control unit 201 acquires and sets, as extraction information, the player ID of the previous player who was most recently matched with the target player, the card ID of the leader card related to the previous player in the most recent battle game, and the card ID of the leader card of the battle deck of the target player. Then, the server control unit 201 extracts a maximum number (3 people) of waiting players based on the extraction information and three types of matching criteria. The process related to this extraction may be performed in the same manner as S501 to S505 in the matching process of the first embodiment, but instead of determining one player among the extracted players as the opponent player, a maximum number of players are determined as matching candidates from among the extracted players, and the information of the matching candidates is returned to the player terminal 100, which is different.

[0098] At this time, if the players extracted in accordance with different combinations of matching criteria are included among the players up to the maximum number, information for identifying the players who match more matching criteria may be included in the information of the matching candidates and configured to be displayed discriminably on the application screen. That is, for example, if there are two players who match all types of matching criteria, and the remaining one player is extracted from the players who match two types of matching criteria in order to secure the maximum number of matching candidates, the former two players may be considered to have a more interesting game development, and thus are displayed in a different display mode from the remaining one player on the application screen 600.

[0099] To facilitate understanding of the invention, in the game system of this embodiment, when a battle application is made for a matching candidate, it is described that the matching candidate and the target player are matched. However, the implementation of the present invention is not limited to this. For example, when the waiting player disconnects during the waiting for a battle application, or when the waiting player declines the battle application in a mode where the waiting player can select whether to receive the battle application or not, etc., the display of the application screen 600 may be controlled to continue until the matching is completed (receiving information on the matching result), and to end when the matching is completed. In this case, in order not to send duplicate matching requests, after sending the matching request, the operation input for selecting the matching candidate 601 on the application screen 600 may be controlled not to be accepted.

[0100] Since a matching request can be received from a plurality of player terminals 100 at the same time, the waiting player changes from moment to moment. Therefore, the server control unit 201 may update the information on the matching candidate at, for example, a predetermined time interval and transmit it to the player terminal 100 regularly. In the player terminal 100 used by the target player, when receiving the information on the new matching candidate, the display content of the application screen 600 is updated. Here, when the target player was displaying detailed information related to any of the matching candidates at the time of receiving the information on the matching candidate, since it is presumed that the target player is considering a battle with the matching candidate, the control unit 101 may hold the information on the previously received matching candidate and control not to change the display content of the application screen 600.

[0101] [Modification Example 4] In the above-described Embodiment 2, it has been described that players to be matching candidates are extracted based on the matching criteria based on the players who fought most recently and the leader cards of the decks, similar to Embodiment 1. However, the implementation of the present invention is not limited to this. For example, in an aspect where player information is managed including attribute information such as the game level, the number of plays, and the rank of the player based on the game performance, matching criteria regarding the similarity of the attribute information with the target player may be further included. In the said matching criteria, it is a condition that the attribute information of the player to be a matching candidate for the target player is similar to the attribute information of the target player. Here, whether the attribute information is similar or not may be determined, for example, by whether the difference in the game level, the difference in the number of plays, and the difference in rank are below a predetermined threshold value. By configuring in this way, the opportunity for players with similar play skills to fight against each other increases, and the interest of players in the fighting game can be enhanced.

[0102] In such an aspect, in order to facilitate a game development suitable for the target player who spontaneously makes a battle application, the information of the matching candidates may be configured to include standby players of the same rank as the target player or standby players of a rank lower than the target player. Alternatively, the information of the matching candidates may include standby players of a rank higher than the target player. However, the information of the matching candidates may be configured such that the number of standby players of a rank lower than the target player is larger than the number of standby players of the higher rank and the same rank.

[0103] [Embodiment 3] In the above-described embodiments and variations, the matching process mainly targeting all players in the logged-in state has been described. On the other hand, the usage times of the service vary, and the play styles (play frequencies and play time zones) of battle games also differ for each player. Therefore, a natural difference can occur in the play skills of each player. Thus, in a game mode that performs a matching process targeting all players, when a match is made where there is a significant difference in play skills between players, there is a possibility of reducing the interest of the player with particularly low play skills in the battle game. For this reason, in the battle game of this embodiment, as a game mode that realizes a more interesting matching and makes it easier for players with similar play skills to be matched, it includes a class matching mode.

[0104] 《Class Matching Mode》 In the class matching mode, class points are assigned to players according to their battle game results, and the player's class is determined according to the cumulative number of points assigned. Then, the battle games in the class matching mode are basically configured such that players classified into the same class are matched. In other words, in the class matching mode, players are separated by class, and the matching process is controlled so as to match players within the class.

[0105] In one aspect, six ranks are provided, with higher ranks in the order of Bronze, Silver, Gold, Platinum, Master, and God. For each rank, the number of rank points (point threshold: the minimum number of points for each rank) required to be classified into that rank is determined, and the higher the rank, the higher the required number of rank points is set. That is, the rank of a player is determined by identifying the maximum point threshold among the point thresholds exceeded by the cumulative number of rank points given to the player, and the rank associated with the maximum point threshold. For example, in an aspect where the point threshold for Bronze is 0, the point threshold for Silver is 10,000, the point threshold for Gold is 30,000, the point threshold for Platinum is 50,000, the point threshold for Master is 70,000, and the point threshold for God is 90,000, the rank of a player with a cumulative number of rank points of 55,000 is Platinum.

[0106] When a player wins a battle game, the server control unit 201 determines to give a fixed value of rank points to the player and updates the attribute information of the corresponding player information. At this time, the server control unit 201 compares the cumulative number of rank points after the update with the threshold of each rank and determines the newly classified rank. On the other hand, when a player loses or draws in a battle game, the server control unit 201 shall not give rank points to the player and shall not update the attribute information of the corresponding player information.

[0107] Therefore, in the class matching mode, basically, many class points are given to the player who has won more battles in the battle game. As a result, the cumulative number of points given also increases, and the player will be classified into a higher class. That is to say, the class in the class matching mode corresponds to a parameter that evaluates the play skills of each player. The class information in the class matching mode may be included as attribute information in the player information for each player and managed. The server control unit 201 acquires the class information in the matching process related to the class matching mode and determines the opponent for the battle. By configuring in this way, players with high play skills are more likely to be classified into higher classes. Therefore, it is possible to provide a battle game play experience that enhances the interest while ensuring fairness.

[0108] <Bet Function> By the way, in the mode where a fixed number of class points are given by winning a battle game, it is necessary to play and win a considerable number of battle games until the player is classified into an appropriate class (a class in which many players with similar play skills exist). That is to say, in such a mode, the higher the play skill of the player, the more wins and play times are required until the player is classified into an appropriate class. However, since the time available for playing the game varies depending on the player's environment, there is a possibility that a suitable play experience cannot be guaranteed for some players.

[0109] Therefore, in the battle game of this embodiment, in the class match mode, as a mechanism to make it easier for players to be classified into appropriate classes regardless of the number of play times, a betting function is provided. The betting function is a mechanism that enables players to obtain additional class points as additional rewards when they win in the battle game. More specifically, for a battle game executed based on a matching request by a target player, the betting function bets (wagers) at least a part of the class points associated with the target player as an endowed state on the victory of the target player himself / herself. When the target player wins the battle game, class points (so-called dividends) corresponding to the number of class points wagered (so-called bet amount / chip. Hereinafter referred to as a betting element) are granted separately from the fixed-value class points. That is, the more class points the target player wagers as a betting element, the more additional rewards will be granted when the target player wins the battle game. Therefore, players with high play skills can actively use the betting function to increase the cumulative grant number of class points more quickly and reach appropriate classes more easily.

[0110] Here, in order to ensure fairness among players, betting on a betting element using the betting function is accepted only until the matching in the matching process is performed. Also, the class points wagered as a betting element shall cease to be in the endowed state of the target player if the target player loses the battle game. That is, in a battle game using the betting function, the betting element related to the target player is managed as a temporarily deposited state in the server 200 while being associated with the target player, and the treatment of the association changes according to the victory or defeat of the battle game.

[0111] More specifically, when the target player wins the battle game, the bet element is returned to the granted state of the target player again while maintaining the association with the target player, and additional reward class points are further granted to the target player. On the other hand, when the target player loses the battle game, the association between the bet element and the target player is released, and the target player is in a state where the bet element is not granted (the state of losing the bet element), and no additional reward class points are granted. In addition, when the target player draws in the battle game, the bet element is returned to the granted state of the target player again while maintaining the association with the target player, and no additional reward class points are granted.

[0112] Also, the additional reward class points are set to an amount less than the bet element so that the number of players classified into higher classes does not increase too much. Preferably, the larger the amount of the bet element, the smaller the ratio (payout ratio) of the amount of class points granted as additional rewards to the amount of the bet element may be set.

[0113] Since the cumulative granted number of the target player can change due to the process of granting or associating these class points related to the battle game using the bet function, when there is a change in the cumulative granted number, the server control unit 201 determines the class to which the target player should be classified. That is, when the target player wins the battle game using the bet function, more class points are granted, so the target player may be classified into a higher class (promoted) than currently. On the other hand, when the target player loses the battle game using the bet function, some class points are lost, so the target player may be classified into a lower class (demoted) than currently.

[0114] That is, the bet function allows the target player to take risks, but it facilitates the target player's reach to an appropriate class and can provide an exciting and highly interesting battle game playing experience.

[0115] In the battle game of this embodiment, the number of rank points that each player can bet using the betting function is not an arbitrary value that the player can specify, but is configured to be specified from among options of a predetermined amount or a predetermined unit. The betting screen that accepts the specification of the betting element can be configured to be specified from among options 701a to f, including not betting, as shown in FIG. 7, for example. In the example of FIG. 7, when the target player's cumulative awarded number is currently 85,000 and 5,000 related to the selected option 701a is bet, if the target player wins the battle game, 1,000 fixed awarded points at the time of victory and 4,000 additional reward are awarded, the cumulative awarded number becomes 90,000, and the rank becomes God, and if the target player loses, the betting element of 5,000 is lost and the cumulative awarded number becomes 80,000.

[0116] Here, the options that can be specified as the amount of rank points to be bet are explained as being changed according to the rank into which the target player is classified in order to ensure game balance and prevent rank fluctuations. That is, in the example of FIG. 7, the target player's rank is Master, so options 701a to 701e are displayed, but for example, for the next lower rank, Platinum, option 701a may not be specified or may be controlled not to be displayed. Also, in order to prevent the cumulative number of points awarded from becoming negative, the designation of a bet element is controlled to be acceptable on the condition that the amount of rank points to be designated has been awarded to the target player.

[0117] (Display of bet details) When matching is completed for players using the betting function, bet elements are displayed in a manner that allows all players participating in the competitive game to check them on a game start screen that notifies two competing players, as shown in Fig. 8. Displaying such bet elements can be an indicator of each player's enthusiasm for the competitive game, and can increase players' motivation for playing the game and improve interest.

[0118] In addition, for the battle game, according to the amount of the total bet elements of two players, on the game start screen or the game screen during the battle game, the display effects can be made different by adding cheers or confetti, etc., so as to control to further enhance the interestingness of the battle game.

[0119] In this embodiment, the details of the matching process are omitted. From the perspective of utilizing the effect of improving the interestingness according to the amount of such bet elements, in the matching method such as Embodiment 1, for example, in the matching request related to a player for whom a class point of a predetermined amount or more, such as a so-called high bet, is designated as a bet element, a matching criterion for matching players who bet under the same conditions can also be configured to be used in the matching process.

[0120] 《Class Determination Process》 Hereinafter, in the server 200 of this embodiment, the specific process of the class determination process executed for the class match mode will be described with reference to the flowchart of FIG. 9. The process corresponding to the flowchart can be realized by the server control unit 201 reading out the corresponding processing program stored in the server storage device 202, for example, and expanding and executing it in the server memory 203. Note that this class determination process will be described as being started when the end condition of the battle game is satisfied for the battle game implemented in the class match mode in any communication session. Also, in the description of this class determination process, the battle game for which the end condition is satisfied is referred to as the "target game".

[0121] In S901, the server control unit 201 selects, as the target player, one player among the players who participated in the target game and whose new class after the target game is undetermined.

[0122] In S902, the server control unit 201 determines whether the target player has used the bet function in relation to the target game. If the server control unit 201 determines that the target player has used the bet function, the process proceeds to S903. If it determines that the target player has not used the bet function, the process proceeds to S905.

[0123] In S903, the server control unit 201 determines the class points of the additional reward to be given to the target player based on the battle result of the target player in the target game and the bet elements related to the target player. When the battle result of the target player is a victory, the server control unit 201 determines an additional reward in an amount corresponding to the bet elements and gives it to the target player. That is, the server control unit 201 executes the update process of the player information of the target player and changes the cumulative number of awarded class points to a value obtained by adding the amount of the additional reward. Also, when the battle result of the target player is a draw or a defeat, the server control unit 201 determines the additional reward as 0. At this time, since there is no change in the cumulative number of awarded points for the target player, the server control unit 201 only determines that the additional reward is 0, and it is not necessary to perform the update process of the player information of the target player.

[0124] In S904, the server control unit 201 determines and executes the treatment of the bet elements held in the custody state for the target player based on the battle result of the target player in the target game. When the battle result of the target player is a victory or a draw, the server control unit 201 maintains the association between the bet elements and the target player and returns from the custody state to the awarded state of the target player. At this time, since there is no substantial change in the cumulative number of awarded points for the target player, the server control unit 201 only performs the process of releasing the custody state, and it is not necessary to perform the update process of the player information of the target player. Also, when the battle result of the target player is a defeat, the server control unit 201 releases the association between the bet elements and the target player, putting the target player in a state of having lost the bet elements. That is, the server control unit 201 executes the update process of the player information of the target player and changes the cumulative number of awarded class points to a value obtained by subtracting the amount of the bet elements.

[0125] In S905, the server control unit 201 determines the class points of the normal reward based on the battle result of the target player in the target game. When the battle result of the target player is a victory, the server control unit 201 gives the target player a normal reward (class points of a fixed value). That is, the server control unit 201 executes the update process of the player information of the target player and changes the cumulative grant number of class points to a value obtained by adding a fixed value. When the battle result of the target player is a draw or defeat, the server control unit 201 determines the normal reward as 0. At this time, since there is no change in the cumulative grant number of the target player, the server control unit 201 only needs to determine that the normal reward is 0, and it is not necessary to perform the update process of the player information of the target player.

[0126] In S906, the server control unit 201 determines the class to which the current target player is newly classified based on the cumulative grant number of the class points of the target player. More specifically, the server control unit 201 compares the cumulative grant number of the class points of the target player with the point threshold value and determines the class to which the player is newly classified. When the server control unit 201 determines the class to which the player is newly classified, it updates the player information of the target player.

[0127] In S907, the server control unit 201 determines whether a new class after the target game has been determined for all players participating in the target game. When the server control unit 201 determines that a new class has been determined for all players, it completes this class determination process. When it determines that there are undetermined players, that is, players for which the class has not been determined, the process returns to S901.

[0128] As described above, according to the information processing apparatus of the present embodiment, it is possible to provide a suitable playing experience for the game regardless of the number of plays. That is, a player with high playing skills can more easily upgrade to an appropriate class where they can battle with players having similar playing skills earlier. As a result, it is possible to avoid the occurrence of mismatches with differences in playing skills in lower classes.

[0129] [Modification Example 5] In the above-described Embodiment 3, when the target player loses in the battle game using the bet function, an aspect in which the rank of the target player can be downgraded according to the subtraction of the rank points has been described. However, the implementation of the present invention is not limited to this. Downgrading is not preferable for players, and in particular, players in lower ranks such as silver and gold may lose their motivation for game play due to downgrading. For this reason, the downgrading due to the subtraction of rank points may be performed on the condition that the rank of the target player is higher than a predetermined rank such as master or higher. That is, for example, for players with a rank of platinum or lower, even if the rank points are subtracted and the point threshold for the rank is not reached, they may not be downgraded to a lower rank and may maintain their current rank.

[0130] Also, in Embodiment 3, when the target player wins in the battle game using the bet function, an aspect in which the player immediately upgrades on the condition that the increased rank points exceed the point threshold for a higher rank has been described. However, the implementation of the present invention is not limited to this. Regarding upgrading, when the point threshold is exceeded, the target player may be given the right to challenge an upgrade battle to determine whether the player can upgrade to the corresponding rank, and the player may be upgraded according to the achievement of the upgrade conditions in the upgrade battle. The upgrade battle may be, for example, a battle game with players of the same rank, and upgrading may be recognized when the target player wins more than half of a predetermined number of battle games. Here, the predetermined number may vary according to the rank, and the higher the rank, the more the predetermined number increases, and the difficulty of achieving the upgrade conditions may be adjusted to increase.

[0131] [Modification Example 6] In the above-described Embodiment 3, the mode of accepting the designation of the number of class points as bet elements from among a predetermined amount or options in predetermined unit units has been described. However, the implementation of the present invention is not limited thereto. For example, when the total number of class points in the given state of the target player is less than the minimum amount that the player can specify as a bet element, all the class points in the given state of the target player may be configured to be specifiable as bet elements (so-called all-in). Alternatively, in order to increase the player's interest, regardless of the total number of class points in the given state, an all-in option may be configured to be specifiable.

[0132] [Modification Example 7] In the above-described Embodiment 3 and the modification example, the mode of making the class points specifiable as bet elements has been described. However, the implementation of the present invention is not limited thereto. For example, in a mode where other types of game elements are given to the player in addition to the class points, or in a mode where other types of game elements are given to the player instead of the class points, in the betting function, the other types of game elements may be configured to be specifiable as bet elements. In such a mode, the types of game elements that the player can specify as bet elements may be changed according to the class to which the player is classified. Also, in a mode where the types of game elements that can be specified as bet elements change according to the class, the higher the class to which the player is classified, the more types of game elements that are set to be of high value in the battle game can be specified as bet elements. For example, by configuring the game elements to be obtainable by victory, the interest of the battle game can be increased.

[0133] [Modification Example 8] In the above-described embodiments and modifications, various aspects of multiple types of matching criteria for matching or extracting as matching candidates the target players who have made matching requests have been described. However, these matching criteria may be used with a changed combination, and it goes without saying that the priority order of each individual matching criterion can also be appropriately changed based on other elements such as the content and rank of the battle game.

[0134] One aspect of such a combination is shown in FIG. 10. The table shown in FIG. 10 exemplifies multiple types of matching criteria and their priority orders that are referred to in the matching process for the above-described battle game in the rank matching mode. Each row of the table shows, for one matching criterion, the extraction conditions defined for the matching criterion, the prerequisite conditions to which the matching criterion is applied, and the priority order of the matching criterion among multiple types of matching criteria. As shown in the illustration, the higher the row in the upper part shows the matching criterion, the higher the priority order, and it is a matching criterion that is more likely to be guaranteed to meet the conditions when extracting waiting players related to the target player.

[0135] In the example of FIG. 10, on the condition of giving top priority to not matching the players against whom the target player has played in the most recent 10 battles, the conditions related to the rank of the target player, the bet element, and the leader card of the deck are defined.

[0136] Regarding the conditions related to the class of the target player, the conditions are defined differently depending on whether the target player is classified as a God, which is the highest class, or is classified into other classes. More specifically, when the class of the target player is God, the matching criteria with a lower priority are defined such that the ranking in the class of the target player is matched with standby players within ±50 ranks. However, if there are no such standby players, it is configured to be relaxed in order with standby players within ±200 ranks and standby players whose class is God. On the other hand, when the class of the target player is other than God, the matching criteria with a lower priority are defined such that standby players of the same class are matched. However, if there are no such standby players, it is configured to be relaxed in order with standby players classified into classes of ±1 and standby players classified into classes of ±2.

[0137] Also, regarding the conditions related to the leader card of the deck, the matching criteria that the target player does not have the same leader card as the deck used by the player they played against most recently or does not have the same leader card as the deck for the target player's battle are defined on the premise that the class of the target player is other than God. This is because in the case of God, which is the highest class, the battle games conducted among players of this class are very diverse in strategy, and the individual play skills are also considerable, and interactions can be developed regardless of the advantages and disadvantages of deck matchups.

[0138] Also, regarding the conditions related to the bet element, it is defined on the premise that the bet element bet by the target player is equal to or more than a predetermined amount. This is not only because having battles between players who have placed so-called high bets leads to an increase in the interestingness of the battle game, but also produces the following effects. For example, even if a player with high play skills tries to conduct game play (so-called smurfing) aimed at repeatedly placing high bets using a sub-account and fraudulently manipulating the battle results and cumulative awards, such behavior can be deterred by configuring it so that standby players in the higher classes where high bets are likely to be placed can be matched.

[0139] [Summary of the embodiment] The above embodiment discloses at least the following program, communication terminal, and game system.

[0140] (1) A computer that executes a competitive game in which players compete against each other, A construction process for constructing a battle deck to be used in the battle game based on an operational input by a player; a transmission process for transmitting to a matching server a matching request for matching with an opponent, the matching request including information about the battle deck constructed in the construction process, in response to receiving an operation input related to starting play of the battle game; A program for executing a first type of game element and a second type of game element different from the first type of game element appear in the competitive game; The first type of game element and the second type of game element can be registered in the battle deck, A program in which the matching request is sent to the matching server in the sending process on the condition that the first type of game element is registered in the battle deck.

[0141] (2) the program further causes the computer to execute an execution process of executing the competitive game with the opponent on condition that the opponent has been matched by the matching server; The program described in (1), wherein the construction process does not accept changes to the first type of game elements registered in the battle deck only before the battle game is executed, while accepting changes to the second type of game elements to be registered in the battle deck.

[0142] (3) The program described in (2), wherein the construction process does not accept changes to the first type of game elements and the second type of game elements registered in the battle deck during execution of the battle game.

[0143] (4) The execution process is the program according to (2) or (3) that executes the battle game on the condition that the battle deck includes one game element of the first type and one or more game elements of the second type.

[0144] (5) The construction process is the program according to any one of (1) to (4) that registers, in the battle deck, the game element selected by the player's operation input from among the game elements associated with the player.

[0145] (6) The construction process is capable of constructing one or more decks to be used in the battle game, and the program further causes the computer to execute a selection process of selecting one deck from among the one or more decks as the battle deck based on the player's operation input, the program according to any one of (1) to (5).

[0146] (7) In the battle game, a progress parameter for determining whether the game play of each player participating in the battle can continue is set, the game element of the first type is a game element in which a plurality of types of effects that switch according to the progress parameter are set, and the game element of the second type is a game element in which one type of effect that does not switch according to the progress parameter is set, the program according to any one of (1) to (6).

[0147] (8) A communication terminal that executes a battle game in which players battle against each other, comprising construction means for constructing a battle deck to be used in the battle game based on the player's operation input, and transmission means for transmitting, to a matching server, a matching request for a battle opponent that includes information about the battle deck constructed by the construction means in response to receiving an operation input related to the start of play of the battle game, and including: In the said battle game, a game element of a first type and a game element of a second type different from the said game element of the first type appear. In the said battle deck, it is possible to register the said game element of the first type and the said game element of the second type. The said transmission means is a communication terminal that transmits the said matching request to the said matching server on the condition that the said game element of the first type is registered in the said battle deck.

[0148] (9) A game system including a communication terminal that executes a battle game in which players battle against each other, and a matching server that matches players for the said battle game, The said communication terminal has construction means for constructing a battle deck for use in the said battle game based on a player's operation input, and transmission means for transmitting, to the said matching server, a matching request for an opponent in the battle game, the matching request including information regarding the said battle deck constructed by the said construction means, in response to an operation input related to the start of play of the said battle game being received. It is equipped with In the said battle game, a game element of a first type and a game element of a second type different from the said game element of the first type appear. In the said battle deck, it is possible to register the said game element of the first type and the said game element of the second type. The said transmission means is a game system that transmits the said matching request to the said matching server on the condition that the said game element of the first type is registered in the said battle deck.

[0149] (10) The said matching server is equipped with matching means for matching a prescribed number of players selected from among the players corresponding to the received said matching request for the said battle game based on a plurality of types of matching criteria. The communication terminal further includes an execution unit that executes the battle game in which the specified number of players participate, on the condition that the matching is performed by the matching unit. The game system according to (9).

[0150] (11) The plurality of types of matching criteria include criteria related to the game elements of the first type. The matching unit preferentially matches players with different game elements of the first type registered in the battle deck. The game system according to (10).

[0151] (12) The plurality of types of matching criteria include criteria related to the matching frequency between the same players. The matching unit controls the first player corresponding to the matching request so as not to match the second player who was most recently matched with the first player. The game system according to (11).

[0152] (13) Among the plurality of types of matching criteria, the criteria related to the matching frequency between the same players have a higher priority than the criteria related to the game elements of the first type. The game system according to (12).

[0153] (14) Attribute information is associated with each player. The plurality of types of matching criteria include criteria related to the similarity of the attribute information associated with the players. The matching unit matches the specified number of players associated with the same or similar attribute information. The game system according to any one of (10) to (13).

[0154] [Other Embodiments] The invention is not limited to the above embodiments, and various modifications and changes are possible within the scope of the gist of the invention.

Description of Reference Numerals

[0155] 100: Player terminal, 101: Control unit, 102: Storage device, 103: Memory, 104: GPU, 105: Operation I / F, 106: Communication I / F, 110: Display, 120: Speaker, 200: Server, 201: Server control unit, 202: Server storage device, 203: Server memory, 204: Server communication I / F, 300: Network

Claims

1. A computer that executes a battle game in which players battle against each other, a construction process for constructing a battle deck to be used in the battle game based on a player's operation input, a transmission process for transmitting, to a matching server, a matching request for a battle opponent that includes information regarding the battle deck constructed in the construction process in response to receiving an operation input related to the start of play of the battle game, an execution process for executing the battle game with the battle opponent on the condition that a battle opponent is matched by the matching server, A program for causing the above to be executed, in the battle game, a first type of game element and a second type of game element different from the first type of game element appear, it is possible to register the first type of game element and the second type of game element in the battle deck, the matching request is transmitted to the matching server in the transmission process on the condition that the first type of game element is registered in the battle deck, The construction process is a program that does not accept changes to the first type of game element registered in the battle deck from after the matching request is transmitted until before the execution of the battle game, while accepting changes to the second type of game element to be registered in the battle deck.

2. The program according to claim 1, wherein the construction process does not accept changes to the first type of game element and the second type of game element registered in the battle deck during the execution of the battle game.

3. The program according to claim 1, wherein the execution process executes the battle game on the condition that the battle deck includes one first type of game element and one or more second types of game elements.

4. The program according to claim 1, wherein the construction process registers, in the battle deck, a game element selected by a player's operation input from among the game elements associated with the player.

5. the construction process can construct one or more decks to be used in the battle game, the program further causes the computer to execute a selection process for selecting one of the one or more decks as the battle deck based on a player's operation input The program according to claim 1.

6. For each player in the said battle game, a progress parameter for determining whether the game play of the player can continue is set. The said first type of game element is a game element with a plurality of types of effects set to switch according to the said progress parameter. The said second type of game element is a game element with one type of effect set that does not switch according to the said progress parameter. The program according to any one of claims 1 to 5.

7. A communication terminal that executes a battle game in which players battle against each other, A construction means for constructing a battle deck for use in the said battle game based on the operation input of the player, A transmission means for transmitting a matching request for a battle opponent, which includes information about the said battle deck constructed by the said construction means, to a matching server in response to receiving an operation input related to the start of play of the said battle game, An execution means for executing the said battle game with the said battle opponent on the condition that the battle opponent has been matched by the said matching server, Comprising, In the said battle game, a first type of game element and a second type of game element different from the said first type of game element appear, It is possible to register the said first type of game element and the said second type of game element in the said battle deck, The said transmission means transmits the said matching request to the said matching server on the condition that the said first type of game element is registered in the said battle deck, The said construction means does not accept changes to the said first type of game element registered in the said battle deck from after the said matching request is transmitted until before the execution of the said battle game, while accepting changes to the said second type of game element to be registered in the said battle deck. A communication terminal.

8. A game system including a communication terminal that executes a battle game in which players battle against each other and a matching server that matches players for the said battle game, The said communication terminal is, A construction means for constructing a battle deck for use in the said battle game based on the operation input of the player, A transmission means for transmitting a matching request for a battle opponent, which includes information about the said battle deck constructed by the said construction means, to the said matching server in response to receiving an operation input related to the start of play of the said battle game, Execution means for executing the said battle game with the said opponent, on the condition that an opponent has been matched by the said matching server; comprising; In the said battle game, a game element of a first type and a game element of a second type different from the said game element of the first type appear; In the said battle deck, it is possible to register the said game element of the first type and the said game element of the second type; The said transmission means transmits the said matching request to the said matching server, on the condition that the said game element of the first type is registered in the said battle deck; The said construction means does not accept changes to the said game element of the first type registered in the said battle deck, while accepting changes to the said game element of the second type to be registered in the said battle deck, from after the said matching request has been transmitted until before the execution of the said battle game, a game system.

9. The said matching server is provided with matching means for matching a prescribed number of players selected from among the players corresponding to the received said matching request, for the said battle game, based on a plurality of types of matching criteria; The said communication terminal further comprises execution means for executing the said battle game in which the said prescribed number of players participate, on the condition that they have been matched by the said matching means; The game system according to claim 8.

10. The said plurality of types of matching criteria include criteria regarding the said game element of the first type; The game system according to claim 9, wherein the said matching means preferentially matches players with different said game elements of the first type registered in the said battle deck.

11. The said plurality of types of matching criteria include criteria regarding the matching frequency between the same players; The said matching means controls so as not to match the said second player who was most recently matched with the said first player, to the said first player corresponding to the said matching request. The game system according to claim 10.

12. In the said plurality of types of matching criteria, the criteria regarding the matching frequency between the same players are prioritized over the criteria regarding the said game element of the first type, the game system according to claim 11.

13. Attribute information is associated with each player; The said plurality of types of matching criteria include criteria regarding the similarity of the said attribute information associated with the player. The matching means matches the specified number of players associated with the same or similar attribute information The game system according to any one of claims 9 to 12

Images