Game management server and computer program

Abstract

To provide a game management server for appropriately managing a player's participation in a match type game so as to prevent overpayment of a consideration.SOLUTION: A game server 1 manages participation in a match by a player 6 of a game in which multiple matches are performed at a lapse of time. The game server receives a setting of a match charge from a player who participates in a match, subtracts a consideration corresponding to a match charge set by a player from asset holdings of the player who loses a match, adds a consideration corresponding to a match charge set by a player who wins a match to the asset holdings of the player, and increases a required match charge that is the minimum value of a match charge required for a player's participation in a match as the start of the match is later from the start of a game.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a server for managing a game and a computer program. [Background technology]

[0002] There are competitive games in which players pay a fee to participate. For example, Japanese Patent Application Laid-Open Publication No. 2017-118980 (hereinafter referred to as Patent Document 1) discloses a game system that matches players and controls the execution of a multiplayer online game, and includes a means for controlling the execution of the game in response to payment of a fee. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2017-118980 A Summary of the Invention

[0004] In a game where multiple matches are played over time and players lose a match fee if they lose a match, players may end up paying too much in their quest to reach the top. Therefore, a game management server is needed that can properly manage players' participation in matches in a competitive game to prevent players from paying too much.

[0005] According to one embodiment, a server for managing a game manages the participation of players in matches in a game in which multiple matches are played over time. The server for managing a game is configured to accept the setting of a match fee from players participating in a match, deduct a consideration according to the match fee set by the player who loses the match from the assets on hand of the player who loses the match, add a consideration according to the match fee set by the player who wins the match to the assets on hand of the player who wins the match, and increase the required match fee, which is the minimum value of the match fee required for a player to participate in a match, the later a match starts after the start of the game.

[0006] According to one embodiment, a computer program causes a computer to function as a game management server that manages the participation of players in a game in which multiple matches are played over time. The computer program causes the computer to accept match fee settings from players participating in the match, deduct a consideration corresponding to the match fee set by the player who lost the match from the assets held by that player, add a consideration corresponding to the match fee set by that player to the assets held by the player who won the match, and increase the required match fee, which is the minimum match fee required for a player to participate in a match, the later a player starts a match after the start of the game.

[0007] Further details will be described in the following embodiments. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a schematic diagram of the game system. [Figure 2] FIG. 2 is a diagram conceptually showing the participation status of players in games provided by a game server of a game system and the number of tokens they hold. [Figure 3] FIG. 3 is a schematic diagram of the configuration of a game server. [Figure 4] FIG. 4 is a flowchart showing an example of the processing flow in the game server. [Figure 5] FIG. 5 is a schematic diagram of a screen for applying to participate in a game. [Figure 6] FIG. 6 is a schematic diagram of an application screen in which the application screen of FIG. 5 has been updated. [Figure 7] FIG. 7 is a schematic diagram of a screen for applying to participate in a game. [Figure 8] FIG. 8 is a flowchart showing a modified example of the flow of processing in the game server. [Figure 9] FIG. 9 is a schematic diagram of the configuration of a game system according to the second embodiment. [Figure 10] FIG. 10 is a schematic diagram of a display screen of a user terminal. [Figure 11] FIG. 11 is a flowchart showing an example of the flow of processing in the game server according to the second embodiment. [Figure 12] FIG. 12 is a schematic diagram of a screen for applying to participate in a game. [Figure 13] FIG. 13 is a diagram showing the configuration of a game system and a user terminal according to the sixth embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] <1. Overview of the game management server and computer program> (1) A game management server according to an embodiment manages the participation of players in a game in which multiple matches are played over time. The game management server is configured to accept a match fee setting from a player participating in a match, deduct a compensation corresponding to the match fee set by the player from the assets (tokens) of a player who loses the match, and add a compensation corresponding to the match fee set by the player to the assets of a player who wins the match. The required match fee, which is the minimum match fee required for a player to participate in a match, increases the later a player starts the match after the start of the game. The compensation gained if a player wins a match and lost if a player loses may be equal to the match fee, or may be at least a portion of the match fee that is less than the match fee set by the player, or may be an amount greater than the match fee that is set by the player. Furthermore, the "compensation corresponding to the match fee" deducted from the assets of a player who loses a match and the "compensation corresponding to the match fee" added to the assets of a player who wins the match may be calculated using different methods.

[0010] According to the processing performed by the game management server of the embodiment, the later a player attempts to participate in a match after the start of the game, the higher the required match fee. In other words, as time passes from the start of the game, a player must pay a higher match fee to participate in the game, and players whose assets do not meet the required match fee are eliminated. As a result, players who cannot win matches are prevented from participating in game matches at an early stage, preventing players from overpaying match fees (compensation).

[0011] (2) The game management server of (1) is preferably further configured to allow a player to participate in a battle if the battle fee set by the player is equal to or greater than the required battle fee. This prevents players who cannot set a battle fee equal to or greater than the required battle fee from being allowed to participate in a battle, thereby preventing overpayment of the fee.

[0012] (3) The game management server of (1) is preferably further configured to not allow players to set a battle fee less than the required battle fee. This prevents players who cannot set a battle fee equal to or greater than the required battle fee from participating in a battle, thereby preventing overpayment of the fee.

[0013] (4) The game management server according to (1) to (3) is preferably further configured to extract potential opponents for a player based on a battle fee set by the player. As an example, the game management server extracts other players who have the same battle fee set as the opponents as potential opponents. This allows the battle fees set by each player to be exchanged between the players depending on the outcome of the battle.

[0014] (5) In the game management server of (1) to (4), preferably, the battle fee is replaced with tokens, which are in-game currency. The game management server is preferably configured to have access to a first memory that stores the number of tokens held by players, and to change the number of tokens stored in the first memory by an amount corresponding to the battle fee set by the players, according to the results of the players' battles. In this way, the number of tokens held by players is managed according to the results of the battles.

[0015] (6) In the game management server of (5), preferably, tokens can be bought and sold by players, and the number of tokens stored in the first memory is changed according to the results of the buying and selling of tokens, thereby managing the number of tokens held by players according to the results of the buying and selling of tokens.

[0016] (7) In the game management server of (6), preferably, the token is a non-fungible token recorded on a blockchain, which allows the token to be traded in a third-party market.

[0017] (8) The game management server of (6) or (7) is preferably further configured to accept input of information regarding token buying and selling prices, extract at least one of a predetermined range of selling prices and a predetermined range of buying prices from the input buying and selling prices, and display it on the user terminal of the player displaying the game, thereby allowing the player to grasp at least one of the predetermined range of selling prices and the predetermined range of buying prices during a match.

[0018] (9) The game management server according to (5) to (8) is preferably further configured to accept input of information related to actions other than game operations by a player, and increase the number of tokens stored in the first memory by a specified number when the input information satisfies a predetermined condition. This allows a player to increase the number of tokens they possess by taking an action that allows them to input information that satisfies the predetermined condition.

[0019] (10) A game management server according to any one of (1) to (9), preferably having access to a second memory that stores operation information for player matches, and further configured to transmit, to a trading server, operation information for matches in which the player participated and that started after a specified time from the start of the game, among the operation information stored in the second memory. By limiting the match fee that a player can set so that it is higher the later the match starts from the start of the game, the number of players who can participate in the match decreases as time passes from the start of the game to the start of the match. This makes it possible to narrow down the players whose operation information is to be transmitted to the trading server to players who are strong in matches, and to reduce the number of players whose operation information is to be transmitted to the trading server.

[0020] (11) A computer program according to an embodiment causes a computer to function as a game management server that manages the participation of players in a game in which multiple matches are played over time. The computer program causes the computer to accept match fee settings from players participating in the match, deduct a payment corresponding to the match fee set by the losing player from the assets held by that player, add a payment corresponding to the match fee set by that player to the assets held by the winning player, and increase the required match fee, which is the minimum match fee required for a player to participate in a match, the later a player starts the match after the start of the game. By causing the computer to perform processing according to an embodiment, the later a player tries to join a match after the start of the game, the less likely they are to meet the required match fee, and the more players will be unable to participate in the match. As a result, overpayment of the payment is prevented.

[0021] <2. Examples of game management servers and computer programs> [First embodiment] [System Configuration] FIG. 1 is a schematic diagram of a game system 100. The game system 100 includes a game server 1. User terminals 5, 5A, 5B, etc. of multiple game players 6, 6A, 6B, etc. are connected to the game server 1 via a network 7 such as the Internet. The multiple user terminals 5, 5A, 5B, etc. are also collectively referred to as a user terminal 5. The user terminal 5 is an example of an interface for a player 6 who uses the game system 100, and is a smartphone, a personal computer, or the like.

[0022] The game server 1 functions as a game-providing server, and as an example, provides a game on the web. The player 6 causes the user terminal 5 to access the web and display the game screen provided by the game server 1 on the web. The user terminal 5 accepts game operations performed by the player 6 and passes information capable of identifying the operations (hereinafter, operation information) to the game server 1 via the web. The game server 1 changes the game screen on the web in accordance with the operation information. The game server 1 also functions as a game management server, and manages the participation of the player 6 in the game.

[0023] [Game Features] FIG. 2 is a diagram conceptually showing the participation status of players in a game provided by the game server 1 and the number of tokens they hold. The game provided by the game server 1 is a game in which multiple matches are played over time. The matches can be any type in which multiple players compete with each other using their skills to determine the winner, and are not limited to a specific competition. As an example, the match is assumed to be a one-on-one competition.

[0024] A game player applies to participate in a match to compete against an opponent. The opponent is determined randomly or through matching by the game server 1. Preferably, the game server 1 determines opponent candidates, and the player selects an opponent from among the candidates.

[0025] If a player loses a match, they lose tokens, and if they win, they gain tokens. Tokens are in-game currency, and as long as they can be counted, their units and forms can be any. Specific examples of tokens include, but are not limited to, tickets, coins, and points. In-game match fees (compensation) are replaced by tokens. One example of a token is digital data (e.g., a digital token).

[0026] A predetermined number of tokens (for example, five) may be given to a player by the game server 1 before the start of the game. The above-mentioned battle fee is required for a player to participate in a battle, and if the number of tokens held by a player falls below the required battle fee, which is the minimum battle fee required to participate in a battle, the player cannot participate in the battle. Therefore, a player who is weak at battles cannot participate in many battles. A player who is strong at battles can participate in more battles. In the following explanation, the tokens that a player gains when they win a battle and the tokens that they lose when they lose are assumed to be equivalent (the same amount) to the battle fee.

[0027] The required battle fee increases as time passes from the start of the game to the start of the battle. In other words, the later the battle begins, the more the required battle fee. Players who are weak in battles will have fewer tokens and will find it difficult to participate in battles later in the game. Players who are strong in battles will have more tokens and will find it easier to participate in battles later in the game.

[0028] To participate in a match, a player arbitrarily sets the number of tokens (hereinafter also referred to as match tokens) to be used as a match fee. The game server 1 causes a player who loses a match to lose the number of tokens that the player has set as match tokens from among the tokens held by that player. The game server 1 gives the number of tokens that the player has set as match tokens to a player who wins a match. In other words, if a player sets a large number of match tokens, they will gain more tokens if they win, but will also lose more tokens if they lose. Players can arbitrarily set the number of match tokens according to their own wishes.

[0029] The game server 1 predetermines the number of required tokens equivalent to the required battle fee according to the time elapsed from the start of the game to the start of the battle. The game server 1 increases the number of required tokens the later the battle starts from the start of the game. The player must set a number of battle tokens that is equal to or greater than the number of required tokens specified by the game server 1. Therefore, the later the player wants to participate in a battle from the start of the game, the more battle tokens they must set.

[0030] As an example, the game in FIG. 2 is made up of a first stage st1, a second stage st2, a third stage st3, and a fourth stage st4, which are switched over by the game server 1 as time passes. In the example of FIG. 2, the first to fourth stages represent the gradual progression of time from the start of the game. In each stage, multiple matches between players may take place. The start of multiple matches in each stage is the same as the start of the stage.

[0031] More specifically, in the example of Figure 2, the game server 1 starts the first stage st1 at time t0. The game server 1 sets the start of the battle in the first stage st1 as time t0. When time t1 is reached, the game server 1 switches the first stage st1 to the second stage st2. The game server 1 sets the start of the battle in the second stage st2 as time t1. When time t2 is reached from the start of the second stage st2, the game server 1 switches the second stage st2 to the third stage st3. The game server 1 sets the start of the battle in the third stage st3 as time t2. When time t3 is reached from the start of the third stage st3, the game server 1 switches the third stage st3 to the fourth stage st4. The game server 1 sets the start of the battle in the fourth stage st4 as time t3.

[0032] In the example of Fig. 2, the game server 1 specifies a larger number of tokens required for a battle in a later stage among multiple stages. In the example of Fig. 2, the game server 1 specifies a required number of tokens for a battle in the first stage st1 as 2, a required number of tokens for a battle in the second stage st2 as 5, a required number of tokens for a battle in the third stage st3 as 10, and a required number of tokens for a battle in the fourth stage st4 as 15. Therefore, a player must set the number of battle tokens to 2 or more to participate in a battle in the first stage st1, to 5 or more to participate in a battle in the second stage st2, to 10 or more to participate in a battle in the third stage st3, and to 15 or more to participate in a battle in the fourth stage st4.

[0033] Preferably, the number of tokens required for the first stage st1 defined by the game server 1 is less than the number of tokens given to all players before the start of the game, so that all players can participate in the battle in the first stage st1.

[0034] When the game starts, a player may participate in matches starting from the first stage st1, or may participate only in matches in later stages without participating in matches in earlier stages. Also, a player may only be able to participate in one match in each stage, or may participate in multiple matches in the same stage. Also, a player may participate from the start of the game, or may join the game midway through after the game has started.

[0035] [Game Server Configuration] 3 is a schematic diagram of the game server 1. As an example, the game server 1 is configured by a computer having a processor 11, a memory 12, and a communication unit 13, or by one computer and its peripheral devices. The game server 1 may also be realized by multiple computers working together.

[0036] The processor 11 is, for example, a CPU (Central Processing Unit). The memory 12 includes, for example, a ROM (Read Only Memory) and a RAM (Random Access Memory). The memory 12 stores a game program 121 and a management program 122 as programs executed by the processor 11. These programs 121 and 122 may be a single program, modules included in a single program, or different programs. The communication unit 13 is, for example, a communication module, and realizes communication with other devices via the network 7.

[0037] The memory 12 further has a user information DB 123, which is a storage area for storing user information. The user information includes identification information for each player 6 and the number of tokens held by each player 6. The memory 12 also stores information about the game for each player 6. The information about the game includes operation information. The operation information may be collected, for example, by a keylogger. A replay video (game video) is generated from the operation information of the player 6. Various methods are known for generating a replay video from operation information such as a keylog, and the generation method here is not limited to a specific method. The memory 12 may store a replay video instead of, or in addition to, the operation information.

[0038] The game server 1 includes a game providing unit 10 that functions as a game providing server. The game providing unit 10 is realized by a processor 11 executing a game program 121 to perform game processing 111. The game processing 111 is processing for providing a game to a player 6, and is not limited to any particular processing as long as it is processing for providing a general competitive game. By performing the game processing 111, the processor 11 stores player operation information in a memory 12.

[0039] The game server 1 includes a game management unit 20 that functions as a server for managing the game. The game management unit 20 is realized by the processor 11 executing a management program 122 to perform management processing 112. The management processing 112 is processing for managing the participation of players 6 in the game.

[0040] The game server 1 stores in advance the number of tokens required for each stage. The management process 112 includes determining whether or not the player 6 can participate in the battle by determining whether or not the number of battle tokens set by the player 6 for participation in the battle is equal to or greater than the number of tokens required for the stage where the battle will be held.

[0041] The management process 112 includes managing the number of tokens held by players, and, for example, includes changing the number of tokens held by players depending on the results of a match. The management process 112 includes, for each match, decreasing the number of tokens held by a losing player by the number of match tokens set by that player, and increasing the number of tokens held by a winning player by the number of match tokens set by that player.

[0042] [System processing flow] 4 is a flowchart showing an example of the processing flow in the game server 1. A game player who wants to participate in a battle applies for participation using a user terminal 5. As an example, the player connects the user terminal 5 to a specified website for the game and inputs the information required to apply for the battle.

[0043] 5 is a schematic diagram of an application screen 301 for participation in a battle. The application screen 301 has a field 62 for inputting the number of battle tokens set by the player. Preferably, the application screen 301 includes a display 61 of the current stage in which the battle for which participation is being applied will be held. More preferably, the application screen 301 includes a display 63 of the required number of tokens specified for the current stage. This allows the player to input a number in the field 62 that is equal to or greater than the required number of tokens for the stage.

[0044] Preferably, the application screen 301 includes a display 71 of the number of tokens held by the player. This allows the player to input the number of battle tokens to be set while checking the number of tokens held. More preferably, the display 71 of the number of tokens held by the player may increase or decrease depending on the number of battle tokens to be set by the player, which is input in the field 62.

[0045] The number of tokens held by a player may be automatically read by the processor 11 of the game server 1 from the user information DB 123 when the player connects the user terminal 5 to a specified website for the game and logs in. In this case, the display 71 is automatically displayed on the application screen 301. As another example, the application screen 301 may include a confirmation button 72, which may receive an instruction from the player to display the number of tokens held. In this case, when an instruction is given using the confirmation button 72 on the application screen 301, the processor 11 of the game server 1 reads the number of tokens held by the player from the user information DB 123, and displays the number of tokens held by the player on the application screen 301.

[0046] The number of battle tokens entered on application screen 301, together with the player's identification information (e.g., ID (identification)), is passed to game server 1 as a request to participate in the battle. When the number of battle tokens is set on application screen 301 (YES in step S101), processor 11 compares the set number of tokens with the number of tokens required for the current stage to determine whether or not the player can participate in the battle.

[0047] If the input number of tokens is less than the required number of tokens, processor 11 does not permit the player to participate in the match (NO in step S103). In this case, processor 11 returns to step S101 and waits for new input to application screen 301. Alternatively, processor 11 may end the processing.

[0048] Processor 11 determines to permit the player to participate in the battle if the input number of tokens is equal to or greater than the required number of tokens (YES in step S103). Processor 11 updates application screen 301 if permitting participation in the battle. Figure 6 is a schematic diagram of application screen 302 after application screen 301 has been updated.

[0049] When permitting the player to participate in the battle, processor 11 extracts, from among the other players, players who have the same number of set battle tokens as the player as potential opponents (step S105), and displays the selected players for selection on application screen 302. Application screen 302 includes options 64A, 64B, 64C, and 64D representing the extracted potential opponents, respectively, back button 65A, and enter button 65B.

[0050] The player can select an opponent from options 64A, 64B, 64C, and 64D and press the confirm button 65B to confirm the application, or press the back button 65A to return to the application screen 301 and reset the number of battle tokens. If the set number of battle tokens is less than the required number of tokens, the application screen 301 does not switch to the application screen 302, and the player cannot apply to participate in the battle. In other words, in this case, the player is not permitted to participate in the battle.

[0051] When an opponent is selected on application screen 302 and the application to participate in the battle is decided (YES in step S107), processor 11 executes game processing for causing the battle with the selected opponent (step S109). The processing in step S109 is not limited to a specific processing and may be processing for a general battle-type game. At this time, processor 11 stores operation information by the player in memory 12.

[0052] If the application is not confirmed on application screen 302 (NO in step S107), processor 11 returns to step S101 without executing the game process, and returns application screen 302 to application screen 301 to wait for new input. Alternatively, processor 11 may end the process.

[0053] After the game processing of step S109, processor 11 updates the number of tokens held by the player in accordance with the result of the match between the players (step S111). In step S111, if the player loses the match, processor 11 decreases the number of tokens held by the player by the number of match tokens set in step S101, and if the player wins, processor 11 increases the number of tokens held by the number of match tokens set in step S101. Processor 11 then returns to step S101. Alternatively, processor 11 may end processing.

[0054] [Variations] The management process 112 may include not allowing a player to set a number of battle tokens that is less than the required number of tokens. In this case, the processor 11 displays the application screen 303 of FIG. 7 instead of the application screen 301. The application screen 303 has a field 62A, an operation button 62B for increasing the number of battle tokens to be input into the field 62A, and an operation button 62C for decreasing the number of battle tokens.

[0055] When the number input into field 62A matches the number of tokens required for the current stage where the battle is to be held, processor 11 according to the modified example makes operation button 62C unselectable and allows only operation button 62B to be operated. In the example of FIG. 7, the number input into field 62A matches the required number of tokens, 2, so operation button 62C is shown to be grayed out. As a result, in order to participate in the battle, the player cannot input a number of battle tokens that is less than the required number of tokens for the stage where the battle is to be held, and can only input a number equal to or greater than the required number of tokens.

[0056] FIG. 8 is a flowchart showing a modified example of the processing flow in the game server 1. The processing in FIG. 8 differs from the processing in FIG. 4 in that it includes step S100 instead of step S103. In step S100, when the user terminal 5 accesses a specified website via the network 7, processor 11 displays application screen 303 (step S100). In step S100, processor 11 monitors the input of the number of battle tokens on application screen 303. If the input value matches the required number of tokens specified for the current stage in which the battle in which the player is applying to participate will be held, processor 11 displays operation button 62C as unselectable in step S100. This prevents the player from setting a number of battle tokens less than the required number of tokens. When the number of battle tokens is set on application screen 301 (YES in step S101), processor 11 executes the processing from step S105 onwards.

[0057] In the game system 100 according to the first embodiment or its modified example, many players have enough tokens to meet the required number of tokens in the early stages. However, as the stage changes and the battle progresses, weaker players are unable to set battle tokens in excess of the required number of tokens. As a result, overpayment of the compensation is prevented.

[0058] [Second embodiment] The token may be an NFT (Non-Fungible Token). In this case, the user terminal 5 can communicate with a wallet server (not shown) having a storage area for storing digital assets, called a wallet, via the network 7.

[0059] 9 is a schematic diagram of the configuration of a game system 100 according to the second embodiment. In the game system 100 according to the second embodiment, the game server 1 and user terminal 5 can access the blockchain 3 via a network 7. The game server 1 and user terminal 5 can also access an NFT market 8 via the network 7. The wallet server connects to the NFT market 8 and transfers digital assets. As a result, tokens can become the subject of buying and selling on a third-party market.

[0060] Blockchain 3 is composed of a network system in which multiple computers are interconnected. The multiple computers that make up Blockchain 3 store in a distributed manner the correspondence between NFT tokens and the identification information of the players who own them.

[0061] A smart contract 33 is implemented in the blockchain 3. The smart contract 33 is software (computer program) implemented in the blockchain 3, and is automatically executed according to predetermined conditions. The smart contract 33 performs processes such as recording the owner of an NFT in the blockchain 3, rewriting the owner, and updating the transaction history.

[0062] In the second embodiment, the smart contract 33 obtains the results of the player's battle from the game server 1 and rewrites the owner of the tokens in accordance with the battle result. As an example, when a player sets the number of battle tokens, the smart contract 33 temporarily rewrites the owner of the set number of tokens from the player to the operator of the game system 100. Then, in accordance with the battle result, the smart contract 33 rewrites the owner of the tokens from the operator of the game system 100 to the player who won the battle. Alternatively, the smart contract 33 may rewrite the owner of the tokens of the player who lost the battle to the player who won.

[0063] In the second embodiment, players can also use the user terminal 5 to access the NFT market 8 and buy and sell tokens. Buying and selling of tokens on the NFT market 8 may be the same as buying and selling of general NFTs. The smart contract 33 rewrites the owner of the token depending on the results of the buy and sell.

[0064] The game server 1 obtains the results of buying and selling tokens from the NFT market 8. In the second embodiment, the management process 112 includes changing the number of tokens held by the player, which is stored in the memory 12, in accordance with the results of buying and selling tokens by the player.

[0065] The game server 1 obtains information about buying and selling prices from the NFT market 8. The information about buying and selling prices may be, for example, selling prices or buying prices. In the second embodiment, the management process 112 includes extracting at least one of a predetermined range of selling prices and a predetermined range of buying prices. The predetermined range of selling prices and the predetermined range of buying prices are, for example, the current lowest selling price and the current highest buying price. As another example, the predetermined range of selling prices and the predetermined range of buying prices may be the trend in selling prices over a predetermined period and the trend in buying prices over a predetermined period.

[0066] FIG. 10 is a schematic diagram of the display screen 304 of the user terminal 5 in the second embodiment. The display screen 304 includes a game screen 67 and displays 68 and 73 related to the buying and selling prices of tokens. Display 68, for example, displays the current minimum selling price and the current maximum buying price of tokens. Display 73 may, for example, be a chart showing price fluctuations of the selling and / or buying prices of tokens over a predetermined period of time. The game management unit 20 of the game server 1 obtains information about buying and selling prices from the NFT market 8, extracts the minimum selling price and the maximum buying price, and displays them on the display screen 304. The game management unit 20 also generates a chart based on the information about buying and selling prices obtained from the NFT market 8, or obtains a chart showing price fluctuations from the NFT market 8 and displays it on the display screen 304. Preferably, the game management unit 20 obtains information about buying and selling prices from the NFT market 8 at predetermined time intervals and updates display 68 and display 73 on the display screen 304. The display screen 304 may also have a button 75 for receiving an instruction to update the display 68 or the display 73 .

[0067] Preferably, the display screen 304 includes a button 69A for instructing the purchase of tokens, and a button 69B for instructing the sale of tokens. When button 69A is pressed, the game management unit 20 passes a request for the player to purchase tokens at the bid price included in the display 68 to the NFT market 8, and when button 69B is pressed, the game management unit 20 passes a request for the player to sell tokens at the sell price included in the display 68 to the NFT market 8. This passes the player's request for the purchase and sale of tokens to the NFT market 8, and when the conditions are met, the purchase and sale of tokens on the NFT market 8 is completed.

[0068] More preferably, the display screen 304 includes a field 74A for inputting the number of tokens to be instructed to be purchased, and a field 74B for inputting the number of tokens to be instructed to be sold. When a number is input into field 74A and button 69A is pressed, the game management unit 20 passes a request to the NFT market 8 to purchase the number of tokens input into field 74A at the buy price included in display 68. When a number is input into field 74B and button 69B is pressed, the game management unit 20 passes a request to the NFT market 8 to sell the number of tokens input into field 74B at the sell price included in display 68.

[0069] More preferably, the display screen 304 includes a field 76A for entering the purchase price of tokens and a field 76B for entering the selling price of tokens. When a number is entered in field 76A and button 69A is pressed, the game management unit 20 passes a request to the NFT market 8 to purchase a specified number of tokens for the purchase price entered in field 76A. If the display screen 304 also includes field 74A, the game management unit 20 passes a request to the NFT market 8 to purchase the number of tokens entered in field 74A for the purchase price entered in field 76A. When a number is entered in field 76B and button 69B is pressed, the game management unit 20 passes a request to the NFT market 8 to sell the specified number of tokens for the selling price entered in field 76B. If the display screen 304 also includes field 74B, the game management unit 20 passes a request to the NFT market 8 to sell the number of tokens entered in field 74B for the selling price entered in field 76B.

[0070] Preferably, the display screen 304 includes a button 69C that instructs access to the NFT market 8. When the button 69C is pressed, the game management unit 20 switches the display screen 304 to a screen (not shown) of the NFT market 8. This allows players to quickly switch to the screen of the NFT market 8 even during a battle.

[0071] 11 is a flowchart showing an example of the processing flow according to the second embodiment on the game server 1. The processor 11 obtains information on the buying and selling prices of tokens from the NFT market 8 (step S201). The processor 11 extracts the minimum selling price and the maximum buying price from the information on the buying and selling prices, and displays them on the display screen 304 together with the game screen 67 (step S203).

[0072] When an instruction to buy or sell tokens is accepted on the display screen 304 (YES in step S205), the processor 11 sends a request to buy or sell tokens at the selling price or buying price displayed on the display screen 304 at the time the instruction was accepted to the NFT market 8 (step S207). In step S205, the processor 11 may further accept an instruction on the number of tokens to buy or sell, and send this to the NFT market 8 in step S207.

[0073] Thereafter, when processor 11 receives information from NFT market 8 indicating that the sale and purchase has been completed (YES in step S209), processor 11 changes the number of tokens held by the player stored in memory 12 according to the number sold and purchased, and updates it to the number after the sale and purchase (step S211).

[0074] Processor 11 returns to step S201 at predetermined intervals and repeats the series of processes. Also, if there is no instruction to buy or sell tokens on display screen 304 for a predetermined period of time (NO in step S205) or if no information on a successful sale is obtained from NFT market 8 (NO in step S209), processor 11 returns to step S201 and repeats the series of processes.

[0075] Processor 11 executes the processing of FIG. 11 in parallel with at least the game processing in step S109 of FIG. 4 or FIG. 8. When step S109 ends, processor 11 may end the processing of FIG. 11. As a result, display screen 304 is displayed at least while players are competing. By displaying game screen 67 and the buying and selling prices of tokens on the same screen, players can grasp the buying and selling prices of tokens without switching screens during a match. Furthermore, by repeating the processing of FIG. 11 at predetermined intervals, the current minimum selling price and maximum buying price of tokens are displayed on display screen 304. Furthermore, by including button 69A for instructing to buy tokens and button 69B for instructing to sell tokens on display screen 304, players can buy and sell tokens at their desired prices even during a match.

[0076] [Third embodiment] In the third embodiment, the game server 1 accepts input of information related to the player's actions via the network 7. The information related to the player's actions refers to information obtained when the player performs a specific action. The specific action is an action different from game operations and is predefined by the game system 100. The specific action is, for example, an action of the player purchasing a specific product, or an action of the player going to a specific location such as a specific store. The information related to the player's actions may be, for example, information indicating that the user terminal 5 has accessed a specific website using code information attached to a product. Furthermore, the information related to the player's actions may be, for example, information indicating that the user terminal 5 has accessed a specific website using code information installed at a specific location, or an electronic coupon received by the user terminal 5 from a device installed at a specific location.

[0077] The processor 11 of the game server 1 determines whether or not the information related to the player's actions satisfies a predetermined condition. The condition indicates that the information is obtained as a result of the player performing the above-mentioned specific action.

[0078] For example, if the specific behavior is the player purchasing a specific product, the condition may be that the user terminal 5 has accessed a predetermined site using code information attached to the product. In this case, the processor 11 determines that the information related to the player's behavior satisfies the condition by receiving information indicating that the player has accessed the predetermined site from the predetermined site.

[0079] Furthermore, for example, if the specific behavior is the player going to a specified location such as a specific store, the condition may be that the user terminal 5 accesses a predetermined site using code information installed at that location, or that the user terminal 5 receives an electronic coupon from a device installed at that location, etc. In this case, the processor 11 determines that the information related to the player's behavior satisfies the condition by receiving information indicating that the player has accessed the predetermined site from the predetermined site or by receiving the electronic coupon from the user terminal 5.

[0080] If the condition is satisfied, processor 11 increases the number of tokens held by the player, which is stored in memory 12, by a specified number. The specified number is stored in advance according to information related to the player's actions. This allows the player to increase the number of tokens held by taking a specific action other than game operations. Furthermore, game system 100 according to the third embodiment can encourage the player to take a specific action other than game operations.

[0081] Preferably, processor 11 transmits the number, timing, frequency, etc. of specific actions taken by the player to a predefined device. The predefined device is a device that desires the player to take a specific action other than game operations, such as a server of a seller of a specific product or a server of a store in a specific location. This allows the device that desires the player to take a specific action to know that the player actually took the specific action, as well as the number, timing, frequency, etc.

[0082] [Fourth embodiment] The game providing unit 10 of the game server 1 may provide a game (e.g., called a tournament mode) that requires the setting of the number of battle tokens, and a game (e.g., called a free mode) that does not require the setting of the number of battle tokens. The free mode may be used to measure the battle skills of players.

[0083] In the fourth embodiment, an application screen 305 shown in Fig. 12 is displayed instead of the application screen 301. In addition to the display 61, field 62, and display 63 of the application screen 301, the application screen 305 has a button 66 for instructing participation in a battle in free mode. This allows a player to apply to participate in a battle in free mode on the application screen 305.

[0084] The game providing unit 10 provides the same game in the free mode as in the tournament mode. Note that in this case, the game management unit 20 does not manage tokens. The game providing unit 10 judges the player's gaming skill and stores the judgment result in the memory 12 in place of or in addition to the operation information. The judgment result may be, for example, the player's score or whether or not a predetermined operation has been performed.

[0085] The processing of the game server 1 in the tournament mode in the fourth embodiment is generally the same as the processing in the first embodiment of FIG. 4, except for step S105. In the fourth embodiment, the processor 11 extracts, from among the other players, other players whose gaming skill determination results satisfy a predetermined condition as opponent candidates. Alternatively, the processor 11 may extract, from among the other players, other players whose set number of battle tokens matches the set number and whose gaming skill determination results satisfy a predetermined condition as opponent candidates. The predetermined condition may be, for example, the same as the determination result of the player's gaming skill, or may be within a predetermined range from the determination result of the player's gaming skill. This allows a player to compete against other players according to their battle skills, thereby enhancing the enjoyment of the game.

[0086] [Fifth embodiment] The game system 100 may purchase operation information for a match that starts after a specified time from the start of the game. As an example, the game system 100 purchases operation information for a match at the highest stage (the fourth stage st4 in the example of FIG. 2). The operation information may be a replay video or a key log.

[0087] In the fifth embodiment, the game management unit 20 of the game server 1 transmits operation information of a battle at the highest stage among the operation information stored in the memory 12 to a predefined purchasing server (not shown). Preferably, the game management unit 20 grants the player points or digital assets such as crypto assets equivalent to the purchasing price of the operation information.

[0088] In the game system 100, the number of players who can participate in a match decreases as time passes from the start of the game. In the example of Figure 2, the passage of time from the start of the game is shown downward, and the number of players who can participate in a match decreases in an inverted pyramid shape as time passes. This allows the game management unit 20 to narrow down the players whose operation information is to be purchased to those who are strong in matches, and to reduce the number of players whose operation information is to be purchased.

[0089] [Sixth embodiment] The game system 100A according to the sixth embodiment can be used not only for games provided by a server, but also for non-digital game formats, such as sports or rock-paper-scissors, in which players gather together using their own game consoles. In the sixth embodiment, the game server 1 only needs to include at least the game management unit 20, and the game providing unit 10 may be implemented by another device. For example, the game providing unit 10 may be implemented by a user terminal 5. FIG. 13 is a schematic diagram of the configuration of the game system 100A according to the sixth embodiment and the user terminal 5. The user terminal 5 includes a processor 51, a memory 52, an operation unit 53, and a display unit 54. The memory 52 stores a program 521, and the processor 51 executes the program 521 to perform game processing 511. In the sixth embodiment, the game processing 511 may receive input of the results of a physical battle between players, instead of providing a digital game.

[0090] In the game system 100A, the user terminal 5 has a first communication unit 55 for communicating with the game management unit 20 and the like via the network 7, and a second communication unit 56 for communicating with other user terminals 5A and the like. The user terminal 5 according to the sixth embodiment is assumed to be a portable terminal that can be carried by a player, such as a smartphone or tablet, and the second communication unit 56 performs short-range wireless communication, such as infrared communication.

[0091] The processor 51 of the user terminal 5 performs game processing 511 by executing a program 521 in accordance with an operation of the operation unit 53 by a player. The game processing 511 is processing for having players compete against each other, as in the first to fifth embodiments, and uses information about other players received from the user terminal 5A by the second communication unit 56 as opponents. In this case, the user terminal 5 communicates operation information with the other user terminal 5A that is within a distance where communication is possible via the second communication unit 56, via the second communication unit 56. The processors 51 of both user terminals 5, 5A update the game screen using the operation information, thereby realizing a battle between the respective players on both user terminals 5, 5A.

[0092] In the sixth embodiment, the game management unit 20 obtains the number of battle tokens set by the player from the user terminal 5. In the sixth embodiment, the game management unit 20 also increases the number of required tokens the later the battle starts after the start of the game. In addition, the game management unit 20 obtains the battle result from the user terminal 5 and changes the number of tokens held by the player by the number of battle tokens set by that player.

[0093] [Variation 1] As another example, the game server 1 may determine whether or not to allow player 6 to participate in a battle by determining whether the number of tokens held by the player is equal to or greater than the required number of tokens. That is, in a modified example, when processor 11 accepts the setting of the number of battle tokens on application screen 301 in step S101 of FIG. 4, instead of step S103, processor 11 compares the number of tokens held by the player stored in memory 12 with the required number of tokens for the current stage in which the battle will be held. Processor 11 allows players who hold more than the required number of tokens to participate in the battle, and does not allow players who do not hold more than the required number of tokens to participate in the battle. This restriction also prevents overpayment of fees.

[0094] [Variation 2] The game is not limited to having multiple stages that change over time as shown in FIG. 2. The game server 1 may measure the time that has elapsed from the start of the game to the start of the match, and increase the number of required tokens according to the elapsed time. As another example, the game may be one in which multiple matches are played in a predetermined order from the start of the game. In this case, the game server 1 may increase the number of required tokens the more matches that have been played from the start of the game until that match. Furthermore, the game server 1 may increase the number of required tokens the more matches a player has participated in from the start of the game until that match.

[0095] [Variation 3] The number of tokens a player receives when they win a match and the number of tokens lost when they lose may differ from the number of match tokens set by the player. The number of tokens a player receives when they win a match and the number of tokens lost when they lose may be at least a portion of the number of match tokens set by the player when participating in the match, or may be a number greater than the set number of match tokens. For example, if a player sets the number of match tokens to 5, a player who wins the match may be awarded 3 tokens, which is a partial subtraction from the set number of match tokens. Also, for example, a player who wins a match may be awarded more tokens (bonus tokens) than the set number of match tokens.

[0096] Furthermore, if the number of tokens lost by a player who loses a match and the number of tokens gained by a player who wins a match differ from the number of match tokens set by the player, the method for calculating the number of tokens lost if a player loses may be different from the method for calculating the number of tokens gained if a player wins.

[0097] <3. Notes> The present invention is not limited to the above-described embodiments, and various modifications are possible. Furthermore, two or more of the first to sixth embodiments and modifications may be combined. [Explanation of symbols]

[0098] 1: Game server, 5: User terminal, 6: Player, 11: Processor, 12: Memory (first memory, second memory), 20: Game management unit (game management server)

Claims

1. A game management server that manages participation in a game in which multiple matches are played over time by players of the game, accepting a battle fee setting from the player participating in the battle; deducting from the assets held by the player who lost the match an amount corresponding to the match fee set by the player, and adding to the assets held by the player who won the match an amount corresponding to the match fee set by the player; The required battle fee, which is the minimum value of the battle fee required for the player to participate in the battle, is increased the later the start of the battle is from the start of the game. Game management server.

2. Furthermore, if the battle fee set by the player is equal to or greater than the required battle fee, the player is permitted to participate in the battle. The game management server according to claim 1 .

3. Furthermore, the player is not permitted to set a battle fee that is less than the required battle fee. The game management server according to claim 1 .

4. Furthermore, the system is configured to extract opponent candidates for the player based on the opponent fee set by the player. The game management server according to claim 1 .

5. The battle fee is replaced by tokens, which are in-game currency. a first memory that stores the number of tokens held by the player; Furthermore, the number of tokens stored in the first memory is changed by a number corresponding to the battle fee set by the player, according to the battle result of the player. The game management server according to claim 1 .

6. The tokens are tradable by the players, and changing the number of tokens stored in the first memory according to the results of the buying and selling of the tokens.

6. The game management server according to claim 5.

7. The token is a non-fungible token recorded on the blockchain. The server for managing a game according to claim 6.

8. moreover, Accept input of information regarding the purchase and sale prices of the tokens; and extracting at least one of a predetermined range of selling prices and a predetermined range of buying prices from the input buying and selling prices, and displaying the extracted range on the user terminal of the player who is displaying the game. The server for managing a game according to claim 6.

9. moreover, accepting an input by the player of information related to an action other than an operation of the game; and if the information satisfies a predefined condition, increasing the number of tokens stored in the first memory by a predefined number.

6. The game management server according to claim 5.

10. A second memory is accessible that stores operation information of the player in the battle, moreover, and transmitting, to a purchase server, the operation information of the battle in which the player participated and which started after a specified time from the start of the game, among the operation information stored in the second memory. The game management server according to claim 1 .

11. A computer program that causes a computer to function as a game providing server that manages participation in a game in which multiple matches are played over time by players of the game, the computer program comprising: accepting a battle fee setting from the player participating in the battle; deducting from the assets held by the player who lost the match an amount corresponding to the match fee set by the player, and adding to the assets held by the player who won the match an amount corresponding to the match fee set by the player; The later the start of the match is from the start of the game, the larger the required match fee, which is the minimum value of the match fee required for the player to participate in the match. Computer program.

Images