Program, communication terminal, and game system

Abstract

The purpose of this invention is to make it easy for players to start multiplayer games. The program of this invention causes the computer executing the multiplayer game to perform: a deck-building process, which constructs a deck for use in the multiplayer game based on the player's input; and a sending process, which, based on the input related to starting the multiplayer game, sends a matchmaking request for an opponent, i.e., a matchmaking request containing information related to the deck constructed in the deck-building process, to a matchmaking server; and in the multiplayer game, game elements of category 1 and game elements of category 2 (different from category 1) appear. Both category 1 and category 2 game elements can be registered in the deck. The matchmaking request is sent to the matchmaking server in the sending process, provided that category 1 game elements are registered in the deck.

Description

Technical Field

[0001] This invention relates to a program, a communication terminal, and a game system, particularly to an online matchmaking game for playing against opponents. Prior Technology

[0002] There is an online matchmaking video game (Patent Document 1). Among these video games, there are those based on Trading Card Games (TCGs). In real-world TCGs, each player pre-constructs a deck containing multiple cards based on a desired strategy, and can use this deck to start a game against an opponent. [Previous Technical Documents] [Patent Literature]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2022-020788 Summary of the Invention

[0004] [The problem the invention aims to solve] However, matchmaking for opponents and deck building take time, and the time until players can actually play the game in online TCG video games may be long.

[0005] The purpose of this invention is to provide a program, communication terminal, and game system that allows players to easily start multiplayer games. [Technical means to solve the problem]

[0006] One aspect of the present invention is a program that enables a computer playing a player-versus-player game to perform: a deck-building process, which constructs a deck for use in the game based on player input; and a sending process, which, based on input related to the start of the game, sends a matchmaking request for an opponent, i.e., a matchmaking request containing information related to the deck constructed in the deck-building process, to a matchmaking server; and in the game, game elements of category 1 and game elements of category 2, which are different from game elements of category 1, appear. Game elements of category 1 and game elements of category 2 can be registered in the deck. The matchmaking request is sent to the matchmaking server in the sending process, provided that game elements of category 1 are registered in the deck. [Effects of the Invention]

[0007] According to the present invention, players can easily start a battle game. Simple Explanation of the Diagram

[0008] Figure 1 is a diagram illustrating the structure of a game system according to embodiments and variations of the present invention. Figure 2 is a block diagram illustrating the hardware configuration of a player terminal 100, which is an example of an embodiment and variation of the present invention. Figure 3 is a block diagram illustrating the hardware configuration of a server 200, which is an example of an embodiment and variation of the present invention. Figure 4 is a flowchart illustrating the client processing executed in the player terminal 100 of Embodiment 1 of the present invention. Figure 5 is a flowchart illustrating the matching process performed in the server 200 of Embodiment 1 of the present invention. Figure 6 illustrates the application screen of a matchmaking candidate displayed on the player terminal 100 in Embodiment 2 of the present invention. Figure 7 is an illustration of the betting screen in a battle game according to Embodiment 2 of the present invention. Figure 8 is an illustration of the game start screen displayed when the betting function of Embodiment 2 of the present invention is used. Figure 9 is a flowchart illustrating the level determination process performed in the server 200 of Embodiment 3 of the present invention. Figure 10 is a diagram illustrating the matching criteria of Variation 8 of the present invention. Implementation

[0009] [Implementation Form 1] The embodiments are described in detail below with reference to the accompanying drawings. Furthermore, the embodiments described below do not limit the scope of the patent application; and not all combinations of features described in the embodiments are necessary for the invention. Two or more features from the plurality of features described in the embodiments may be combined arbitrarily. Also, the same reference numerals are used to designate the same or identical components, and repeated descriptions are omitted.

[0010] The following description illustrates an embodiment of the invention applied to a game system, exemplified by a server that provides communication connections to player terminals (communication terminals or game devices) used by each player, enabling matching of two players connected simultaneously to provide a battle game service (battle service). However, the invention can be applied to systems implemented with any machine configuration capable of playing electronic games with multiple players. Furthermore, in this specification, "player" refers to a user who uses the battle service provided by the server 200 in this game system to log in.

[0011] The Structure of a Game System Figure 1 shows the configuration of the game system of this embodiment. As shown, the game system is configured such that the server 200 and a plurality of player terminals 100 can communicate and connect via network 300. Furthermore, in this embodiment, the server 200 provides the following battle service: matching two players from the connected player terminals 100 as players in a battle game, setting up communication dialogues for sending and receiving various information related to the battle game, and realizing the battle game participated in by the two players.

[0012] Each player can log in to the battle service by launching a designated client application on their player terminal 100. Within the client application, players can configure various settings or preparations for the battle game, set up their player profile, and manage game sessions (battles, games). Details are described below, but in this embodiment, the battle game (electronic game) available for gameplay is a trading card game (TCG) played while arranging cards and other game elements in a designated game area. Furthermore, the player terminal 100 can be any communication terminal with communication capabilities, such as a PC (Personal Computer) or a smartphone.

[0013] <Hardware Components of a Gamer Terminal> Next, the hardware configuration of the player terminal 100 will be explained using Figure 2. Figure 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 (Central Processing Unit) that performs various controls, including the action control of the various hardware components of the player terminal 100. Specifically, the control unit 101 performs corresponding controls by reading the required program stored in the memory device 102, unfolding it in the memory 103, and executing it.

[0015] Memory device 102 is, for example, a non-volatile memory or an HDD (Hard Disk Drive) or other device capable of permanently storing information. In addition to storing the operating system or various application-related programs that enable the player terminal 100 to operate, memory device 102 stores information on parameters required for various controls, or various data used for display or communication functions related to the browser. Memory 103 is, for example, a volatile memory or other memory device used for temporarily storing data. Memory 103 serves not only as the expansion area for various programs, but also as a storage area for temporarily storing data output during the operation of various hardware devices or various control processes.

[0016] The GPU (Graphics Processing Unit) 104 is a rendering device that performs various rendering processes related to the generation of the display screen on the player terminal 100. The GPU 104 also performs rendering processes for the game screen during gameplay in a multiplayer game. The GPU 104 includes GPU memory (not shown), which expands various graphics data read from the memory device 102, performs prescribed calculations, and generates various images, primarily the screen. The screen or images generated by the GPU 104 are displayed to the player, for example, on the display 110 provided with the player terminal 100. The display 110 is, for example, an LCD monitor or other device provided with the player terminal 100, or a device detachably connected to the player terminal 100 for displaying information. The display 110 displays the screen generated by the GPU 104.

[0017] The operation I / F (Interface) 105 is a user interface provided by the player terminal 100 for accepting operation inputs. When the operation I / F 105 detects that an operation input has been completed, it outputs a control signal corresponding to the operation input to the control unit 101. In one embodiment, the operation I / F 105 may include operation components such as buttons provided on the casing of the player terminal 100, or various sensors. Furthermore, in this embodiment, the display 110 of the player terminal 100 is configured to detect touch input, and the operation I / F 105 includes a touch input detection sensor provided on the display 110.

[0018] The Communication I / F106 is a communication interface for external devices on the player terminal 100. Information communication between the Communication I / F106 and external devices can be conducted via a Wide Area Network (WAN) such as the Internet, or via a Local Area Network (LAN). Although it is stated that information communication via the Communication I / F106 is wireless, this does not exclude the possibility of wired communication.

[0019] Speaker 120 is the sound output interface of player terminal 100. Speaker 120 outputs various sound information including sounds related to client applications.

[0020] <Server Hardware Components> Figure 3 is a block diagram showing the hardware configuration of the server 200 in this embodiment. Furthermore, in the following description, the hardware configuration that implements the same functions as the player terminal 100 is prefixed with "server" to strictly distinguish it from the configuration of the player terminal 100.

[0021] The server control unit 201, such as a CPU, is a processor that controls the operation of the hardware of the server 200, manages players related to the battle service, performs matchmaking for players, and controls various functions including sending and receiving information or sharing information for the executed battle game. Specifically, the server control unit 201, for example, reads the required program stored in the server memory device 202, unfolds it in the server memory 203, and executes it to perform the corresponding control.

[0022] Server memory 202 is a device capable of permanently storing information, such as non-volatile memory or an HDD. In addition to being used by the operating system or related programs to enable the server 200 to operate, server memory 202 stores information on parameters required for various controls or provides various data necessary for matching functions. Furthermore, server memory 202 also has a database function for managing information on each player logged into the game system. Server memory 203 is a memory device used for temporarily storing data, such as volatile memory. Server memory 203 serves not only as the expansion area for various programs but also as a storage area for temporarily storing data output during various hardware actions or control processes.

[0023] The Server Communication I / F204 is a communication interface for external devices connected to the Server 200. Information communication between the Server Communication I / F204 and external devices can be conducted via a Wide Area Network (WAN) such as the Internet, or via a LAN. Information communication via the Server Communication I / F204 can also be conducted using either wired or wireless methods.

[0024] Overview of Battle Games The following is an overview of the battle games that provide a gameplay experience in the game system of this embodiment.

[0025] <Service Login> If a client application is executed on player terminal 100, the service displays a related game window on the monitor 110 of player terminal 100. Players can log in to the service by entering, for example, their player ID (Identity Document) and password in the game window. Through this process, player terminal 100 sends a service login request to server 200 along with the entered information. When server control unit 201 receives the service login request, it checks the authenticity of the entered information, for example, by referring to player information associated with the player ID. If the authenticity is confirmed, the player is managed as logged in. Players in the logged-in state can then utilize various functions provided by the game's related services through the game window.

[0026] <Deck Building> The service includes deck-building functionality.

[0027] The battle games are played in designated arenas specified by the game developers. Each player constructs a "deck" containing a set of game elements and can use the constructed deck to play the battle game.

[0028] To build a deck, players need to acquire game elements, such as through a lottery system that can be accessed by paying a fee. That is, the game elements a player can include in their deck are limited to those they have already acquired. Furthermore, a player can build not just one deck, but multiple decks that differ in at least some of the registered game elements.

[0029] Information about the game elements a player has acquired or the deck a player has constructed is managed by associating it with the unique identification information (player ID) of that player and registering it in the server memory device 202. More specifically, the server memory device 202 also functions as a database (DB) for managing various information related to each player. Each record in the DB, which is the player information, associates the player ID, information about the game elements acquired by that player, and information about the deck a player has constructed.

[0030] For example, game elements acquired by a player are uniquely identified by their element IDs and quantities, which are included in the player's information to manage whether the player possesses certain game elements. Similarly, a player's constructed deck is managed as deck information (deck information) by including the deck's identification information (deck ID) and the element IDs of the game elements it contains in the player's information.

[0031] As described above, the battle game provided in this embodiment of the battle service is a TCG (Trading Card Game), and the game element that players can register in their decks and use is (virtual) cards (possibly available in video games). In this embodiment of the battle game, the cards that players can use are classified into two types: leader cards and member cards, each with different roles in the battle game. A deck must contain at least one leader card. In other words, a deck is constructed with one leader card and (at least one) multiple member cards. Each card has a value, for example, corresponding to the degree to which it is advantageous in the battle game. Players must register the card group contained in the deck in a way that the total value of the deck becomes a predetermined value.

[0032] Here, the captain card and member card are cards with different functions in the battle game, and they have the following differences.

[0033] The captain card restricts the member cards that can be included in the deck, thus defining the deck's direction (the strategic approach to victory in a battle game). In other words, by including one captain card in the deck, the game's progression is somewhat determined. On the other hand, member cards, fundamentally, do not restrict the other cards that can be included in the deck.

[0034] The game is turn-based. During each player's turn, cards from their deck are sequentially placed on the field. The leader card is placed on the field at the start of the game and remains there throughout the game. Meanwhile, member cards are randomly added to a player's hand from a deck and are placed on the field during each turn based on the player's decision. In other words, the difference between leader and member cards lies in whether their placement on the field is mandatory or arbitrary.

[0035] Here, in this battle game, each player's leader card has a predetermined lifespan (a parameter indicating the number of times an attack can be launched against the leader card) set at the start of the game. In this implementation, to ensure fairness, the lifespan of each leader card is set to a fixed 8. The battle ends when the lifespan of any player's leader card reaches 0, or when any player's deck (hand, stack, and field member cards) reaches 0. That is, a player can defeat their opponent by reducing their opponent's leader card's lifespan to 0, or by reducing their opponent's deck to 0 first. Conversely, a player loses to their opponent by reducing their own leader card's lifespan to 0, or by reducing their deck to 0 before their opponent.

[0036] Furthermore, while individual cards have effects that occur when deployed on the field during battle, member cards have only one effect that does not change based on battle parameters. In contrast, leader cards differ from member cards in that they have multiple effects that change based on battle parameters. These battle parameters can be, for example, the leader card's life points, or effects that activate when the leader card's life points are halved, making the battle more advantageous.

[0037] Therefore, if the player selects the "Build New Deck" or "Edit Existing Deck" menu related to deck building, the game window displays a list of cards managed by the player. The player can select desired cards from the list to edit the target deck. Specifically, the identification information (card ID) of the selected cards is added to the deck information of the target deck. This deck information is temporarily stored in the player's terminal memory 103 and updated each time a card is selected for editing.

[0038] When the "Build New Deck" menu is selected here, new deck information is generated, and the deck information related to the deck to be edited is stored in memory 103. Conversely, when the "Edit Existing Deck" menu is selected, the deck information related to the corresponding deck is downloaded from server 200 to player terminal 100, and the deck information related to the deck to be edited is stored in memory 103.

[0039] Furthermore, based on the completed deck-building input, the deck information related to the edited deck is uploaded from the player's terminal 100 to the server 200 and managed within the player's player information. In the case of a new deck, the server 200 assigns a new deck ID to the player, associates this deck ID with the uploaded deck information, and adds it to the player's player information. Also, in the case of an already constructed deck, since the deck ID is already associated with the edited deck's deck information, the deck information in the player's player information with the same deck ID as the uploaded deck information is updated based on that uploaded deck information.

[0040] Furthermore, to avoid occupying DB storage space by including deck information with no cards registered in player data, the upload of deck information for the edited object is conditional upon registering at least one card at the time of completing the deck-building input. That is, deck building is not necessarily conditional upon the deck becoming usable in the game. For example, even if a deck is temporarily registered with at least one card under consideration, the player can still save the deck information as if the deck building is complete.

[0041] <Match> Players can engage in battle games by using decks constructed using the deck-building function. In this implementation of the battle game, since there are two players battling, each player needs to send a matchmaking request from their player terminal 100 to the server 200 when starting a game. When the server control unit 201 receives the matchmaking request, it processes the matchmaking between the two players who are logged in at the same time and have made the matchmaking request.

[0042] Therefore, a game function is set up in the client application. When using this function, the player accepts the request to start a game. For the (subsequent) game, the player selects one deck from their constructed deck as the battle deck, thereby performing the operation input related to the start game request. Details are described below, but in this embodiment of the game system, in order to improve the fun of the game, the player's deck is also considered when matching opponents. Therefore, when the operation input related to the start game request is completed, the control unit 101 sends a matching request containing information about the battle deck to the server 200 via communication I / F 106.

[0043] The matching request may include, for example, the player's player ID and information about the deck the player is using. The information about the deck to be displayed may be, for example, the deck ID. The server control unit 201 may, based on the player ID and the deck ID, refer to the deck information related to the deck from the corresponding player information and specify the cards registered in the deck.

[0044] As mentioned above, the course of the battle game varies depending on the player's battle deck, especially the leader card included in that deck. The characteristics of each leader card are primarily determined by the effects that can be activated by that leader card; however, to allow for multiple playstyles, there are favorable / unfavorable compatibility traits. Therefore, if a player is continuously matched with other players using decks with unfavorable compatibility, there is a risk of reducing the player's interest in the battle game. Therefore, in this embodiment of the game system, the matchmaking request includes information about the battle deck, which is referenced in the matchmaking processing described later by the server control unit 201.

[0045] However, constructing a deck for optimal gameplay requires considering the effects and value of each leader card or member card, which takes time. Furthermore, the matchmaking process for players requesting matches to find better opponents, which aims to provide a more engaging gaming experience, also takes time depending on the time of day. In other words, if a system is implemented where requests to start a game are only accepted after the deck is completed, the time required until a logged-in player can begin their game could be lengthy.

[0046] Therefore, in this embodiment of the game system, the game is configured such that a player accepts a request to start playing if at least one leader card is registered in the deck. That is, the matching request is sent from the player terminal 100 to the server 200 on the condition that the deck selected as the battle deck contains at least one leader card.

[0047] Therefore, the game window associated with the client application is configured such that after the player inputs the operation related to starting a game, the contents of the battle deck can be displayed and confirmed, and the battle deck can be edited. Here, the deck that is edited is limited to the battle deck. Furthermore, details will be described below, but according to the matchmaking request, the server 200 performs matchmaking processing based on the information of the captain card in the battle deck. Therefore, after starting a game, only the member cards other than the captain card in the battle deck can be edited and controlled. This editing of the battle deck can be controlled in a way that is limited to the period until the matchmaking of the opponent is completed.

[0048] (Matching Processing) The following is a summary of the matching process performed in the matching-related server 200.

[0049] Since the game system in this embodiment provides a two-player battle game (TCG), when the server control unit 201 receives a matchmaking request from a player's terminal 100, it performs matchmaking processing to determine the other players (opponents) to battle against that player. Matchmaking processing involves matching logged-in players who submit matchmaking requests at the same time with each other. To provide a highly engaging gaming experience, this embodiment sets multiple matchmaking criteria, based on which players are selected as opponents. Each matchmaking criterion specifies the conditions for selecting players as opponents. The server control unit 201 selects players who meet the conditions from those who receive matchmaking requests at the same time, and determines one of these players as the opponent. Given a priority order among the various matching criteria, the server control unit 201 repeats the following process: it selects players who basically meet all the conditions related to the matching criteria, and selects one player as the opponent. However, if there are no players who meet all the conditions, it removes players in order from the matching criteria with the lower priority, and selects players accordingly.

[0050] The first matching criterion in this implementation is the frequency of matching with the same player. The outcome of a competitive game is also influenced by factors such as player experience, skill, and the cards a player possesses. In particular, regarding skill, which depends on the number of times a player has played the game, when there is a clear difference in skill between players, even consecutive wins can easily result in victory for the more skilled player. Consequently, less skilled players are prone to losing streaks, potentially reducing their interest in competitive games. Furthermore, in cases of consecutive matches with the same player, for example, by repeatedly playing during periods with fewer logged-in players, it's possible to intentionally match with the same player. Alternatively, one player could deliberately repeat losing streaks to unfairly manipulate another player's win rate.

[0051] Therefore, in the first matchmaking criterion, the condition is that the opponent matched with the player making the matchmaking request is not an opponent from a matchmaking game that the player has recently played a specified number of times. For ease of understanding, this embodiment will describe a method to avoid consecutive matches with the same player by setting the specified number of matches to one. That is, hereinafter, the first matchmaking criterion will be determined as not being a player recently matched with the player making the matchmaking request. However, the implementation of this invention is not limited to this; for example, it may also be possible to avoid matching with a player who has only been matched once, until a specified number of matches with other players have been played (two or more times).

[0052] The second matching criterion in this implementation is the frequency of matching with players using decks containing the same leader card. As mentioned above, the game progression in a competitive match depends on the leader cards in the deck. Therefore, if a player can continuously play against decks containing the same leader card, they will be continuously provided with the same game progression experience, which may lead to player boredom. In particular, when playing against decks containing leader cards with unfavorable compatibility, players may lose interest in the competitive match because they are forced into an uncontrollable game.

[0053] Therefore, the second matching criterion is based on the condition that the captain card is different from the deck of the opponent in the player who made the matching request, and the deck used by the opponent in the player's most recent matches within a specified number of times. For ease of understanding, this embodiment will describe a method to avoid consecutive matches with players using decks containing the same captain card, where the specified number of matches is set to one. That is, the second matching criterion will be determined by the condition that the captain card is different from the deck used by the player who made the matching request in their most recent matches. However, the implementation of this invention is not limited to this; for example, it may be possible to avoid matching with an opponent whose deck uses a captain card only once, until the specified number of matches with opponents using decks containing other captain cards have been played more than twice.

[0054] The third matching criterion in this implementation is that the player using a deck containing a different captain card than the player who made the match request must use that deck. Each player constructs their deck considering the characteristics related to the captain card, but when playing against a deck containing the same captain card, it's difficult to utilize these characteristics, potentially leading to a monotonous game. Therefore, the third matching criterion is that the opponent matched with the player who made the match request must use a deck with a different captain card than the player's own deck.

[0055] The server control unit 201 determines which other players to match with a player who has made a match request based on these three match criteria. The priority of the match criteria is set in a manner that decreases in the order of the first match criterion, the second match criterion, and the third match criterion. In order to determine the opponent from players who make match requests at the same time, the server control unit 201 appropriately reorganizes these match criteria and selects players.

[0056] For example, if player A recently played against player B, who used a deck containing captain card b, and in the next game uses a deck containing captain card a, when server control unit 201 receives player A's matchmaking request, it first selects players whose decks match all matchmaking criteria. That is, server control unit 201 selects players whose decks are different from player B's (first matchmaking criterion) and who use decks containing captain cards other than captain card a and captain card b (second and third matchmaking criteria). If there are players whose decks match all matchmaking criteria (more than one player is selected), server control unit 201 determines the opponent from among those players. On the other hand, if there are no players whose decks match all matchmaking criteria, server control unit 201 removes the lowest priority matchmaking criterion (in this case, the third matchmaking criterion) and selects matching players again. Specifically, the server control unit 201 selects players whose decks are different from player B's (first matching criterion) and who use a deck that includes a leader card other than leader card b (second matching criterion). If the server control unit 201 is unable to select a matching player under these conditions, it then eases the conditions (removes the second matching criterion) and performs a reselection.

[0057] Thus, the server control unit 201 selects players based on pre-determined conditions to provide a better gaming experience, and decides on the opponent to match with the player who made the match request while easing the conditions as needed. Alternatively, if no suitable player is found under the first match criteria, the server control unit 201 may, for example, randomly select one player from those who made match requests at the same time as the opponent, or extend the search period until the specified timeout period, and search again for a player matching the match criteria.

[0058] When player matchmaking is complete, the server control unit 201 sets up a communication dialogue for sending and receiving various information related to the battle game between the two matched players. This communication dialogue information, such as matchmaking result information, is sent to the player terminals 100 used by each of the two players. When the control unit 101 of the player terminal 100 receives the communication dialogue information, it begins processing the connection to that communication dialogue.

[0059] <The Play> By connecting the player terminals 100 of each player in a battle to a communication interface, a battle game between two matched players can begin. In the client application running on each player terminal 100, when the two players' player terminals 100 are connected to the communication interface, game-related processing for the battle game begins, and the game screen is displayed.

[0060] Here, the battle game is executed under the condition that the battle deck contains one leader card and one or more member cards. To ensure fairness, the battle deck is controlled to be uneditable when the game-related processing begins. Therefore, if the player's battle deck does not contain any member cards before the game-related processing begins, the system will accept input for selecting at least one member card to add the card and update the deck information to execute the game-related processing.

[0061] In the game-related processing executed on each player terminal 100, various information for game execution is generated based on the player's input of operations in the game, and then sent to the server 200. The server 200 manages the various information for game execution in each communication session and completes the process of sending (sharing) the information received from the player terminal 100 to other player terminals 100 participating in the communication session. In the game-related processing of the game, when the server 200 receives game execution information related to the opponent, it controls the display of the game screen based on that information. Therefore, the game system provides a gaming experience for remote players who want to play against each other via the server 200.

[0062] Client-side processing The following describes the client processing of the client application executed in the player terminal 100 of this embodiment using the flowchart in Figure 4. The processing corresponding to this flowchart can be implemented by the control unit 101, for example, reading the corresponding processing program stored in the memory device 102, unfolding it in the memory 103, and executing it. Furthermore, this client processing is described starting when the player's service login is completed, for example, by executing the client application in the player terminal 100. In the description related to this client processing, the player who logs into the service using the player terminal 100 during the execution of this processing is referred to as the "target player".

[0063] In S401, the control unit 101 determines whether the operation input related to the deck-building function has been completed. If the control unit 101 determines that the operation input related to the deck-building function has been completed, the processing is transferred to S402; if the control unit determines that the operation input has not been completed, the processing is transferred to S403.

[0064] In S402, the control unit 101 performs processing related to the deck-building function. In this embodiment, details of the processing related to the deck-building function are omitted, but as mentioned above, by utilizing the deck-building 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 the operation input related to the start of the game request has been completed. If the control unit 101 determines that the operation input related to the start of the game request has been completed, the processing is transferred to S404; if the control unit determines that the operation input has not been completed, the processing is transferred to S411.

[0066] In S404, the control unit 101 accepts the selection of the deck (battle deck) used by the target player in the battle game. The selection of the battle deck is completed based on the operation input of selecting any deck from the decks constructed with the target player. Before this selection, the control unit 101 obtains the deck information registered with the player from the server 200 and displays the corresponding decks selectively on the display 110.

[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, it transfers the processing to S406; if it determines that no leader card is registered, it returns the processing to S404. In the latter case, the server control unit 201 may, for example, display a notification on the display 110 indicating that a deck with a registered leader card has been selected.

[0068] In S406, the control unit 101 sends a matching request to the server 200, which includes the deck ID of the deck selected in S404 as the deck ID of the deck used in the battle. Based on the matching request, the server 200 performs matching processing to complete the determination of the player who will play against the opponent (hereinafter referred to as the opposing player).

[0069] In step S407, the control unit 101 determines whether a match has been made with the opposing player. This determination can be based on whether the server 200 has received match result information. If the control unit 101 determines that a match has been made with the opposing player, the process is transferred to step S408; if the match has not been made, the process is repeated.

[0070] In S408, the control unit 101 establishes a communication connection with the communication dialogue via communication I / F106 based on the communication dialogue information of the connection end contained in the matching result information.

[0071] In S409, the control unit 101 performs game-related processing for the battle game.

[0072] In step S410, the control unit 101 determines whether the game-related processing of the battle game started in step S409 has been completed. Here, the game-related processing of the battle game ends when the end conditions of the battle game are met and the battle result is determined. If the control unit 101 determines that the game-related processing of the battle game has been completed, it transfers the processing to step S411; if it determines that the processing has not been completed, it repeats the processing of this step.

[0073] In S411, the control unit 101 determines whether the operation input related to the end of the client application has been completed. If the control unit 101 determines that the operation input related to the end of the client application has been completed, it terminates the client processing; if it determines that the operation input has not been completed, it returns the processing to S401.

[0074] Matching Processing Next, the matching process performed by the server 200 in this embodiment will be explained using the flowchart in FIG5. The process corresponding to this flowchart can be implemented by the server control unit 201, for example, reading the corresponding processing program stored in the server memory device 202, expanding it in the server memory 203, and executing it. Furthermore, this matching process will be explained starting, for example, when a matching request is received from any player terminal 100. In the explanation related to this matching process, the player receiving the matching request is referred to as the "target player," other players making matching requests at the same time are referred to as "standby players," and the player matching with the target player is referred to as the "opponent player."

[0075] In S501, the server control unit 201 obtains information used to capture the opponent's information (capture information). In this embodiment, the server control unit 201 obtains the player ID of the player 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 as capture information. Here, various information related to the previous player can also be obtained from the battle history information contained in the target player's player information.

[0076] In S502, the server control unit 201 determines, based on the acquired information, whether there are any players among the idle players whose matching criteria match all types. That is, the server control unit 201 sets three matching criteria as acquisition conditions and attempts to acquire players from the idle players whose matching criteria match. If the server control unit 201 determines that there are players among the idle players whose matching criteria match all types, it transfers the processing to S505; if it determines that there are no such players, it transfers the processing to S503.

[0077] In S503, the server control unit 201 removes the lowest priority matching reference from the matching references of the current acquisition conditions and sets new acquisition conditions.

[0078] In S504, the server control unit 201 determines, based on the acquired information, whether there is a player among the idle players who matches the new acquisition condition. If the server control unit 201 determines that there is a player among the idle players who matches the new acquisition condition, the processing is transferred to S505; if it determines that there is no player, the processing is returned to S503. Furthermore, if no matching criteria are set as acquisition conditions, the server control unit 201 determines that all idle players match the new acquisition condition.

[0079] In step S505, the server control unit 201 selects players from the standby players who match the selection criteria, and decides one of these players as the opposing player. Here, the decision of the opposing player can also be made by drawing lots. The server control unit 201 sends the player ID of the decided opposing player as the matching result information back to the player terminal 100 used by the target player, completing this matching process. At this time, the server control unit 201 also sends matching result information displaying the match with the target player to the player terminal 100 used by the opposing player.

[0080] As explained above, according to the communication terminal of this embodiment, players can easily start a battle game. Furthermore, according to the information processing device of this embodiment, highly engaging matchmaking can be provided.

[0081] [Variation Example 1] In the above-described embodiment, the first matching criterion is defined as determining that the target player is not an opponent in a game they have played a specified number of times recently. However, the implementation of this invention is not limited to this. For example, when the difference in skill level between the target player and the opponent is small, it is difficult to imagine that even if these players were to play again, the game would proceed in a one-sided manner. In other words, when the difference in skill level between the target player and the opponent is large, even if these players were to play again in a short period of time, the game might proceed in the same way. On the other hand, between players with small differences in skill level, the possibility that the game might not proceed in the same way is higher.

[0082] Therefore, in player information management systems that include attributes such as game level, number of plays, or ranking based on game performance, the specified number of matches until a target player and the opposing player can be matched can be increased or decreased based on these attribute information. For example, multiple value ranges can be set based on the difference in the number of plays between players, and the specified number of matches can be changed depending on which value range the difference falls into. In this case, the specified number of matches should be increased for value ranges with larger differences.

[0083] [Variation Example 2] In the above-described embodiments and variations, it has been explained that when a player who has played against another player once is matched with a target player, the condition is that the target player will not be matched with that player in a specified number of games played. That is, for the matching of the same player with another player, the condition is the number of times the game has been played. However, the implementation of the present invention is not limited to this, and a specified time period may also be used as a condition.

[0084] [Variation Example 3] In the above embodiments and variations, it has been explained that the state after sending a match request is limited to the editable deck for the battle, but the implementation of the present invention is not limited to this. In one embodiment, it can also be configured such that the battle deck is not editable after sending the match request, provided that the battle deck is completed at the time the match request is sent (e.g., the difference between the total value and the value cap is reached at a threshold value). This state is envisioned for example in game modes such as those where players are evaluated and ranked based on their battle performance, and where serious competition between players is the premise, in order to make the evaluation more appropriate.

[0085] [Implementation Mode 2] In Embodiment 1 described above, it was explained that upon receiving a matchmaking request, the server control unit 201 matches one player selected from players who submitted matchmaking requests at the same time with the player associated with that request. That is, in the game system of the above embodiment, the matchmaking method for the prescribed number of players in a battle game is determined by the matchmaking process executed in the server 200 without considering the players' preferences. However, the matchmaking method in online battle games is not limited to the server control unit 201 forcibly determining the opponent. For example, there is also a matchmaking method where some players enter a standby state to accept battle requests, and other players not in standby state select their desired player from among the standby players to submit a battle request. In this matchmaking method, since players not in standby state can submit battle requests to their desired player, unlike Embodiment 1, it achieves matchmaking that considers the players' preferences. In this embodiment, a method for achieving highly engaging matchmaking in this matchmaking method will be explained.

[0086] "match" In the game function of the client application in this embodiment, when a request to start a game is received, the application then selects whether to accept a game request from another player (hereinafter referred to as a request to wait) or to accept a game request from another player currently waiting (hereinafter referred to as a request). If either request is selected, the client application then, similar to Embodiment 1, accepts the selection of the deck for the game and sends a matchmaking request from the player terminal 100 to the server 200.

[0087] In the game function of this implementation, the timing of sending the match request varies depending on whether the target player chooses to request either a standby request or a request.

[0088] Specifically, when a player selects to request a standby status, if they subsequently select their deck for battle, the player's player ID, the deck ID for their battle deck, and a match request including the standby request are sent from the player terminal 100 to the server 200. When the server control unit 201 receives the match request, it adds the player to the standby players in the battle request standby state for management.

[0089] On the other hand, when a player selects to submit a request, if they subsequently select their deck for the match, the player's player ID, the deck ID for the match, and a "waitlist request" containing the request are sent from the player terminal 100 to the server 200. When the server control unit 201 receives the waitlist request, it sends information on matchmaking candidates, including multiple waiting players, back to the player terminal 100 in order to allow the player to select a player to submit a match request. Upon receiving the matchmaking candidate information, the player terminal 100 displays the application screens of each player in the matchmaking candidate list in the game window related to the client application, indicating that the matchmaking request is open.

[0090] Figure 6 shows an example of the application screen configuration. In the example of Figure 6, the application screen 600 is configured to configure three idle players included in the matchmaking candidate information as matchmaking candidates 601a-c. For example, by completing the operation input for each area, the application for a match with the corresponding idle player can be accepted. That is, the matchmaking candidates 601a-c display the matchmaking candidates that the target player can match with. When the target player completes the operation input to select any matchmaking candidate, a matchmaking request containing the player ID of the idle player in the matchmaking candidate is sent to the server 200. When the matchmaking request is received, the server control unit 201 performs the process of matching the target player with the idle player specified by the player ID contained in the matchmaking request.

[0091] Details are described below, but the matchmaking waitlist 601 does not display all players waiting for match requests at the same time, but rather displays players selected by the server control unit 201 and whose match requests from the target player are limited to the maximum number (3) or less. In this way, by limiting the number of players displayed as matchmaking waitlist 601, the prolonged matchmaking time caused by the target player hesitating about which player to match with can be avoided.

[0092] On the other hand, by limiting the number of standby players displayed as matchmaking candidates 601, the target player can be given the impression that there are fewer players interested in the game. Therefore, in the application screen 600, as shown in the figure, in addition to matchmaking candidates 601a~c, non-candidate players 602a~g are configured as active elements. Therefore, when the server control unit 201 sends the matchmaking candidate information back to the player terminal 100, the information of the players displayed as non-candidate players 602 is also sent at the same time.

[0093] Here, since the player displayed as non-candidate player 602 is an active element, it can be, for example, a player selected from standby players who are not selected as matchmaking candidates, a player selected from logged-in players based on the prescribed rules, or a player selected from all players including logged-out players.

[0094] The difference between matchmaking candidates 601 and non-candidate players 602 lies in the fact that, on the application screen 600, the former displays a status indicating that the target player can apply for a match, while the latter displays a status indicating that the target player cannot apply for a match. Furthermore, as shown in the illustration, the display size of matchmaking candidates 601 is set to larger. Also, as a reference when selecting a target player from matchmaking candidates 601 to apply for a match, the matchmaking candidate information includes detailed information about each waiting player, such as player name, stats, and attribute information. Therefore, detailed display icons 603a-c are displayed for each of the matchmaking candidates 601a-c. By inputting an operation on this icon, the detailed information of the corresponding waiting player can be displayed. This is also different from non-candidate players 602. That is, as shown in the illustration, for non-candidate players 602a-g, the detailed display icon 603 is not displayed, and the target player cannot view the detailed information.

[0095] The game system in this embodiment is configured to allow players from various geographical locations to battle against each other. Therefore, server 200 is not only a single server, but can also be configured as a group of multiple servers cooperating. In this embodiment, in order to allow the target player to battle against players from various regions, a map image simulating the Earth is displayed as a background image 604 on the application screen 600. Here, the map image of background image 604 can also change its position in the centrally displayed map image based on geographical information associated with player terminal 100 (e.g., the geographical location information of player terminal 100). That is, when a player from Japan makes a waitlist request, the map image of background image 604 is displayed with Japan as the center, and when a player from the United States makes a waitlist request, the map image of background image 604 is displayed with the United States as the center.

[0096] Furthermore, since the game system in this embodiment provides a TCG (Trading Card Game) for gameplay, in the example of Figure 6, the matchmaking candidates 601 and non-candidate players 602 configured on the application screen 600 are displayed as cards. However, it should be easily understood that the implementation of this invention is not limited to this.

[0097] To implement a better game progression in multiplayer battles, the server control unit 201, similar to Embodiment 1, selects players as matchmaking candidates from the standby players based on multiple matchmaking criteria. When selecting players as matchmaking candidates, the server control unit 201 sets the selection information based on the information contained in the candidate acquisition request. In this embodiment, the server control unit 201 obtains the player ID of the player most recently matched with the target player, the card ID of the leader card related to the player in the most recent battle, and the card ID of the leader card of the target player's battle deck, and sets this as the selection information. Furthermore, based on this selection information and the three matchmaking criteria, the server control unit 201 selects a maximum number (3) of standby players. The processing related to the capture can be performed in the same way as the matching process in Implementation Form 1 (S501~S505), but the difference is that instead of deciding one player from the captured players as the opposing player, the maximum number of players from the captured players are decided as matchmaking candidates, and the information of the matchmaking candidates is sent back to the player terminal 100.

[0098] In this case, if the maximum number of players includes players selected based on matching criteria for different combinations, the matchmaking candidate information can include information identifying more players with matching criteria, which can be clearly displayed on the application screen. For example, if there are two players with matching criteria consistent with all types, and to ensure the maximum number of matchmaking candidates is reached, the remaining player is selected from those two players with matching criteria. The former two players can then form a more engaging game, and their appearance on the application screen 600 will differ from that of the remaining player.

[0099] To facilitate understanding of the invention, this embodiment of the game system describes the matching of a matchmaking candidate with a target player when the candidate completes a match request. However, the invention is not limited to this. For example, it is also conceivable that during the standby period of a match request, the player's communication is interrupted, or the player can choose whether to accept the match request and reject it. In such cases, the display of the application screen 600 continues until the match is completed (the match result information is received), and the process ends with the match completion. In this case, to avoid sending duplicate match requests, the system is controlled so that after sending a match request, the input for selecting a matchmaking candidate 601 is not processed on the application screen 600.

[0100] Furthermore, since multiple player terminals 100 may receive matchmaking requests simultaneously, the number of players on standby changes constantly. Therefore, the server control unit 201 can, for example, update the matchmaking candidate information at predetermined time intervals and periodically send it to the player terminals 100. When the player terminal 100 used by the target player receives new matchmaking candidate information, the display content of the application screen 600 is updated. Here, when the target player displays detailed information related to any matchmaking candidate upon receiving matchmaking candidate information, it is assumed that the target player is discussing a match against that matchmaking candidate. Therefore, the control unit 101 can also control the display content of the application screen 600 to maintain the previously received matchmaking candidate information.

[0101] [Variation Example 4] In Embodiment 2 described above, similar to Embodiment 1, players are selected as matchmaking candidates based on a matching criterion of the most recently played player or the leader card of the deck. However, the implementation of this invention is not limited to this. For example, in a system where player information includes attributes such as game level or number of plays, or player rank based on game performance, a matching criterion related to the similarity of the target player's attribute information may also be included. This matching criterion is based on the condition that the attribute information of the player serving as a matchmaking candidate for the target player is similar to that of the target player. Here, whether the attribute information is similar can also be determined by, for example, whether the difference in game level, number of plays, or rank is below a predetermined threshold. With this configuration, the chances of players with similar gaming skills playing against each other increase, thereby increasing players' interest in competitive games.

[0102] In this configuration, to facilitate a better game progression for the player actively requesting a match, the matchmaking waiting list can include players of the same or lower rank as the target player. Alternatively, the matchmaking waiting list can include players of a higher rank than the target player, but the number of players of a lower rank than the target player can be greater than the number of players of the same or higher rank.

[0103] [Implementation Mode 3] The above implementation forms and variations primarily describe the matchmaking process targeting all logged-in players. However, since service usage periods vary, and each player's playstyle (play frequency or playtime) differs, player skill levels can naturally vary. Therefore, in a game mode that matches all players, when matching players with significantly different skill levels, it may especially reduce the interest of players with lower skill levels in the game. Therefore, in this implementation of the game, a ranked matchmaking mode is included to achieve higher levels of enjoyment and facilitate matching players with similar skill levels.

[0104] Level Matching Mode In ranked matchmaking mode, players are assigned a ranking score based on their performance in the game, and their ranking is determined by the accumulated score. Furthermore, ranked matchmaking games are structured to match players who are essentially classified as being in the same ranking category with each other. In other words, in ranked matchmaking mode, players are separated into different ranking categories, and matchmaking is controlled by matching players within the same ranking category.

[0105] In a given scenario, player ranks can be set up in six progressively higher order: Bronze, Silver, Gold, Platinum, Master, and God. For each rank, a minimum score (the minimum score required for each rank) is defined, with higher ranks requiring a higher minimum score. Specifically, a player's rank is determined by the maximum score threshold that exceeds the player's accumulated rank score. For example, in a scenario where the minimum score for Bronze is 0, for Silver it's 10,000, for Gold it's 30,000, for Platinum it's 50,000, for Master it's 70,000, and for God it's 90,000, a player with a accumulated rank score of 55,000 would be ranked Platinum.

[0106] When a player wins a battle game, the server control unit 201 assigns a fixed level score to that player and updates the corresponding player information's attribute information. At this time, the server control unit 201 compares the updated accumulated level score with the threshold values ​​for each level to determine a reclassified level. Conversely, when a player loses or draws in a battle game, the server control unit 201 does not assign a level score to that player, nor does it update the corresponding player information's attribute information.

[0107] Therefore, in the ranked matchmaking mode, players with more wins in the game are generally assigned higher ranked scores, resulting in a larger cumulative score, and these players are classified as high-ranked. In other words, the ranked system in ranked matchmaking mode is equivalent to a parameter evaluating each player's skill level. The ranked information in ranked matchmaking mode is managed as attribute information included in each player's player profile. The server control unit 201 obtains this ranked information during the ranked matchmaking process to determine the opponent. This structure makes it easy to classify players with higher skill levels into high-ranked teams, thus providing a more engaging and fairer gaming experience.

[0108] <Betting Function> However, in the scenario where a fixed ranking score is awarded based on victories in competitive games, a considerable number of competitive games need to be played and won before a player can be classified into an appropriate ranking (where there are many players with similar skill levels). In other words, in this scenario, players with higher skill levels require more wins or games to be classified into an appropriate ranking. However, the duration of available games varies depending on the player's circumstances, which may not guarantee a better gaming experience for some players.

[0109] Therefore, in this implementation of the battle game, in the level-matching mode, a betting function is set up as a plan to easily classify players into appropriate levels regardless of the number of times they have played. The betting function is a plan where players can obtain level points as additional reward points when they win in a battle game. More specifically, the betting function works as follows: For a battle game executed based on a match request from a target player, at least a portion of the level points associated with the target player's status are bet on the target player's own victory. This is then separately assigned to the level points bet on the win (the so-called betting points / rewards, hereinafter referred to as betting elements) in a battle game, along with a fixed level point value. That is, the more level points a target player bets as betting elements, the more additional reward points they receive when they win in a battle game. Therefore, players with higher gaming skills can more quickly increase their accumulated level points by actively utilizing the betting function, making it easier to reach the appropriate level.

[0110] To ensure fairness among players, betting on betting elements using the betting function is limited to processing before matchmaking. Furthermore, the rank score bet as a betting element becomes unassigned to the target player if they lose in the game. In other words, in games using the betting function, the betting elements related to the target player are considered to be associated with that player and are temporarily managed as a stored state on server 200; the processing of this association changes based on the outcome of the game.

[0111] More specifically, when a player wins in a match, the betting element reverts to its original state while maintaining the connection with the player, granting the player additional bonus points as a level score. Conversely, when a player loses, the betting element is disconnected from the player, leaving the player without the betting element (a state of losing the betting element) and without additional bonus points. Furthermore, when a match ends in a tie, the betting element reverts to its original state while maintaining the connection with the player, without granting additional bonus points as a level score.

[0112] Furthermore, the level score for bonus points is set to be less than the amount of betting elements, in a way that the number of players classified as high-level players does not increase excessively. Preferably, the more betting elements there are, the smaller the ratio (payout rate) of the level score awarded as bonus points relative to the amount of betting elements.

[0113] The accumulated points awarded to a player may vary depending on the processing of the ranking points assigned or associated with the game using the betting function. Therefore, when there is a change in the accumulated points awarded, the server control unit 201 determines the ranking of the player to be classified. That is, if the player wins in a game using the betting function, they are awarded more ranking points, so the player may be classified into a higher ranking (upgrade). On the other hand, if the player loses in a game using the betting function, they lose some ranking points, so the player may be classified into a lower ranking (downgrade).

[0114] In other words, while the betting function exposes players to risk, it also makes it easy for them to reach an appropriate level and provides a thrilling and highly entertaining gaming experience.

[0115] In this implementation of the battle game, the score for each player's level, which can be bet using the betting function, is not a value that players can arbitrarily specify. Instead, it can be specified from a range of predetermined quantities or defined unit units. The betting screen for accepting betting elements is shown in Figure 7, for example, and can be configured to allow selection from options 701a-f, which also include options without betting. In the example of Figure 7, when the target player's accumulated score is currently 85000, and the betting selection option 701a contains 5000, upon winning the battle game, the player receives a fixed score of 1000 and an additional 4000 bonus points, bringing the accumulated score to 90000 and the level to God. Upon losing, the player loses the 5000 betting element, and the accumulated score becomes 80000.

[0116] Here, to ensure fairness in the game or prevent large fluctuations in rank, the option to specify the rank score for betting can be changed according to the rank of the target player. That is, in the example of Figure 7, since the target player's rank is Master, options 701a~e are displayed. However, for example, in Platinum, a lower rank, option 701a may not be specified or displayed. Furthermore, to prevent the accumulated score from becoming negative, the specification of the betting element can be reasonably controlled based on the state of assigning the target player the desired amount of rank score.

[0117] (Display of betting information) If a player completes a match using the betting function, the betting information will be displayed on the game start screen of the two players, as shown in Figure 8, in a manner that all players participating in the game can confirm. This display of betting information can serve as an indicator of each player's enthusiasm for the game, thereby increasing player motivation and enhancing the enjoyment of the match.

[0118] In addition, the game can be customized to display different visual effects on the game start screen or the game screen during the battle, such as adding cheers or flying confetti, based on the total amount of bets placed by the two players, thereby enhancing the fun of the battle game.

[0119] In this embodiment, details of the matching process are omitted. However, from the perspective of increasing the fun by utilizing the amount of betting elements, for example, in the matching method of embodiment 1, it can also be configured to use a matching benchmark to match players who bet under the same conditions in the matching process for matching requests related to players who bet high amounts or have a specified level score in the betting elements.

[0120] Grade Decision Processing The following describes the specific processing of the level determination process related to the level matching mode in the server 200 of this embodiment using the flowchart in FIG9. The processing corresponding to this flowchart can also be implemented by the server control unit 201, for example, reading the corresponding processing program stored in the server memory device 202, and executing it in the server memory 203. Furthermore, this level determination process is explained in the context of a battle game implemented in any communication conversation related to the level matching mode, starting when the end conditions of that battle game are met. In the explanation of this level determination process, the battle game that meets the end conditions is referred to as the "target game".

[0121] In S901, the server control unit 201 selects one player from among the players participating in the target game who has not yet decided on the new level after the target game, as the target player.

[0122] In S902, the server control unit 201 determines whether the target player has used the betting function related to the target game. If the server control unit 201 determines that the target player has used the betting function, the processing is transferred to S903; if it determines that the player has not used the function, the processing is transferred to S905.

[0123] In S903, the server control unit 201 determines the level score of the additional bonus points awarded to the target player based on the target player's battle results in the target game and the betting elements related to the target player. When the target player wins, the server control unit 201 determines the amount of additional bonus points corresponding to the betting elements and awards it to the target player. That is, the server control unit 201 performs update processing of the target player's player information, changing the accumulated level score to a value plus the additional bonus points. Furthermore, when the target player's battle results in a draw or loss, the server control unit 201 sets the additional bonus points to 0. In this case, since the target player's accumulated score remains unchanged, the server control unit 201 can simply set the additional bonus points to 0 without performing update processing of the target player's player information.

[0124] In S904, the server control unit 201 determines and executes the handling of betting elements held in a custodial state for the target player based on the battle results of the target player in the target game. When the target player's battle result is a win or a draw, the server control unit 201 maintains the association between the betting element and the target player, returning from the custodial state to the target player's assigned state. At this time, since the target player's accumulated assigned number does not actually change, the server control unit 201 can simply perform the process of de-custodialing without updating the target player's player information. Furthermore, when the target player's battle result is a loss, the server control unit 201 deactivates the association between the betting element and the target player, and the target player enters a state where they have lost their betting element. That is, the server control unit 201 performs the process of updating the target player's player information, changing the accumulated assigned number of level scores to the value of deducting the betting element amount.

[0125] In S905, the server control unit 201 determines the level score of the normal reward points based on the battle results of the target player in the target game. When the target player wins the battle, the server control unit 201 assigns the target player the normal reward points (a fixed value of level score). That is, the server control unit 201 performs update processing of the target player's player information, changing the accumulated level score to a value plus the fixed value. Furthermore, when the target player's battle results in a draw or loss, the server control unit 201 sets the normal reward points to 0. In this case, since the target player's accumulated reward points do not change, the server control unit 201 can simply set the normal reward points to 0 without performing update processing of the target player's player information.

[0126] In S906, the server control unit 201 determines the reclassification level of the target player based on the accumulated score of the current target player's level. More specifically, the server control unit 201 compares the accumulated score of the target player's level with the score threshold to determine the reclassification level. When the server control unit 201 determines the reclassification level, it updates the player information of the target player.

[0127] In S907, the server control unit 201 determines whether to decide on a new level for all players participating in the target game. If the server control unit 201 determines that a new level has been decided for all players, it completes the level decision process. If the server control unit 201 determines that no decision has been made, i.e., there are players whose level has not been decided, it returns the process to S901.

[0128] As explained above, the information processing device according to this embodiment can provide a better gaming experience regardless of the number of times the game has been played. That is, players with higher gaming skills can more easily level up to an appropriate level to compete against players with the same gaming skills, thereby avoiding matchmaking that results in a skill gap between players of lower skill levels.

[0129] [Variation Example 5] In the above-described embodiment 3, it was explained that when a player loses in a game using the betting function, their rank may be downgraded due to the deduction of rank points. However, the implementation of this invention is not limited to this. Downgrading is undesirable for players, especially those at lower ranks such as Silver or Gold, who may lose the motivation to continue playing. Therefore, downgrading due to the deduction of rank points can also be based on the condition that the player's rank is at a higher level, such as Master or above. That is, for example, for players below Platinum rank, even if their rank points are reduced to below the rank-related score threshold, they may not be downgraded to a lower rank and can maintain their current rank.

[0130] Furthermore, in Embodiment 3, it has been described that when a player wins a game using the betting function, they are immediately upgraded based on their score exceeding the score threshold for a higher-level rank. However, the implementation of this invention is not limited to this. Regarding upgrades, when the score threshold is exceeded, the player can also be granted the right to challenge for an upgrade battle to determine eligibility for the corresponding rank. Upgrades are granted based on the player's performance in this upgrade battle, which satisfies the upgrade conditions. An upgrade battle could be, for example, a game against a player of the same rank. Upgrades are confirmed when the player wins more than half of the required number of games. Here, the required number of games can be adjusted according to the rank, or the higher the rank, the more games are required, and the more difficult it is to achieve the upgrade conditions.

[0131] [Variation Example 6] In the above-described embodiment 3, the method of accepting the designation of level scores as betting elements from the options of a predetermined quantity or a specified unit has been described. However, the implementation of the present invention is not limited to this. For example, it may be configured such that when the total number of level scores in the assigned state of the target player does not meet the minimum amount that the player can designate as a betting element, all level scores in the assigned state of the target player may be designated as betting elements (so-called all-in). Alternatively, to increase the player's enjoyment, it may be configured such that an all-in option can be designated regardless of the total number of level scores in the assigned state.

[0132] [Variation Example 7] In the above-described embodiment 3 and its variations, the form in which level scores can be designated as betting elements has been explained, but the implementation of the present invention is not limited to this. For example, in the form in which other types of game elements besides level scores are assigned to the player, or in the form in which other types of game elements are assigned to the player in place of level scores, it is also possible to configure the betting function to allow the other types of game elements to be designated as betting elements. In this form, the types of game elements that the player can designate as betting elements can also change according to the player's classification level. Furthermore, in the form in which the types of game elements that can be designated as betting elements change according to the level, the higher the player's classification level, the more likely they are to designate game elements of a higher value in the battle game as betting elements, such as those that can be obtained through victory, thereby increasing the fun of the battle game.

[0133] [Variation Example 8] In the above implementation forms and variations, various forms of matching criteria used to match the target player who makes the match request or to select match candidates have been described. However, these matching criteria can also be changed and combined. Furthermore, the priority order of each matching criterion can of course be appropriately changed based on other factors such as the content of the battle game or the level.

[0134] Figure 10 illustrates one such combination. The table in Figure 10 illustrates the multiple matchmaking criteria referenced in the matchmaking process for the aforementioned ranked matchmaking mode in multiplayer games, along with their priority order. Each column of the table shows, for a single matchmaking criterion, the selection conditions determined associated with that criterion, the prerequisites for applying that criterion, and the priority order of that criterion among multiple matchmaking criteria. As shown, the higher the column in the figure, the higher the priority of the matchmaking criteria, making it easier to ensure consistency with the conditions when selecting idle players related to the target player.

[0135] In the example of Figure 10, the highest priority condition is to prevent the target player from being matched with the player they have played against in the last 10 games. Conditions related to the target player's level, betting elements, and the captain card of the deck are also determined.

[0136] Among the conditions relating to the rank of the object player, the conditions were determined to be different in the case where the object player was classified to the highest rank i.e. God, and in the case of being classified into a rank other than that. In more detail, when constituting a situation where the rank of the target player is God, the matching benchmark for the priority of the low position is determined by matching standby players whose rank is ±50 places with the target player, but in the absence of such standby players, the order of ±200 standby players and standby players whose rank is God is eased. On the other hand, in cases where the rank constituted as the object player is other than God, the matching benchmark for the priority of the lower position is determined by matching standby players of the same rank, but in cases where such standby players do not exist, the order of standby players classified as ±1, and standby players classified as ±2 is eased.

[0137] Further, in the conditions related to the captain's card of the deck, the determination of the target player's rank other than God is a prerequisite regarding the determination of the target player's level other than God in relation to a captain card that is not the same as the use deck of a player recently played against by the target player, or not for the matching benchmark of a captain card that is not the same as the target player's match-use deck. It is based on the strategy of fighting games played by players of that rank with each other among the gods of the highest rank is very diverse, and each person's game technique is also equivalent, and can launch a counterattack that is not based on the compatibility of the deck of favorable and unfavorable counterattacks.

[0138] Also, with respect to the conditions related to the betting elements, it is determined as a prerequisite that the betting elements bet by the target player are above the prescribed amount. It causes the players of the so-called high amount of bets to play against each other not only causing an increase in the interest of the play game, but also producing the following effect. For example, this behavior can be inhibited by being formulated so that even if a player with higher game skills uses sub-accounts to repeat high-amount bets and wants to perform a play for the purpose of improperly operating the results or accumulating conferred numbers (the so-called fake novice), this behavior can be suppressed by matching standby players of high-level levels who are prone to high-amount bets.

[0139] [Summary of Implementation Forms] The foregoing embodiments disclose at least the following programs, communication terminals, and game systems.

[0140] (1) A program that enables a computer performing a matchup game in which players play against one another: construction processing, which is based on the player's operational input, constructing a match-use deck for use in the above-mentioned match-up games; and Send processing which sends to the matching server a match request for a match opponent, i.e., a match request containing information related to the said match-use deck constructed in the above construction processing, based on the operational input related to accepting the start of the play start of the said matchup game; In the aforementioned battle games, game elements of category 1 and game elements of category 2, which are different from those of category 1, appear. The aforementioned decks for battle can include game elements from both category 1 and category 2. The matchmaking request is sent to the matchmaking server during the above-mentioned sending process, provided that the game elements of the first category mentioned above are registered in the above-mentioned deck for battle.

[0141] (2) The program as in (1), wherein the program causes the computer to execute the execution process of the above-mentioned battle game with the opponent as a condition for matching the opponent with the matchmaking server; The above-mentioned deck-building process is limited to the period before the execution of the aforementioned battle game. It does not accept changes to the game elements of the first category registered in the aforementioned battle deck. On the other hand, it accepts changes to the game elements of the second category registered in the aforementioned battle deck.

[0142] (3) As in (2), during the execution of the above-mentioned battle game, the above-mentioned construction process does not accept changes to the above-mentioned Class 1 game elements and the above-mentioned Class 2 game elements registered in the above-mentioned battle deck.

[0143] (4) The program as in (2) or (3) wherein the above execution process is performed on the condition that the above battle deck contains one game element of the first category and one or more game elements of the second category.

[0144] (5) Any of the programs in (1) to (4) wherein the above construction process is derived from the game elements corresponding to the player and the game elements selected by the player's operation input are registered in the above-mentioned battle deck.

[0145] (6) Any of the procedures in (1) to (5), wherein the above-mentioned deck-building process can construct one or more decks for use in the above-mentioned competitive game. The above program enables the computer to perform selection processing based on the player's input, choosing one deck from the above one or more decks as the deck for the game.

[0146] (7) Any of the programs in (1) to (6), wherein the above-mentioned battle game sets parameters for each player in the battle to determine whether the player can continue the game. The game elements in category 1 above are those that have multiple effects that can be switched based on the parameters described above. The game elements in category 2 above are game elements that have an effect that does not require parameter switching as described above.

[0147] (8) A communication terminal that executes a player-versus-player game and possesses: A deck-building mechanism that constructs a deck of cards for use in the aforementioned competitive game based on player input; and The sending mechanism, based on the operation input related to starting the aforementioned battle game, sends a matchmaking request for an opponent, including information about the battle deck constructed by the aforementioned deck-building mechanism, to the matchmaking server; and In the aforementioned battle games, game elements of category 1 and game elements of category 2, which are different from those of category 1, appear. The aforementioned decks for battle can include game elements from both category 1 and category 2. The aforementioned sending mechanism sends the aforementioned matchmaking request to the aforementioned matchmaking server on the condition that the aforementioned deck of cards for the battle contains the aforementioned game elements of category 1.

[0148] (9) A game system comprising: a communication terminal for executing a battle game in which players compete against each other, and a matchmaking server for matching players in the battle game; The aforementioned communication terminal has the following features: A deck-building mechanism that constructs a deck of cards for use in the aforementioned competitive game based on player input; and The sending mechanism, based on the operation input related to starting the aforementioned battle game, sends a matchmaking request for an opponent, including information about the battle deck constructed by the aforementioned deck-building mechanism, to the aforementioned matchmaking server; and In the aforementioned battle games, game elements of category 1 and game elements of category 2, which are different from those of category 1, appear. The aforementioned decks for battle can include game elements from both category 1 and category 2. The aforementioned sending mechanism sends the aforementioned matchmaking request to the aforementioned matchmaking server on the condition that the aforementioned deck of cards for the battle contains the aforementioned game elements of category 1.

[0149] (10) The game system as described in (9), wherein the matchmaking server has a matchmaking mechanism that matches the battle game with a specified number of players selected from the players corresponding to the received matchmaking requests, based on a plurality of matchmaking criteria; The aforementioned communication terminal further includes an execution mechanism that executes the aforementioned battle game with the specified number of players participating, based on the condition of being matched by the aforementioned matching mechanism.

[0150] (11) The game system as described in (10), wherein the above-mentioned multiple matching criteria include the criteria related to the game elements of the first category mentioned above, The aforementioned matchmaking system prioritizes matching players who are logged into the aforementioned deck of cards and whose game elements differ from those in Category 1 of the aforementioned game elements.

[0151] (12) In the game system of (11), the above multiple matching criteria include the criteria related to the matching frequency of the same player with each other. The aforementioned matchmaking agency controls the process by not matching the first player corresponding to the aforementioned matchmaking request with a second player who was most recently matched with that first player.

[0152] (13) In the game system of (12), among the above multiple matching criteria, the matching frequency of the same player is given priority over the game element-related criteria of the first category.

[0153] (14) A game system like any of (10) to (13), in which attribute information is associated with various aspects of the player. The aforementioned multiple matching criteria include those related to the similarity of the aforementioned attribute information associated with players. The aforementioned matching agency will match the specified number of players who have the same or similar attribute information.

[0154] [Other Implementation Forms] The invention is not limited to the above-mentioned implementation forms; various changes and modifications can be made within the scope of the invention's intent.

[0155] 100: Player Terminal 101: Control Department 102: Memory Device 103: Memory 104: GPU 105: Operation I / F 106: Communication I / F 110: Monitor 120: Speaker 200: Server 201: Server Control Department 202: Server memory device 203: Server Memory 204: Server Communication I / F 300: Network 600: Application Screen 601a~601c: Matching Candidates 602a~602g: Not a substitute player 603a~603c: Detailed icon display 604: Background Image 701a~701f: Options S401~S411: Steps S501~S505: Steps S901~S907: Steps

Claims

1. A program that causes a computer executing a player-versus-player game to perform: a deck-building process, which constructs a deck for use in the game based on player input; a sending process, which sends a matchmaking request for an opponent, including information related to the deck constructed in the deck-building process, to a matchmaking server based on input related to starting the game; and an execution process, which executes the game against the opponent provided that the matchmaking server has matched the player; wherein in the game, a first category of game elements and a second category of game elements different from the first category appear; the deck can contain both the first and second category of game elements; and the sending process sends the matchmaking request to the matchmaking server provided that the first category of game elements is contained in the deck. The aforementioned deck construction process, after sending the aforementioned matchmaking request and before the aforementioned battle game is executed, does not accept changes to the game elements of the aforementioned first category registered in the aforementioned battle deck, but accepts changes to the game elements of the aforementioned second category registered in the aforementioned battle deck.

2. As in request item 1, the above-mentioned deck-building process, during the execution of the above-mentioned battle game, does not accept changes to the above-mentioned Class 1 game elements and the above-mentioned Class 2 game elements registered in the above-mentioned battle deck.

3. The program as requested in Request 1, wherein the above execution process is conditional upon the above-mentioned battle deck containing one game element of the first category and one or more game elements of the second category, and the above-mentioned battle game is executed.

4. As in request item 1, the above-mentioned construction process is derived from the game elements corresponding to the player, and the game elements selected by the player's operation input are registered in the above-mentioned battle deck.

5. The program as described in Request 1, wherein the above-mentioned deck-building process can build one or more decks for use in the above-mentioned battle game, and the program causes the computer to perform a selection process based on the player's input, selecting one deck from the above-mentioned one or more decks as the deck for the battle.

6. In any of the requests 1 to 5, the above-mentioned battle game sets parameters for each player to determine whether the player can continue the game. The game element of category 1 is a game element that has multiple effects that switch parameters according to the above. The game element of category 2 is a game element that has one effect that does not switch parameters according to the above.

7. A communication terminal that executes a player-versus-player game, comprising: a construction mechanism that constructs a deck for the game based on player input; a sending mechanism that sends a matchmaking request for an opponent, including information related to the deck constructed by the construction mechanism, to a matchmaking server based on input related to starting the game; and an execution mechanism that executes the game against the opponent as a condition for being matched by the matchmaking server; wherein in the game, a first category of game elements and a second category of game elements different from the first category appear; the deck can be registered with both the first and second category of game elements; and the sending mechanism sends the matchmaking request to the matchmaking server as a condition for the first category of game elements to be registered in the deck. After sending the matchmaking request and before the execution of the battle game, the aforementioned deck will not accept changes to the game elements of the first category registered in the battle deck, but will accept changes to the game elements of the second category registered in the battle deck.

8. A game system comprising: a communication terminal for executing a player-versus-player game, and a matchmaking server for matching players in the game; the communication terminal comprising: a construction mechanism for constructing a deck of cards for the game based on player input; a sending mechanism for sending a matchmaking request for an opponent, including information related to the deck of cards constructed by the construction mechanism, to the matchmaking server based on input related to starting the game; and an execution mechanism for executing the game against an opponent as determined by the matchmaking server; wherein in the game, game elements of category 1 and game elements of category 2 (different from category 1) appear, and the deck of cards can contain both category 1 and category 2 game elements. The aforementioned sending mechanism sends the aforementioned matchmaking request to the aforementioned matchmaking server on the condition that the aforementioned game elements of the first category are registered in the aforementioned battle deck. The aforementioned deck-building mechanism does not accept changes to the aforementioned game elements of the first category registered in the aforementioned battle deck after sending the aforementioned matchmaking request and before the aforementioned battle game is executed. On the other hand, it accepts changes to the aforementioned game elements of the second category registered in the aforementioned battle deck.

9. The game system of claim 8, wherein the matchmaking server has a matchmaking mechanism that matches a predetermined number of players selected from the players corresponding to the received matchmaking request for the battle game based on a plurality of matchmaking criteria; the communication terminal further has an execution mechanism that executes the battle game in which the predetermined number of players participate, provided that the matchmaking is performed by the matchmaking mechanism.

10. In the game system of request item 9, wherein the plurality of matching criteria mentioned above include the criteria related to the game elements of the first category mentioned above, the matching agency shall give priority to matching players who are logged into the game decks of the first category mentioned above and whose game elements are different.

11. In the game system of request item 10, wherein the plurality of matching criteria includes a criterion related to the matching frequency of the same player with each other, the matching agency controls the matching process in a manner that does not match the first player corresponding to the above matching request with the second player who was most recently matched with the first player.

12. In the game system of request item 11, among the above multiple matching criteria, the criterion related to the matching frequency of the same player to each other takes precedence over the criterion related to game elements of category 1.

13. In a game system as described in any of requests 9 to 12, where attribute information is associated with each player, the aforementioned multiple matching criteria include criteria related to the similarity of the aforementioned attribute information associated with the players, and the aforementioned matching agency matches the aforementioned specified number of players who associate the same or similar aforementioned attribute information.

Images