Programs and systems

Abstract

To prevent a decline in user interest. The program causes a computer to function as a control means that performs control to restrict a user's use of a borrowed first object when a first operation by the user using the borrowed first object satisfies a first condition.

Description

[Technical Field]

[0001] The present invention relates to a program and a system. [Background technology]

[0002] In recent years, services that users can use have been used to trade objects that the users have acquired.

[0003] However, if the above-mentioned services are not used appropriately, the user's interest may decrease. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent No. 7511071 Summary of the Invention [Problem to be solved by the invention]

[0005] Therefore, an object of the present invention is to provide a program and a system that can prevent a decline in the user's interest. [Means for solving the problem]

[0006] According to one aspect of the present invention, there is provided a program that causes a computer to function as a control means that performs control to restrict a user's use of a borrowed first object when a first operation by the user using the borrowed first object satisfies a first condition. [Effects of the Invention]

[0007] The present invention makes it possible to suppress a decline in the user's interest. [Brief explanation of the drawings]

[0008] [Figure 1]1 is a diagram showing an example of the configuration of a game system according to an embodiment of the present invention. [Figure 2] FIG. 2 is a diagram showing an example of the hardware configuration of a user terminal. [Figure 3] FIG. 2 is a diagram illustrating an example of a hardware configuration of a server device. [Figure 4] FIG. 2 is a diagram showing an example of the functional configuration of a user terminal. [Figure 5] FIG. 2 is a diagram illustrating an example of the functional configuration of a server device. [Figure 6] 10 is a flowchart showing an example of a processing procedure of a game system. [Figure 7] FIG. 4 is a diagram showing an example of a home screen. [Figure 8] FIG. 10 is a diagram showing an example of a mining screen. [Figure 9] FIG. 10 is a diagram showing an example of a guidance display. [Figure 10] FIG. 10 is a diagram showing an example of a notification display. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. Fig. 1 shows an example of the configuration of a game system according to this embodiment. The game system 1 shown in Fig. 1 is configured to enable users to play games online, for example, and includes a user terminal (terminal device) 10 and a server device 20.

[0010] The user terminal 10 is, for example, an electronic device used by a user. In this embodiment, it is assumed that the user terminal 10 is, for example, a personal computer (PC), but the user terminal 10 may also be other electronic devices such as a smartphone, a tablet terminal, or a video game console.

[0011] The server device 20 is provided to enable users to play games using the user terminals 10, and is communicably connected to the user terminals 10 via a network 30 such as the Internet.

[0012] Although only one user terminal 10 is shown in FIG. 1, the game system 1 is assumed to include a plurality of user terminals 10 used by a plurality of users who can play the game.

[0013] Furthermore, in the game system 1 according to this embodiment, the user terminal 10 and the server device 20 are connected to a blockchain system 40 via a network 30 so as to be able to communicate with each other.

[0014] The blockchain system 40 includes multiple node devices (not shown), each of which has a distributed ledger. Each node device is configured to store the same data in the distributed ledger. Details will be described later, but in this embodiment, assets held by users are managed on a blockchain realized by the distributed ledger held by each node device of the blockchain system 40.

[0015] Fig. 2 shows an example of the hardware configuration of the user terminal 10 shown in Fig. 1. As shown in Fig. 2, the user terminal 10 includes a non-volatile memory 11, a CPU 12, a main memory 13, a communication device 14, an input device 15, a display device 16, and the like.

[0016] The nonvolatile memory 11 stores various programs. The various programs stored in the nonvolatile memory 11 include, for example, an operating system (OS) and various application programs that run on the user terminal 10.

[0017] The CPU 12 is a processor for controlling the operations of various components within the user terminal 10, and executes various programs stored in, for example, the non-volatile memory 11. The CPU 12 may be a single processor or may be configured with multiple processors.

[0018] The various programs stored in the non-volatile memory 11 are loaded from the non-volatile memory 11 into the main memory 13 and executed by the CPU 12, and the programs executed by the CPU 12 include a game program for operating as a user terminal in the game system 1.

[0019] The communication device 14 is a device for communicating with external devices such as the server device 20 and multiple node devices that make up the blockchain system 40.

[0020] The input device 15 is a device for inputting operations performed by the user to play the game, and includes, for example, a mouse and a keyboard.

[0021] The display device 16 is a device for displaying various screens for playing the game, and includes, for example, a liquid crystal display.

[0022] Fig. 3 shows an example of the hardware configuration of the server device 20 shown in Fig. 1. As shown in Fig. 3, the server device 20 includes a nonvolatile memory 21, a CPU 22, a main memory 23, a communication device 24, and the like.

[0023] The nonvolatile memory 21 stores various programs, including, for example, an operating system (OS) and various application programs that run on the server device 20.

[0024] The CPU 22 is a processor for controlling the operations of various components in the server device 20, and executes various programs stored in the nonvolatile memory 21, for example. The CPU 22 may be a single processor or may be configured with multiple processors.

[0025] The various programs stored in the non-volatile memory 21 are executed by the CPU 22 loaded from the non-volatile memory 21 to the main memory 23, and the programs executed by the CPU 22 include a game program for operating as a server device in the game system 1.

[0026] The communication device 24 is a device for communicating with external devices such as the user terminal 10 and multiple node devices that make up the blockchain system 40.

[0027] Although the hardware configuration of the user terminal 10 and the server device 20 has been described here, each node device constituting the above-mentioned blockchain system 40 also has a similar hardware configuration. Specifically, each node device may be provided with, for example, a non-volatile memory, a CPU, a main memory, a communication device, etc.

[0028] The following describes the functional configuration of the game system 1 according to this embodiment. The game system 1 according to this embodiment has a function that enables users to play games by, for example, the user terminal 10, the server device 20, and the blockchain system 40 operating in cooperation with each other.

[0029] 4 shows an example of the functional configuration of the user terminal 10. As shown in FIG. 4, the user terminal 10 includes an operation receiving unit 101, a transmitting / receiving unit 102, a control unit 103, a display processing unit 104, and a storage unit 105.

[0030] 4 are functional units realized by software, that is, by the CPU 12 of the user terminal 10 executing the game program described above. This game program may be downloaded to the user terminal 10 via the network 30, or may be distributed by being stored in advance on a computer-readable storage medium. The CPU 12 is an example of a computer of the user terminal 10 that executes the game program.

[0031] 4 is realized by the nonvolatile memory 11 shown in FIG. 2 or another storage device (not shown).

[0032] The operation reception unit 101 receives operations input by the user using the input device 15 when playing a game. Hereinafter, for convenience, the operations received by the operation reception unit 101 will be referred to as user operations. User operations include, for example, clicking a mouse or pressing a key on a keyboard.

[0033] The transmitting / receiving unit 102 transmits or receives various types of information related to the game via the communication device 14. The various types of information include play information, game information, user information, etc. The play information includes information indicating the user's operations, etc.

[0034] The control unit 103 executes various processes related to the progress of the game based on, for example, user operations.

[0035] The display processing unit 104 executes processing to display various screens for playing the game in accordance with the control of the control unit 103.

[0036] The storage unit 105 stores, for example, game information and user information. The game information and user information are information that is referenced when a game program is executed on the user terminal 10.

[0037] In the game system 1, an account is issued for each user who plays the game, and the game information is information common to all of the accounts. The game information includes, for example, information for defining a virtual space corresponding to the game space. The game information also includes, for example, information regarding the positions and setting values ​​of various objects, such as characters, buildings, trees, stones, and items, that are placed in the virtual space (hereinafter referred to as object setting information). Note that the characters can be controlled by the user, and will be referred to as player characters in the following description.

[0038] User information is information managed for each user account, and the storage unit 105 stores user information about users who use the user terminal 10. The user information includes, for example, information about the player character, information about owned assets, and information indicating the progress of the game. Owned assets correspond to assets acquired by the user by playing the game. Examples of assets include electronic currency, tokens, items, and characters. Electronic currency includes, for example, virtual currency (in other words, crypto assets) and currency that can be used in the game.

[0039] 5 shows an example of the functional configuration of the server device 20. As shown in FIG. 5, the server device 20 includes a storage unit 201, a transmission / reception unit 202, a control unit 203, and a management unit 204.

[0040] The storage unit 201 shown in FIG. 5 is realized by the nonvolatile memory 21 shown in FIG. 3 or another storage device (not shown).

[0041] 5 are functional units realized by software, that is, by the CPU 22 of the server device 20 executing the game program. This game program may be downloaded to the server device 20 via the network 30, or may be distributed by being stored in advance in a computer-readable storage medium. The CPU 22 is an example of a computer of the server device 20 that executes the game program.

[0042] The storage unit 201 stores game information similar to the game information stored in the storage unit 105 included in the above-described user terminal 10. The storage unit 201 also stores user information of all users who have been issued accounts by registering with the game system 1.

[0043] The transmitting / receiving unit 202 transmits or receives various types of information related to the game via the above-mentioned communication device 24. The various types of information include the above-mentioned play information, game information, and user information.

[0044] The control unit 203 executes various processes for providing a game play environment for playing a game (for example, enabling a user to play a game). Specifically, the control unit 203 provides a virtual space to the user playing the game based on information for defining the virtual space included in the game information. The control unit 203 places objects in the virtual space based on object setting information included in the game information. The control unit 203 controls the objects placed in the virtual space.

[0045] The management unit 204 manages the game information and user information stored in the storage unit 201. Specifically, the management unit 204 executes processes such as adding, updating, and deleting game information and user information. In addition, the management unit 204 manages assets held by users on the blockchain by linking with the blockchain system 40.

[0046] It should be noted that "provision of a game play environment" in this embodiment is realized by a game program that runs on the game system 1. The game programs that run on the game system 1 include, for example, a game program that runs on the user terminal 10 and a game program that runs on the server device 20, and the game program according to this embodiment may be a part of these game programs.

[0047] Here, we have explained the functional configurations of the user terminal 10 and the server device 20. Below, we will briefly explain the functional configurations of the node devices that make up the blockchain system 40. Note that the server device 20 may operate as part of multiple node devices that make up the blockchain system 40.

[0048] The node device registers the assets held by the user in the distributed ledger based on information about the assets held by the user transmitted from the user terminal 10 or the server device 20. In addition, the node device registers the transaction history of the assets held by the user in the distributed ledger based on information about the transactions of the assets held by the user transmitted from the user terminal 10 or the server device 20.

[0049] In addition, a distributed ledger manages multiple blocks containing hash values ​​and transactions. A hash value is calculated from information contained in the previous block, and the distributed ledger registers assets held and transaction histories, etc., with each block linked like a chain by the hash value. A transaction is, for example, information indicating the details of a transaction of assets held, and includes input information indicating the transfer source and output information indicating the transfer destination in the transaction.

[0050] The blockchain system 40 stores information in units called blocks in a distributed ledger and manages these blocks in this way, thereby realizing a blockchain with high tamper resistance and making it possible to manage the above-mentioned assets held and the transaction history of those assets on the blockchain. In this case, the user terminal 10 or the server device 20 will hold their own asset information based on the contents of the distributed ledger of the blockchain system 40.

[0051] In the game system 1 according to this embodiment, for example, at least some of the functions of the user terminal 10 may be provided by the server device 20 or the blockchain system 40, or at least some of the functions of the server device 20 may be provided by the user terminal 10 or the blockchain system 40. Furthermore, the game system 1 may include devices other than the user terminal 10, the server device 20, and the blockchain system 40. That is, the game program according to this embodiment may be executed by the user terminal 10, the server device 20, the blockchain system 40, or other devices.

[0052] Here, an overview of a game that can be played by a user in this embodiment will be described. Note that the game in this embodiment is, for example, a game that uses a blockchain system 40 (hereinafter referred to as a blockchain game).

[0053] In this embodiment, the virtual space includes, for example, a space such as a mine, and the blockchain game is a game in which a user's player character mines in the mine. In such a blockchain game, for example, items acquired by a user by mining in the mine (in other words, items mined by the user in the mine) are managed on the blockchain as the user's assets, and the assets can be traded with other users.

[0054] In the above-mentioned blockchain game, a map is prepared that is common to multiple users (specifically, all users) who play the blockchain game. Multiple mines are arranged on the map.

[0055] When a map is displayed on the user terminal 10 based on a user's operation, the user acquires or selects a mine on the displayed map where the user will mine. In this embodiment, "acquiring a mine" can be rephrased as "acquiring the right to mine in a specific mine." However, a user may be able to mine in a mine acquired by another user without acquiring the mine.

[0056] Incidentally, in a blockchain game, item A used for mining in a mine is provided as an item necessary to play the game. In other words, in order to perform mining, a user needs to use item A. Item A is, for example, a pickaxe used for mining. A pickaxe may also be called an ice axe. Note that a user who does not own a pickaxe may not be able to acquire a mine.

[0057] Here, in a blockchain game, multiple types of pickaxes with different characteristics are available. Furthermore, pickaxes are items that can be converted into NFTs (Non-Fungible Tokens). "Pickaxes converted into NFTs" refers to a state in which information proving that the pickaxe is unique is managed on a blockchain. In other words, "pickaxes converted into NFTs" refers to a state in which an NFT corresponding to the pickaxe is issued and the issued NFT is managed on a blockchain. In the following explanation, digital assets such as items for which a corresponding NFT has been issued may be simply referred to as NFTs.

[0058] In this embodiment, the pickaxe is converted into an NFT by, for example, the operator of the blockchain game, and cannot be converted by the user. However, the pickaxe may also be converted into an NFT by the user.

[0059] Furthermore, in the blockchain game of this embodiment, users can obtain items B and C through mining. Details will be described later, but for example, item B is an item that can be converted into an NFT, and item C is an item that can be exchanged for a specific token. In the following description, the token exchanged for item C is referred to as a specific token.

[0060] There are multiple types of Item B, which are collectible items. Specifically, Item B is a gemstone that users collect. On the other hand, Item C is a mineral (hereafter referred to as pyroxene) that is different from gemstones. In other words, the blockchain game has the gameplay of mining in a mine using a pickaxe to obtain gemstones and pyroxene.

[0061] Additionally, specific tokens that can be acquired by exchanging gemstones are equivalent to crypto assets (e.g., virtual currency). In the blockchain game, specific tokens are used to restore the durability of pickaxes, strengthen pickaxes, and turn gemstones into NFTs, as described below.

[0062] Regardless of whether they have been converted into NFTs or not, assets such as pickaxes, gems, and gemstones owned by each user may be managed on the blockchain.

[0063] Below, we will briefly explain the flow of asset acquisition and consumption in the blockchain game in this embodiment.

[0064] As described above, in order to mine in a blockchain game, a user needs to use a pickaxe. In this embodiment, a user can purchase a pickaxe by consuming specific tokens in a marketplace inside or outside the blockchain game.

[0065] A user who has purchased a pickaxe as described above can use the pickaxe to mine in a mine. Through mining, a user can obtain a variety of items, including gems and pyroxene.

[0066] Gems acquired by users can be converted into NFTs by meeting certain conditions. That is, in this embodiment, an NFT corresponding to the gem is issued, and the issued NFT is managed on the blockchain. The conversion of gems into NFTs may be performed automatically or based on instructions from the user. Note that conversion of gems into NFTs requires, for example, the consumption of a certain amount of specific tokens.

[0067] Furthermore, by converting gems into NFTs, they can be taken outside of the blockchain game and traded (e.g., bought and sold) in a marketplace outside of the blockchain game. In other words, converting an item such as a gem into an NFT makes it possible to take the item outside of the blockchain game. Note that gems may be traded in a designated marketplace regardless of whether they are converted into an NFT.

[0068] Pyroxene acquired by a user can be exchanged for a specific token as described above. The exchange between the pyroxene and the specific token is assumed to be performed automatically. Specifically, all pyroxene held by a user may be exchanged for a specific token at a predetermined time, or may be exchanged for a specific token when mining is completed, etc. Furthermore, the exchange between the pyroxene and the specific token may be performed based on a user's instruction.

[0069] In this embodiment, it is assumed that pyroxene obtained by mining in a mine is exchanged for a specific token, but the specific token may also be obtained directly by the mining.

[0070] Also, although the description here assumes that pyroxene can be exchanged for a specific token, gems may also be exchangeable for a specific token. In other words, gems may be items that can be converted into NFTs and can be exchanged for a specific token. The exchange between gems and specific tokens may be performed either before or after conversion into NFTs, or may be performed both before and after conversion into NFTs.

[0071] The specific token in this embodiment corresponds to a virtual currency managed on a blockchain. The specific token may be a token that can be exchanged for other crypto assets at a predetermined exchange. The specific token may also be a unique token related to a blockchain game with an issuance limit set, or may be a virtual currency that can be used outside the blockchain game.

[0072] An example of a processing procedure of the game system 1 according to this embodiment will be described below with reference to the flowchart of FIG.

[0073] In this embodiment, it has been described that a user needs to use a pickaxe to perform mining, but the pickaxe used by the user may be a pickaxe owned by the user or a pickaxe owned by another user. In other words, for example, a user who owns a pickaxe can use the pickaxe to perform mining, or can lend the pickaxe to another user and request that the other user perform mining. On the other hand, for example, a user who does not own a pickaxe can temporarily borrow a pickaxe from another user to perform mining without purchasing the pickaxe.

[0074] In this embodiment, a user who owns a pickaxe and can lend the pickaxe to other users is called an owner. On the other hand, a user who borrows a pickaxe from an owner to mine is called a scalar. When a scalar borrows a pickaxe from an owner to mine, the scalar will mine in the mine that the owner has acquired.

[0075] First, for example, when a game program is launched on the user terminal 10 to start a blockchain game, a home screen is displayed on the user terminal 10 (step S1).

[0076] Here, an example of a home screen is shown in Fig. 7. As shown in Fig. 7, a home screen 110 has a plurality of buttons 110a to 110i arranged thereon.

[0077] The button 110a is a button that can display a screen (for example, the map described above) for acquiring and managing a mine.

[0078] Button 110b is a button that can display a screen for checking the gems that the user has acquired by mining (in other words, the gems that the user has acquired in the blockchain game).

[0079] In this embodiment, a pickaxe used for mining has a durability value assigned to it, and this durability value decreases as the pickaxe is used for mining. When the durability value reaches a predetermined value (e.g., 0), the pickaxe becomes unusable. Furthermore, a level or rank is assigned to the pickaxe. Increasing the level or rank of such a pickaxe and strengthening it changes parameters that affect the ease of mining, for example, gems and pyroxene, and increases the efficiency of the mining. Button 110c is a button that can display a screen for restoring the durability value of the pickaxe or strengthening the pickaxe. Note that the durability value of the pickaxe can be restored or strengthened by consuming, for example, a predetermined amount of specific tokens.

[0080] The button 110d is a button that can display a screen for recruiting scalars to request mining, for example, when the user is the owner.

[0081] Button 110e is a button that can display a screen for buying and selling gems in a predetermined marketplace.

[0082] Button 110f is a button that can display a screen for buying and selling pickaxes in a predetermined marketplace.

[0083] Button 110g is a button that can display a screen for searching information about gems mined within the blockchain game.

[0084] Button 110h is a button that can display a screen for managing assets such as specific tokens and NFTs.

[0085] When any of the above-mentioned buttons 110a to 110h is pressed, the home screen 110 transitions to a screen corresponding to the button, but the button 110i is provided for returning to the home screen 110 from the screen corresponding to the button.

[0086] Incidentally, the home screen 110 further includes a first mining start button 111 and a second mining start button 112 for instructing the start of mining.

[0087] The first mining start button 111 is a button for the user to perform mining as an owner. When the operation of pressing the first mining start button 111 is performed, the user starts mining using a pickaxe that the user owns. Note that since the first mining start button 111 is a button for performing mining as an owner, it may be configured so that it cannot be pressed if the user does not own a pickaxe, for example.

[0088] The second mining start button 112 is a button for the user to perform mining as a scalar. When the operation of pressing the second mining start button 112 is performed, the user borrows a pickaxe owned by another user, who is the owner, and starts mining.

[0089] Note that, although the home screen has been described here with reference to Fig. 7, the home screen 110 shown in Fig. 7 is an example, and the home screen in this embodiment may be different from Fig. 7. Specifically, the home screen in this embodiment may be one in which at least some of the buttons 110a to 110i, 111, and 112 are omitted, or may be one in which buttons other than the buttons 110a to 110i, 111, and 112 are further arranged.

[0090] Returning to Figure 6 again, when the first mining start button 111 or the second mining start button 112 located on the above-mentioned home screen 110 is pressed, the mining screen is displayed on the user terminal 10 (step S2).

[0091] FIG. 8 shows an example of a mining screen. As shown in FIG. 8, a mine 121 corresponding to a virtual space is displayed on the mining screen 120. A user's player character 122 is placed in the mine 121 displayed on the mining screen 120. The user can operate the player character 122 while referring to the mining screen 120, and the player character 122 moves through the mine 121 based on the user's operation, and operates to excavate the surface of the mine 121 using a pickaxe. The processing of step S2 described above includes processing to control the behavior of the player character 122 so as to perform mining in the mine 121 displayed on the mining screen 120.

[0092] In this embodiment, it is assumed that a user plays the blockchain game as the above-mentioned scalar. In this case, the scalar can mine using the pickaxe owned by the owner as described above.

[0093] Mining in a blockchain game is carried out, for example, by excavating the surface of a mine to extract ore containing gems or pyroxene, and then further excavating the ore to extract the gems or pyroxene from the ore. When a scalar mines a gem or pyroxene, a portion of the mined gem or pyroxene is distributed to the owner, and the scalar can obtain the remaining portion of the gem or pyroxene as a reward.

[0094] On the other hand, as mentioned above, a pickaxe has a durability value that decreases each time the pickaxe is used to dig the ground, and when the durability value reaches a certain value, the pickaxe becomes unusable. When the pickaxe becomes unusable due to the durability value reaching the certain value, the owner can recover the durability value of the pickaxe by consuming a specific token.

[0095] In other words, by lending their pickaxe to a scalar, the owner has the advantage of being able to acquire gems or pyroxene without having to mine them themselves, but if the scalar does not mine efficiently, not only will they be unable to acquire gems or pyroxene, but they may also be forced to consume specific tokens to restore the durability of their pickaxe. If such a situation occurs, there is a concern that users' interest and motivation in playing the blockchain game as owners will decrease.

[0096] Therefore, in this embodiment, in order to prevent a decline in user interest, a mechanism is provided to prevent the inefficient mining of scalars described above.

[0097] 6, when a scalar mines using a pickaxe borrowed from the owner, it is determined whether the scalar's operation of using the pickaxe (hereinafter referred to as an excavation operation) satisfies a predetermined condition (hereinafter referred to as a guidance condition) (step S3). The excavation operation corresponds to an operation for controlling the player character to excavate the ground surface using the pickaxe (specifically, hitting the ground surface with the pickaxe), and may be, for example, an operation of clicking a mouse once.

[0098] Here, the guidance condition in this embodiment corresponds to, for example, a condition related to the use of a pickaxe. In other words, the guidance condition is a condition that indicates that the scalar is not using the pickaxe appropriately or is not mining efficiently.

[0099] The guidance conditions in this embodiment will be specifically described below. First, as described above, mining in a blockchain game requires excavating the surface of the mine, and in this blockchain game, multiple types of surfaces with different hardness are prepared. The number of times a pickaxe is used to excavate the surface varies depending on the hardness. Specifically, for example, a surface with low hardness can be excavated by using a pickaxe once, but a surface with high hardness cannot be excavated unless the pickaxe is used multiple times.

[0100] In order to mine efficiently in blockchain games, it is necessary to start digging from a relatively soft surface, and continuing to use a pickaxe on a hard surface cannot be considered efficient mining.

[0101] In this case, the above-mentioned guidance condition includes that the number of times that digging operations have been performed on a ground surface having a hardness equal to or greater than a predetermined value exceeds a predetermined value. The number of times that digging operations have been performed corresponds to the number of times that a pickaxe has been used.

[0102] In addition, tools for efficient mining (hereinafter referred to as mining tools) are provided in blockchain games. Mining tools include, for example, detectors that can detect and report ores (i.e., gems or pyroxenes) in the vicinity of the player character. In order to perform efficient mining, it is necessary to search for ores using such detectors.

[0103] For this reason, the count of the number of times an excavation operation has been performed to determine whether the above-mentioned guidance conditions are met (hereinafter referred to as the count of excavation operations) is assumed to start, for example, from the timing when the detector was last used. The count of excavation operations may also start, for example, from the timing when ore was last mined. In this case, the count of excavation operations is reset when the detector is used or when ore is mined. Note that "ore is mined" may mean that ore is exposed by excavating the earth's surface, or may mean that gemstones or pyroxenes are extracted from the ore.

[0104] Whether or not the scalar's excavation operation (in other words, the play situation related to the scalar's mining) satisfies the guidance conditions is determined based on game information including information for defining a virtual space in which various earth surfaces are arranged, play information including information indicating the position of the scalar's player character and the operation of the scalar, etc.

[0105] In addition, if multiple types of ground surfaces are prepared as described above, the ground surface having a hardness equal to or greater than a predetermined value may be the single ground surface with the highest hardness, or multiple ground surfaces with the highest hardness, or a ground surface that cannot be excavated without performing at least two excavation operations.

[0106] Furthermore, the excavation operation on the ground surface having a hardness equal to or greater than a predetermined value may be performed continuously or intermittently. That is, it may be determined that the guidance condition is satisfied when the number of excavation operations performed on the ground surface having a hardness equal to or greater than a predetermined value exceeds a predetermined value in succession, or it may be determined that the guidance condition is satisfied when the total number of excavation operations performed on the ground surface having a hardness equal to or greater than the predetermined value exceeds a predetermined value, even if an excavation operation on the ground surface having a hardness less than the predetermined value is performed in between.

[0107] If it is determined that the digging operation of the scalar satisfies the guidance condition (YES in step S3), guidance regarding the digging operation of the scalar is output to the user terminal 10 used by the scalar (step S4).

[0108] The guidance output in step S4 is displayed on the mining screen in the form of a dialog, as shown in Figure 9. In the example shown in Figure 9, a guidance message such as "Mining efficiency is declining. Dig from the soft surface until the detector responds. After the detector responds, use the detector frequently to search for ore. If no improvement is seen, the scalar contract will be automatically terminated" is displayed. The guidance message may be, for example, a message equivalent to a warning or notification. The scalar contract corresponds to a pickaxe lending relationship between the owner and the scalar.

[0109] Although omitted in FIG. 6, once the processing of step S4 is executed, the scalar can resume mining.

[0110] As described above, when the scalar performs mining again after the processing of step S4 is executed, it is determined whether the excavation operation of the scalar satisfies a predetermined condition (hereinafter referred to as the release condition) (step S5).

[0111] In this embodiment, the release conditions are the same as the guidance conditions described above. However, the count of the excavation operations described above starts from the timing when the guidance is output in step S4 described above. However, when the detector is used or when ore is mined as described above, the count of the excavation operations is reset. Whether the excavation operation of the scalar (in other words, the play situation related to the mining of the scalar) satisfies the release conditions is determined based on the game information, play information, etc. described above.

[0112] In this embodiment, the guidance condition and the cancellation condition are described as being the same condition, but the guidance condition and the cancellation condition may be at least partially different. Specifically, the predetermined values ​​in the guidance condition and the cancellation condition may be different values.

[0113] If it is determined that the scalar's excavation operation satisfies the cancellation condition (YES in step S5), the above-mentioned scalar contract is cancelled (step S6). "The scalar contract is cancelled" means that the scalar's ability to use the owner's pickaxe based on the pickaxe lending relationship between the owner and the scalar is cancelled, and the scalar loses the right to use the owner's pickaxe.

[0114] When the processing of step S6 is executed, the user terminal 10 used by the scalar is notified that the scalar contract has been terminated in step S6. This notification is displayed on the mining screen in the form of a dialogue, for example, as shown in FIG. 10. In the example shown in FIG. 10, a notification message such as "Since no improvement in mining efficiency has been observed, the scalar contract has been automatically terminated. You will be leaving the mine" is displayed.

[0115] When the above-mentioned notification message is displayed, the scalar mining is forcibly ended (the scalar player character automatically leaves the mine), and the process returns to step S1 and is repeated.

[0116] If it is determined in step S3 that the digging operation of the scalar does not satisfy the guidance conditions (NO in step S3), the process of step S3 is repeatedly executed while mining by the scalar is being performed. In step S3, it is determined that the guidance conditions are not satisfied, for example, when a detector is used or when ore is mined, as described above, and the count of the digging operation is reset.

[0117] Similarly, if it is determined in step S5 that the scalar's excavation operation does not satisfy the release condition (NO in step S5), the process returns to step S5 and is repeated, allowing the scalar to continue mining. Note that in step S5, as described above, if a detector is used or ore is excavated, it is determined that the release condition is not satisfied, and the count of the excavation operation described above is reset.

[0118] Here, it has been explained that if a detector is used or ore is mined, it is determined that the release condition is not met, and the process returns to step S5 and is repeated, but different processes may be executed when, for example, a detector is used and when ore is mined.

[0119] Specifically, for example, when a detector is used (i.e., an operation using a detector is performed), the above-mentioned count of excavation operations is reset, and the process returns to step S5 and is repeated. In other words, when a detector is used, the count of excavation operations is reset within the scope of the cancellation conditions, and then, if the excavation operation of the scalar satisfies the cancellation conditions, the scalar contract is cancelled.

[0120] On the other hand, for example, when ore is mined, the count of excavation operations may be reset, and the process may be repeated by returning to step S3. In other words, when ore is mined, everything may be reset, and the process may be repeated from the determination process of whether or not the guidance conditions for outputting guidance are met.

[0121] 6 may be executed in the game system 1, and the processes of steps S1 to S6 shown in FIG. 6 may be executed in, for example, the user terminal 10 or in the server device 20. Specifically, for example, the processes of steps S1, S2, and S4 may be executed in the user terminal 10, but some or all of the processes may be executed in the server device 20. Similarly, for example, the processes of steps S2, S4, and S6 may be executed in the server device 20, but some or all of the processes may be executed in the user terminal 10.

[0122] 6, the processing of steps S3 and S4 is described as being executed, but this embodiment may be configured to cancel the scalar contract at least when the scalar's excavation operation satisfies the cancellation condition. Therefore, the processing of steps S3 and S4 shown in FIG. 6 may be omitted.

[0123] Furthermore, in this embodiment, if a scalar contract is terminated, restrictions may be imposed on scalar mining that occurs after the scalar contract is terminated.

[0124] Specifically, when a scalar contract is terminated, the scalar may be prevented from mining in the mine where mining was conducted based on the scalar contract for a specified period of time after the termination of the scalar contract, or the scalar may be prevented from mining in all mines acquired by the owner under the scalar contract.

[0125] Furthermore, if a scalar contract is terminated, the scalar may be prevented from re-borrowing the pickaxe that was borrowed under that scalar contract to conduct mining, or the scalar may be prevented from borrowing any pickaxes owned by the owner under that scalar contract.

[0126] Furthermore, if a scalar contract is terminated, the scalar may be prevented from mining in mines acquired by other owners in addition to the mines acquired by the owner under the scalar contract.

[0127] Furthermore, in this embodiment, the scalar contract is described as being terminated, but instead of terminating the scalar contract, a process may be executed to impose a penalty on the user, such as slowing down the mining speed.

[0128] As described above, in this embodiment, if the scalar's excavation operation satisfies the cancellation condition, the scalar contract is cancelled. In this case, the pickaxe rented by the scalar is owned by an owner who is a user other than the scalar, and the cancellation condition is, for example, a condition regarding the use of the pickaxe.

[0129] Note that a scalar corresponds to a user who does not own a pickaxe. A pickaxe is an example of a first object. A scalar's digging operation is an example of a first operation. A cancellation condition is an example of a first condition. Cancellation of a scalar contract corresponds to canceling the state in which the scalar can use a pickaxe, and means that the scalar is put into a state in which he or she cannot use a pickaxe. However, cancellation of a scalar contract is an example of control that restricts a user's use of a first object, and such control may include processing that imposes a penalty on the user regarding mining.

[0130] In this embodiment, this configuration prevents inefficient mining of scalars and avoids disadvantages to owners. This prevents a decline in the interest of users, who are equivalent to owners, in the blockchain game. Furthermore, this embodiment can also prevent fraudulent activities, such as mechanical mining using fraudulent programs such as bots.

[0131] In addition, in this embodiment, guidance regarding scalar excavation operations is output when guidance conditions that are the same as or at least partially different from the cancellation conditions are met, and the scalar contract is terminated when the cancellation conditions are met after the guidance is output. With this configuration, for example, a user such as a beginner who does not know how to efficiently mine in a blockchain game can be given hints on how to properly mine (i.e., perform excavation operations), thereby preventing the user's scalar contract from being suddenly terminated. Note that the guidance in this embodiment may be, for example, a warning or notification to a user who borrows and uses a pickaxe owned by the owner for the purpose of causing harm to the owner.

[0132] In this embodiment, the release condition includes the number of times the scalar has performed excavation operations on a surface whose hardness is equal to or greater than a predetermined value exceeding a predetermined value. A surface whose hardness is equal to or greater than a predetermined value is an example of a second object that is different from the first object. This release condition can prevent the scalar from repeatedly using a pickaxe on a hard surface, which is inefficient mining.

[0133] Furthermore, when determining whether the scalar's excavation operation satisfies the release condition, the number of times the scalar has performed an excavation operation on a surface whose hardness is equal to or greater than a predetermined value is counted, but the count of excavation operations is reset when, for example, an operation using a detector provided as a mining tool is performed. This configuration makes it possible to avoid a situation in which the scalar contract is automatically released even when the scalar is performing efficient mining using a detector. Note that an operation using a detector is an example of an operation to search for a third object (e.g., ore) without using a first object (e.g., a pickaxe). Furthermore, an operation to search for a third object without using a first object is an example of a second operation that is different from the first operation.

[0134] In this embodiment, the scalar contract is terminated when the scalar's excavation operation satisfies the termination condition, so this embodiment can be said to be configured to impose restrictions on the scalar's excavation operation when the scalar uses a pickaxe borrowed from the owner in a mine, for example. Note that, from the perspective of avoiding the owner's disadvantage caused by the scalar's inefficient mining, such restrictions are not imposed on the owner's excavation operation (i.e., the owner's own operation using a pickaxe).

[0135] In this embodiment, guidance is output when the scalar's excavation operation satisfies the guidance conditions, and the scalar contract is terminated when the scalar's excavation operation satisfies the termination conditions, but at least one of the function that outputs the guidance (hereinafter referred to as the guidance function) and the function that terminates the scalar contract (hereinafter referred to as the termination function) may be switched between enabled and disabled, for example, according to the owner's instructions.

[0136] Furthermore, at least one of the guidance function and the cancellation function may be automatically switched between enabled and disabled based on, for example, the scalar's play information. Specifically, for example, for a scalar whose mining rate calculated based on the play information is less than a predetermined value, at least one of the guidance function and the cancellation function may be enabled, and for a scalar whose mining rate is equal to or greater than the predetermined value, at least one of the guidance function and the cancellation function may be disabled. Note that, assuming that the play information includes the number of times the scalar has mined in a mine (hereinafter referred to as the first number of times) and the number of times the scalar has mined gems or pyroxene in the mine (hereinafter referred to as the second number of times), the mining rate may be calculated by, for example, the second number of times / the first number of times, but may also be calculated by other methods.

[0137] Furthermore, at least one of the guide function and the cancellation function may be disabled for a scalar who has a predetermined relationship with the owner, such as a scalar who has entered a scalar ID made public by the owner, specifically a scalar who is an acquaintance of the owner.

[0138] The guidance conditions and cancellation conditions described in this embodiment are merely examples, and other guidance conditions and cancellation conditions may be prepared in this embodiment. Other examples of guidance conditions and cancellation conditions will be described below.

[0139] A mine where mining is performed in a blockchain game is assumed to have a level as a parameter of the mine. The mine's level increases, for example, as mining is performed in the mine, and the higher the mine's level, the more efficient the mining performed in the mine. Specifically, as the mine's level increases, the number of times a pickaxe is used to excavate the mine's surface decreases, making it easier to excavate the mine's surface. Furthermore, as the mine's level increases, the performance of the detector used in the mine may also improve.

[0140] In this case, different guidance conditions may be prepared according to the level of the mine. Specifically, whether or not the above guidance conditions are met is described as being determined based on the number of excavation operations, the count of which begins from the timing when the detector was last used or when ore was last mined. However, if the mine level is below a predetermined value, the count of the excavation operations may begin, for example, from the timing when the detector last reacted or when ore was last mined. In other words, if the mine level is below a predetermined value, the count of the excavation operations may be reset, for example, when the detector last reacts or when ore is last mined.

[0141] On the other hand, if the mine level is equal to or greater than a predetermined value, the count of excavation operations is reset, for example, when the detector is last used or when ore is last mined. In other words, if the mine level is equal to or greater than a predetermined value, the count of excavation operations is reset, for example, when the detector is last used or when ore is last mined.

[0142] Note that "the detector reacted" refers to a state in which the detector notifies the player character that ore is present near the player character by using the detector, whereas "the detector was used" simply means that the detector was used, regardless of whether or not the detector notified the player character that ore is present near the player character.

[0143] Here, we have described an example in which the timing at which the counting of excavation operations is started or reset differs depending on the level of the mine, but for example, the predetermined value corresponding to the hardness of the ground surface at which excavation operations are counted may differ depending on the level of the mine, or the predetermined value corresponding to the number of excavation operations performed that are determined to satisfy the guidance conditions may differ depending on the level of the mine.

[0144] Here, the guidance conditions have been described, but the cancellation conditions may be the same as the guidance conditions, or may be at least partially different from the guidance conditions.

[0145] According to these guidance conditions and cancellation conditions, since the number of excavation operations tends to increase when the mine level is low, it is possible to encourage the scholar to play in a way that mines ore as reliably as possible. Furthermore, according to these guidance conditions and cancellation conditions, it is possible to relax the conditions when the mine level is high, based on the viewpoint that mining is relatively easy, thereby increasing the degree of freedom in mining.

[0146] Furthermore, while the above-described detector can detect whether or not ore is present near the player character, excavating a surface area with a hardness of a predetermined value or greater when no ore is present nearby is not considered efficient mining. Therefore, at least one of the guidance condition and the release condition may be, for example, a predetermined number of consecutive excavation operations on a surface area with a hardness of a predetermined value or greater at a location far enough from the ore that the detector will not react to the excavator. Alternatively, at least one of the guidance condition and the release condition may be, for example, a predetermined number of consecutive excavation operations on a surface area with a hardness of a predetermined value or greater at a location far enough from the ore that the detector will not react to the excavator. Note that the "number of times a surface area with a hardness of a predetermined value or greater has been excavated" does not refer to the number of excavation operations performed, but rather refers to the number of times the surface area has been destroyed by multiple excavation operations. Furthermore, a "location far enough from the ore that the detector will not react to the excavator" is an example of a location that is a predetermined distance or greater from the third object.

[0147] Furthermore, the durability of a pickaxe decreases each time an excavation operation is performed (i.e., each time the pickaxe is used), and if the durability of the pickaxe is low, more efficient excavation is required. From this perspective, at least one of the guidance condition and the cancellation condition may be, for example, when the durability of the pickaxe is below a predetermined value, and the number of times an excavation operation has been performed on a surface whose hardness is equal to or greater than a predetermined value exceeds a predetermined value. Note that "when the durability of the pickaxe is below a predetermined value" is an example of a state in which the parameter value of the first object is within a predetermined range.

[0148] Furthermore, at least one of the guidance condition and the cancellation condition may be, for example, that the pickaxe's durability has decreased by about 10% of its maximum durability, but the excavation amount is below a predetermined value without using a detector or mining ore. Note that the excavation amount is the amount of the ground excavated, and can be calculated from play information, for example.

[0149] Furthermore, at least one of the guidance conditions and the cancellation conditions may change depending on the play environment of the blockchain game. The play environment may include, for example, the level of the user (e.g., the owner or scholar), the type of pickaxe, the level or durability, and the level of the mine. The user's level, the type of pickaxe, the level or durability, and the level of the mine are examples of parameters set in the virtual space in which the first object is used based on the user, the first object, and the first operation. In this embodiment, if it is determined based on such a play environment that the scholar can, for example, efficiently mine in the blockchain game, at least one of the guidance conditions and the cancellation conditions may be relaxed. On the other hand, if it is determined based on such a play environment that the scholar cannot, for example, efficiently mine in the blockchain game, at least one of the guidance conditions and the cancellation conditions may be strengthened or tightened.

[0150] Furthermore, from the viewpoint of preventing fraudulent activities such as mechanical digging using fraudulent programs such as bots, as described above, at least one of the guidance condition and the release condition may be that no specific operations that would be performed by a human have been performed.

[0151] In this case, for example, if the excavation operation is being performed continuously in a straight line regardless of the shape of the mine, it may be determined that the operation is not a human operation. In other words, at least one of the guidance condition and the cancellation condition may be that the excavation operation is being performed in a predetermined pattern that is assumed to be performed mechanically.

[0152] Furthermore, in some blockchain games, a function for sending and receiving messages between users (specifically, chatting) is provided. In this case, at least one of the notification condition and the cancellation condition may be that, despite receiving and displaying a message sent from another user, a digging operation is performed without responding to the message for a predetermined period of time, for example.

[0153] Although the present embodiment has been described with reference to a blockchain game, the game realized by the game system 1 according to the present embodiment may be a game other than a blockchain game. Furthermore, the present embodiment may be applied to a system that realizes a service that provides a virtual space as described above to users.

[0154] The present invention is not limited to the above-described embodiments, and the components can be modified and embodied in practice without departing from the spirit of the invention. Furthermore, various inventions can be created by appropriately combining multiple components disclosed in the above-described embodiments. For example, some components may be omitted from all the components shown in the embodiments. Furthermore, components from different embodiments may be appropriately combined.

[0155] "Addendum" Some of the features of the present invention are summarized below. "assignment" For example, the purpose is to prevent a decline in the user's interest. "Solution" (1) Computer, a control means for controlling the user to restrict use of the borrowed first object when a first operation by the user using the borrowed first object satisfies a first condition; A program that functions as a (2) the first object is owned by a user different from the user, the first condition is a condition regarding use of the first object; (1) The program described above. (3) The program according to (1) or (2), wherein the control means outputs guidance regarding the first operation when the first operation satisfies a second condition that is the same as or at least partially different from the first condition, and cancels the state in which the user can use the first object when the first operation satisfies the first condition after outputting the guidance. (4) The program according to (1) or (2), wherein the first condition includes that the number of times the first operation using the first object has been performed on a second object exceeds a predetermined value. (5) The program according to (4), wherein the control means resets the number of times the first operation using the first object has been performed on the second object when a second operation different from the first operation is performed. (6) The program according to (1) or (2), wherein the first condition includes that the number of times the first operation is performed at a position that is a predetermined distance or more away from a third object exceeds a predetermined value. (7) The program according to (1) or (2), wherein the first condition includes that the number of times the first operation is performed while the parameter value of the first object is within a predetermined range exceeds a predetermined value. (8) The program according to (1) or (2), wherein the first condition changes based on parameters set in a virtual space in which the first object is used based on the user, the first object, or the first operation. (9) The program according to (1) or (2), wherein the first condition includes that a first operation is performed in a predetermined pattern. (10) the control means receives and displays messages sent by other users; The first condition includes the first operation being terminated without responding to the message. The program described in (1) or (2). (11) Computer, a control means for imposing a restriction on a first operation using a first object when a second user uses a first object borrowed from a first user who owns the first object in a virtual space, and for not imposing a restriction on the first operation when the first user uses the first object in the virtual space; A program that functions as a The solution constituted by the above program may be appropriately applied to the fields of devices, systems, methods, and media. "effect" The configurations (1), (2) and (4) to (10) have the effect of, for example, avoiding disadvantages to the user and preventing the user's interest from decreasing. The configuration (3) has the effect of urging the user to perform an appropriate first operation, for example, by a guide. According to the configuration (11), for example, it is possible to avoid any disadvantage to the first user caused by imposing restrictions on the first operation of the second user, and to prevent the first user's interest from decreasing. [Explanation of symbols]

[0156] 1...game system, 10...user terminal, 11...non-volatile memory, 12...CPU, 13...main memory, 14...communication device, 15...input device, 16...display device, 20...server device, 21...non-volatile memory, 22...CPU, 23...main memory, 24...communication device, 30...network, 40...blockchain system, 101...operation reception unit, 102...transmission / reception unit, 103...control unit, 104...display processing unit, 105...storage unit, 201...storage unit, 202...transmission / reception unit, 203...control unit, 204...management unit.

Claims

1. Computer, a control means for controlling the user to restrict use of the borrowed first object when a first operation by the user using the borrowed first object satisfies a first condition; A program that functions as a

2. the first object is owned by a user different from the user, the first condition is a condition regarding use of the first object; The program according to claim 1.

3. The program of claim 1 or 2, wherein the control means outputs guidance regarding the first operation when the first operation satisfies a second condition that is the same as or at least partially different from the first condition, and cancels the state in which the user can use the first object when the first operation satisfies the first condition after outputting the guidance.

4. 3. The program according to claim 1, wherein the first condition includes a condition that the number of times the first operation using the first object has been performed on a second object exceeds a predetermined value.

5. 5. The program according to claim 4, wherein the control means resets the number of times the first operation using the first object has been performed on the second object when a second operation different from the first operation is performed.

6. 3. The program according to claim 1, wherein the first condition includes a condition that the number of times the first operation is performed at a position at a predetermined distance or more from a third object exceeds a predetermined value.

7. 3. The program according to claim 1, wherein the first condition includes a condition that the number of times the first operation is performed in a state where a parameter value of the first object is within a predetermined range exceeds a predetermined value.

8. 3. The program according to claim 1, wherein the first condition changes based on a parameter set in the virtual space in which the first object is used based on the user, the first object, or the first operation.

9. 3. The program according to claim 1, wherein the first condition includes a first operation being performed in a predetermined pattern.

10. the control means receives and displays messages sent by other users; The first condition includes that the first operation is performed without responding to the message.

3. The program according to claim 1 or 2.

11. Computer, a control means for imposing a restriction on a first operation using a first object when a second user uses a first object borrowed from a first user who owns the first object in a virtual space, and for not imposing a restriction on the first operation when the first user uses the first object in the virtual space; A program that functions as a

12. a control means for controlling the user to restrict use of the borrowed first object when a first operation by the user using the borrowed first object satisfies a first condition; A system comprising:

13. a control means for imposing a restriction on a first operation using a first object when a second user uses a first object borrowed from a first user who owns the first object in a virtual space, and for not imposing a restriction on the first operation when the first user uses the first object in the virtual space; A system comprising:

Images