System, method, and program for providing game

Abstract

To accelerate transactions of an appropriate game object outside a game.SOLUTION: A game providing server 10 according to one embodiment provides a user who operates a player terminal 30 communicably connected via a communication network 20 with a game. The server 10 changes an object used in a first game to a predetermined state according to a player's instruction when a predetermined condition is satisfied, and the object in the predetermined state is used in a second game and can be traded in predetermined services different from those of the first and second games, such that transactions of an object in a state in which a fixed condition is satisfied outside a game are accelerated.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a system, a method, and a program for providing a game. [Background technology]

[0002] Conventionally, in-game objects (characters, items, etc.) have been made tradable outside of the game. For example, the following Patent Document 1 discloses a game system that allows such in-game objects (non-fungible assets) to be easily exchanged outside of the game. Specifically, in this game system, in-game objects are issued as NFTs (Non-Fungible Tokens), and the NFTs are sent to a wallet address designated by a user. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent Publication No. 2021-152815 Summary of the Invention [Problem to be solved by the invention]

[0004] However, in the conventional system described above, although it is possible to trade in-game objects outside the game, if all objects become unconditionally tradable, the value of the objects in the trading market may decrease. Therefore, it is desirable to realize a system that allows appropriate objects to circulate in the trading market.

[0005] One object of embodiments of the present invention is to facilitate out-of-game trading of suitable game objects. Other objects of embodiments of the present invention will become apparent upon reference to this specification as a whole. [Means for solving the problem]

[0006] A system according to one embodiment of the present invention is a system for providing a game, comprising one or more computer processors, wherein the one or more computer processors execute a process of controlling the progress of a first game in which a first object owned by a player is used, a process of changing the first object to a predetermined state in response to an instruction from the player when a first condition is satisfied, and a process of controlling the progress of a second game in which the first object in the predetermined state is used, and the first object in the predetermined state is tradeable via a predetermined service different from the first game and the second game.

[0007] A method according to one embodiment of the present invention is executed by one or more computers and is a method for providing a game, comprising the steps of: controlling progress of a first game in which a first object owned by a player is used; when a first condition is satisfied, changing the first object to a predetermined state in response to an instruction from the player; and controlling progress of a second game in which the first object in the predetermined state is used, wherein the first object in the predetermined state is tradeable via a predetermined service different from the first game and the second game.

[0008] A program according to one embodiment of the present invention is a program for providing a game, which causes one or more computers to execute the following processes: controlling the progress of a first game in which a first object owned by a player is used; changing the first object to a predetermined state in response to an instruction from the player when a first condition is satisfied; and controlling the progress of a second game in which the first object in the predetermined state is used, and the first object in the predetermined state is tradeable via a predetermined service that is different from the first game and the second game. Effect of the Invention

[0009] Various embodiments of the present invention facilitate out-of-game trading of suitable game objects. [Brief description of the drawings]

[0010] [Figure 1] 1 is a diagram showing a schematic configuration of a network including a game providing server 10 according to an embodiment of the present invention. [Diagram 2] FIG. 15 is a diagram illustrating an example of information managed by a player information table 1511. [Diagram 3] 15 is a diagram illustrating an example of information managed by a character management table 1512. [Figure 4] 15 is a diagram illustrating an example of information managed by a facility management table 1513. [Diagram 5] FIG. 15 is a diagram illustrating an example of information managed by a request management table 1514. [Figure 6] FIG. 4 is a diagram illustrating a main screen 50. [Figure 7] FIG. 13 is a diagram illustrating the main screen 50 when "Adventurer" is selected in the tab selection area 56. [Figure 8] 4 is a flowchart illustrating a process executed by the server 10 in response to the generation of a character. [Figure 9] FIG. 6 is a diagram illustrating a provisionally registered character management screen 60. [Figure 10] FIG. 13 is a diagram illustrating an example of the main screen 50 when "Request" is selected in the tab selection area 56. [Figure 11] 6 is a flowchart illustrating a process executed by the server 10 for an initiated request. [Figure 12] 11 is a flowchart illustrating a process executed by the server 10 to determine whether a monster has attacked a guild of each player. [Figure 13] 5 is a diagram illustrating an example of a character information display area 583 when the corresponding character is a hero. [Figure 14] A sequence diagram illustrating the processing performed between the game providing server 10 and the token management server 22 when issuing an NFT in response to the transformation of a character into a heroic spirit. [Figure 15] 4 is a flowchart illustrating a process executed by the server 10 when a war game is played. [Figure 16]FIG. 7 is a diagram illustrating a party selection screen 70. [Figure 17] FIG. 13 is a diagram illustrating a battlefield selection screen 80. [Figure 18] A figure showing an example of a heroic spirit revival instruction screen 90. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Hereinafter, embodiments of the present invention will be described with reference to the drawings. In each drawing, the same reference numerals may be used to denote the same or similar components.

[0012] FIG. 1 is a diagram showing a schematic configuration of a network including a game providing server 10 according to one embodiment of the present invention. As shown in the figure, the server 10 is communicatively connected to player terminals 30 via a communication network 20 such as the Internet. Although only one player terminal 30 is shown in FIG. 1, the server 10 may be communicatively connected to a plurality of player terminals 30. The server 10 provides a game to a user who operates the player terminal 30. The game providing server 10 is an example of a device that implements all or a part of the system of the present invention.

[0013] First, a description will be given of the hardware configuration of the game providing server 10. The game providing server 10 is configured as a general computer, and as shown in Fig. 1, includes a computer processor 11, a main memory 12, an input / output I / F 13, a communication I / F 14, and a storage (storage device) 15, and these components are electrically connected via a bus or the like (not shown).

[0014] The computer processor 11 is configured as a CPU, a GPU, or the like, and loads various programs stored in a storage 15 or the like into a main memory 12, and executes various instructions included in the programs. The main memory 12 is configured, for example, by a DRAM or the like.

[0015] The input / output I / F 13 includes various input / output devices for exchanging information with an operator, etc. The input / output I / F 13 includes, for example, an information input device such as a keyboard, a pointing device (e.g., a mouse, a touch panel, etc.), an audio input device such as a microphone, and an image input device such as a camera. The input / output I / F 13 also includes an image output device such as a display, and an audio output device such as a speaker.

[0016] The communication I / F 14 is implemented as hardware such as a network adapter, various communication software, or a combination of these, and is configured to realize wired or wireless communication via a communication network 20 or the like.

[0017] The storage 15 is composed of, for example, a magnetic disk, a flash memory, etc. The storage 15 stores various programs including an operating system, various data, etc. For example, as shown in FIG. 1, the storage 15 has various tables 151 for managing various information, and also stores a server-side program 40 according to an embodiment of the present invention. The program 40 is a program for causing the game providing server 10 to function as all or part of a system for providing a game. At least a part of the server-side program 40 can be configured to be executed on the player terminal 30 side via a terminal-side program 42 described later.

[0018] In this embodiment, the game providing server 10 may be configured using a plurality of computers each having the above-mentioned hardware configuration. For example, the server 10 may be configured by one or a plurality of server devices.

[0019] The game providing server 10 configured in this manner functions as a web server and an application server, executes various processes in response to requests from the terminal-side program 42 installed in the player terminal 30, and transmits screen data (e.g., HTML data) and control data according to the results of the processes to the player terminal 30. In the player terminal 30, a web page or other screen based on the received data is output.

[0020] Next, a description will be given of the hardware configuration of the player terminal 30. The player terminal 30 is configured as a general computer, and as shown in Fig. 1, includes a computer processor 31, a main memory 32, an input / output I / F 33, a communication I / F 34, and a storage (storage device) 35, and these components are electrically connected via a bus or the like (not shown).

[0021] The computer processor 31 is configured as a CPU, a GPU, or the like, and loads various programs stored in a storage 35 or the like into a main memory 32 and executes various instructions included in the programs. The main memory 32 is configured, for example, by a DRAM or the like.

[0022] The input / output I / F 33 includes various input / output devices for exchanging information with an operator, etc. The input / output I / F 33 includes, for example, an information input device such as a keyboard or a pointing device (e.g., a mouse, a touch panel, etc.), an audio input device such as a microphone, and an image input device such as a camera. The input / output I / F 33 also includes an image output device such as a display, and an audio output device such as a speaker.

[0023] The communication I / F 34 is implemented as hardware such as a network adapter, various communication software, or a combination of these, and is configured to realize wired or wireless communication via the communication network 20 or the like.

[0024] The storage 35 is configured, for example, by a magnetic disk or a flash memory. The storage 35 stores various programs including an operating system, various data, and the like. The programs stored in the storage 35 can be downloaded from an application market or the like and installed. The storage 35 also stores the above-mentioned terminal-side program 42. The program 42 can be configured as a web browser or other application (e.g., a game application, etc.) and can be configured to execute at least a part of the server-side program 40 as described above.

[0025] In this embodiment, the player terminal 30 may be configured as a smartphone, a tablet terminal, a wearable device, a personal computer, a dedicated game terminal, or the like.

[0026] A user (game player) operating a player terminal 30 configured in this manner can play a game provided by the server 10 by communicating with the server 10 via a terminal-side program 42 installed in storage 35 or the like.

[0027] Next, a description will be given of the functions of the game providing server 10 configured as above. The computer processor 11 of the server 10 is configured to function as a management function control unit 111 and a game progress control unit 113 by executing instructions included in a program (e.g., at least a part of the server-side program 40) loaded into the main memory 12, as shown in FIG.

[0028] The management function control unit 111 is configured to execute various processes related to the control of the management function of the game. For example, the management function control unit 111 transmits screen data and control data of various screens related to the management function to the player terminal 30, executes various processes in response to an operation input by a player via the screen output on the player terminal 30, and transmits screen data and control data according to the results of the processes to the player terminal 30. The management functions controlled by the management function control unit 111 include, for example, login processing (user authentication), billing control, and management of player accounts.

[0029] The game progress control unit 113 is configured to execute various processes related to the control of the progress of the game. For example, the game progress control unit 113 transmits screen data and control data of various screens for progressing the game to the player terminal 30, executes various processes in response to operation input by the player via the screen output on the player terminal 30, and transmits screen data, control data, etc. according to the results of the processes to the player terminal 30.

[0030] In this embodiment, the game progress control unit 113 is configured to control the progress of the first game. The first game is configured as a game in which objects owned by the player are used. The objects may be implemented as characters, cards, or the like. The first game may include various types of games.

[0031] Furthermore, the game progress control unit 113 is configured to change the object to a predetermined state in response to an instruction from the player when a predetermined condition is satisfied. Such an instruction from the player is given, for example, via a screen displayed on the player terminal 30.

[0032] Moreover, the game progress control unit 113 is configured to control the progress of the second game. The second game is configured as a game in which the object in the above-mentioned predetermined state is used. The second game may include various types of games.

[0033] In this embodiment, the object in the predetermined state is configured to be tradeable via a predetermined service different from the first game and the second game. For example, when changing an object to a predetermined state, the game progress control unit 113 sets the object as an object that can be traded in the predetermined service. The predetermined service may include various types of services.

[0034] In this manner, the game providing server 10 in this embodiment changes the object used in the first game to a predetermined state in response to an instruction from the player when a predetermined condition is satisfied, and the object in the predetermined state is used in the second game and can be traded in a predetermined service different from the first and second games, so that trading of the object outside the game in a state where certain conditions are satisfied is promoted. In other words, the server 10 promotes trading of appropriate game objects outside the game.

[0035] In this embodiment, the game progress control unit 113 can be configured to associate a non-fungible token (NFT) managed on a blockchain platform (e.g., Ethereum) with the object after it has changed to a predetermined state. In this case, the object may be made tradable through token transactions in a predetermined service (e.g., a token transaction intermediation service). The correspondence between the object and the token is managed on the game providing server 10 or on the blockchain platform. Such a configuration enables trading of the object through trading of the non-fungible token.

[0036] In this embodiment, the above-mentioned predetermined condition that enables the object to change to a predetermined state may include various conditions. For example, the condition is configured as a condition that is satisfied in response to the first game progressing to a predetermined stage. The predetermined stage includes, but is not limited to, for example, a stage in which a predetermined number of turns have passed in a turn-based game, a stage in which a predetermined time has passed in real time, a stage in which a game has progressed to a predetermined part of a scenario, a stage in which a specific object (enemy character, etc.) has been defeated, a stage in which a specific item has been obtained, and a stage in which a specific stage or quest, etc. has been cleared. Such a configuration realizes that the object can be changed to a predetermined state in response to the progress stage of the first game.

[0037] Furthermore, for example, the above-mentioned predetermined condition is configured as a condition that is satisfied when the value of a parameter possessed by an object, which parameter changes as the first game progresses, reaches a threshold value. The parameters possessed by an object include, but are not limited to, for example, a level, maximum HP (hit points), ATK (attack power), DEF (defense power), the total of at least a part of these, age, and maximum stamina. Such a configuration realizes that it is possible to change an object to a predetermined state according to the value of the parameter possessed by the object.

[0038] In this embodiment, after an object changes to a predetermined state, at least some of the parameters of the object may not change (the values ​​are fixed). In other words, the parameters change according to the progress of the first game, and the values ​​are locked according to the change of the object to the predetermined state. This configuration suppresses fluctuations in the value of the object that is the subject of a transaction outside the game.

[0039] Furthermore, the game progress control unit 113 may be configured to, after the predetermined condition is satisfied, cause an object that has not changed to the predetermined state to disappear (including nullify) at a predetermined timing. The predetermined timing is, for example, the timing when a disappearance condition (for example, the value of a parameter possessed by the object reaches a threshold value) is satisfied. Such a configuration promotes the change of an object that satisfies the predetermined condition to the predetermined state.

[0040] In this embodiment, the second game may use other objects in a predetermined state that the player has acquired via a predetermined service. In this case, the player uses in the second game an object that the player himself / herself used in the first game by changing it to a predetermined state, and also uses in the second game an object acquired (e.g., purchased) via a predetermined service (e.g., an object that another player used in the first game and changed to a predetermined state). Such a configuration promotes the acquisition of objects via a predetermined service.

[0041] In this embodiment, the second game may use an object that is not tradeable through a predetermined service and is not used in the first game. The object may be said to be an object exclusive to the second game. This configuration increases the interest of the second game.

[0042] Furthermore, the game progress control unit 113 may be configured to cause an object in a predetermined state that satisfies a disappearance condition to disappear (including nullification) as the second game progresses. The disappearance condition includes various conditions, including a condition that is satisfied when the value of a parameter possessed by the object reaches a threshold value. This configuration prevents the number of objects in a predetermined state from becoming excessive.

[0043] In this case, the game progress control unit 113 may be configured to cancel the disappearance of an object that satisfies the disappearance condition when a predetermined value is consumed by the player. Furthermore, in this case, when the number of times the disappearance of an object is canceled in response to the consumption of the predetermined value reaches a threshold value, it may be made impossible to cancel the disappearance of the object (i.e., the object is destroyed). The predetermined value includes real value (currency, etc.) or virtual value (item, etc.), etc. This configuration gives the player the fun of canceling the disappearance of an object.

[0044] Furthermore, the game progress control unit 113 may be configured to grant the player an item that was set to an object that satisfies the disappearance condition when that object disappears. In other words, the item remains as an item owned by the player even if the object disappears. This configuration encourages effective use of the item that was set to the disappeared object.

[0045] Next, a specific example of one aspect of the game providing server 10 of this embodiment having such functions will be described. In this example, the game provided by the server 10 is a game in a genre called an "idle game," and is configured as a game that progresses according to the passage of real time regardless of whether the player logs in. The game, which will be described in detail later, is configured of a first game in which a guild is managed and adventurers are trained, and a second game in which the grown adventurers are used to wage war against other players.

[0046] First, the information managed by each table in this example will be described. FIG. 2 illustrates information managed by the player information table 1511 in the storage 15 in this example. The player information table 1511 manages information about the player of the game, and as shown in the figure, manages information such as "basic information" including the account name and date of birth, "game start date and time" which is the date and time (year, month, day and time) when the game was started, "number of coins", "experience value", "date and time of defeating the latest monster", "owned item information", "token management account", and "stamina" in association with a "player account" which identifies an individual player. The number of coins, experience value, and stamina are parameters that increase with the passage of real time regardless of whether the player is logged in or not, as will be described in detail later.

[0047] The token management account is an account for a token management service provided by the token management server 22, which will be described later. In this example, the token management service uses the Ethereum platform to manage tokens, and the Ethereum address of the corresponding user is associated with the token management account. The token management account can also be called a wallet account.

[0048] 3 illustrates information managed by the character management table 1512 of the storage 15 in this example. The character management table 1512 manages information related to characters, and as illustrated, manages information such as a "player account" identifying the player who owns the character, a "character state type" indicating the state of the character, a "lifetime remaining", "attributes", "job", "various status information", "level limit", "level", "rank", "equipment information", "skill information", "token ID", a "player spirit character flag" indicating whether the character is a player spirit character, and a "number of resurrections", in association with a "character ID" identifying an individual character. The state of a character specified by the character state type includes "provisional registration", "unregistered", "real registration", "hero", "heroic spirit", "death", and "deletion".

[0049] The remaining lifespan is a parameter that decreases (counts down) according to the passage of real-world time. In this example, a character will enter a "death" state when the remaining lifespan reaches 0. Note that for characters who have entered a "hero" state, the decrease in the remaining lifespan stops, meaning that death due to lifespan will no longer occur.

[0050] As will be described in detail later, the level limit is a parameter that increases with the passage of real time. The number of resurrections indicates the number of times a character in the "Heroic Spirit" state has been resurrected from the "Death" state.

[0051] 4 illustrates, in this example, information managed by the facility management table 1513 in the storage 15. The facility management table 1513 manages information related to facilities owned by each player, and as shown in the figure, manages information such as "facility type" and "level" indicating the type of facility in association with a combination of a "player account" that identifies the player and a "facility ID" that identifies the facility for each player.

[0052] 5 illustrates information managed by the request management table 1514 of the storage 15 in this example. The request management table 1514 manages information related to requests (missions) registered for each player, and as shown in the figure, manages information such as "request status type", "request content information", "request start date and time", "participating character information", and "request result information" indicating the status of the request, in association with a combination of a "player account" that identifies the player and a "request ID" that identifies the request for each player. The status of the request specified by the request status type includes "provisional registration", "not registered", "full registration", "in progress", and "completed".

[0053] The information managed by each table in this example has been described above. Next, the process executed by the server 10 and the screens outputted on the player terminals 30 in this example will be described.

[0054] 6 illustrates an example of a main screen 50 output on the player terminal 30. The screen 50 is a screen for playing a first game in which a guild is managed and adventurers are trained, and as illustrated, has a resource information display area 52 that displays information about resources (coins and experience points) possessed by the player, a game image display area 54 that displays images according to the progress of the game, a war button 55 disposed in the upper right corner of the area 54, a tab selection area 56 for selecting a tab, and a tab-corresponding information display area 58 that displays information corresponding to the tab selected via the area 56.

[0055] The resource information display area 52 has a coin number display area 521 that displays the number of coins owned by the player, and an experience value display area 522 that displays the experience value owned by the player.

[0056] The tab selection area 56 is configured so that one tab can be selected from three tabs: "Town," "Adventurer," and "Request." The main screen 50 in Fig. 6 corresponds to a state in which "Town" is selected in the tab selection area 56, and this "Town" tab is a tab for performing operations related to facilities constructed in the player's guild.

[0057] When "Town" is selected in the tab selection area 56, one or more facility information display areas 581, each displaying information about an individual facility, are arranged vertically in the tab-corresponding information display area 58, and below these areas 581 is a vacant lot button 582 with the text "vacant lot" added to it.

[0058] The facility information display area 581 corresponds to a facility owned by the player (that exists in the guild), and has a level up button 5811, which is an object for instructing to level up the facility, and a level progress indicator 5812 that shows the progress of the current level of the facility relative to the maximum level. The level up button 5811 displays the number of coins required to level up. When the button 5811 is selected, the level of the corresponding facility is increased by one and the player's coins are consumed. The number of coins required to level up increases as the level increases.

[0059] In this example game, there are three types of facilities: (1) A facility that produces coins (2) Facilities that produce experience points (3) Facilities that generate special effects In facilities that produce coins, a certain number of coins are produced and given to the player every time a unit of time (e.g., 10 seconds) passes in real time. The higher the level, the greater the number of coins produced. Similarly, in facilities that produce experience points, a certain number of experience points are produced and given to the player every time a unit of time (e.g., 10 seconds) passes in real time. The higher the level, the greater the number of experience points produced.

[0060] In this example, the time required to produce coins and / or experience points through the facility may be shortened through charging (time-saving charging). The charging may be made by real value (currency, etc.) or virtual value (item, etc.).

[0061] The vacant lot button 582 is an object for instructing the construction of a new facility. When the button 582 is selected, a screen (not shown) for specifying the type of facility to be constructed is displayed, and the player can instruct the construction of the desired type of facility via the screen. In response to the construction of the facility, the player's coins are consumed, and a new record is inserted in the facility management table 1513 and a corresponding value is set. Also, a facility information display area 581 corresponding to the newly constructed facility is added to the tab corresponding information display area 58.

[0062] 7 illustrates an example of the main screen 50 when "Adventurer" is selected in the tab selection area 56. In the tab-corresponding information display area 58 on the main screen 50 in this state, as shown in the figure, one or more character information display areas 583, each of which displays information about an individual character (adventurer), are arranged vertically.

[0063] The character information display area 583 corresponds to a character owned by the player (living in the guild), and has a level up button 5831, which is an object for instructing to level up the character, and a level progress indicator 5832, which indicates the progress of the current level of the character relative to the maximum level. The level up button 5831 displays the number of experience points required for level up. When the button 5831 is selected, the level of the corresponding character is increased by one and the player's experience points are consumed. When the character's level is increased, various status information of the character is updated according to the settings of a predetermined growth table. Changes in status vary depending on the type, number, and level of facilities existing in the guild.

[0064] Above the level progress indicator 5832, the progress of the current level of the character relative to the maximum level is displayed in the format of [current level] / [maximum level] along with the name of the character. Also, in this example, the maximum level of each character owned by the player increases according to the passage of real time. Below the level progress indicator 5832, the unit time (e.g., 2 hours) required to increase the maximum level by one is displayed.

[0065] In this example, the time required to increase the maximum level of a character may be shortened through a charge (time-saving charge). The charge may be made with real value (currency, etc.) or virtual value (item, etc.). For example, the charge may increase the maximum level by 24 hours.

[0066] In this example, a lottery for character generation is held periodically (e.g., every 60 minutes) in accordance with the passage of real time, and if the lottery is won, the character is provisionally granted to the player. The conditions for character generation (e.g., the interval between lotteries and the probability of winning, etc.) vary depending on the number of facilities in the guild, the existence of facilities with special effects that change the conditions for character generation, and their levels, etc.

[0067] 8 is a flow chart illustrating a process executed by the server 10 in response to the generation of a character (winning the lottery). As shown in the figure, the server 10 first sets various parameters of the generated character (step S100). Specifically, parameters such as the character's lifespan, attributes, and job are determined by lottery. In addition, initial skills are determined based on the attributes and job determined by lottery, and initial equipment is determined based on the job.

[0068] Next, the server 10 provisionally registers the character (step S110). Specifically, a new record is inserted and corresponding values ​​are set in the character management table 1512. A value corresponding to "provisional registration" is set as the character status type.

[0069] 9 illustrates a provisionally registered character management screen 60 for managing provisionally registered characters. As shown in the figure, the screen 60 has a list display area 62 that displays a list of provisionally registered characters, a register button 64, and a delete button 66.

[0070] The list display area 62 displays a list of characters owned by the player that are in the "provisionally registered" status. As shown in the figure, one or more individual display areas 621, each of which corresponds to an individual character, are arranged side by side in the area 62. The area 621 displays information about the character (image, name, etc.).

[0071] When the registration button 64 is selected while any of the individual display areas 621 is selected, the corresponding character is officially registered. Specifically, in the character management table 1512, a value corresponding to "official registration" is set as the character status type of the corresponding character. On the other hand, when the delete button 66 is selected, the corresponding character is deleted (cancelled from provisional registration). Specifically, in the character management table 1512, a value corresponding to "non-registration" is set as the character status type of the corresponding character. In addition, when a character is officially registered, a character information display area 583 corresponding to the newly registered character is added to the tab corresponding information display area 58. Note that an upper limit is set for the number of characters that can be officially registered at the same time, and the player cannot officially register characters in excess of the upper limit at the same time.

[0072] 10 illustrates an example of the main screen 50 when "Request" is selected in the tab selection area 56. In the tab corresponding information display area 58 on the main screen 50 in this state, as shown in the figure, one or more request information display areas 584, each of which displays information related to an individual request (mission), are arranged vertically.

[0073] The request information display area 584 corresponds to a registered request, and has a start button 5841 which is an object for instructing the start of the request.

[0074] In this example, a lottery is held periodically (e.g., every 60 minutes) in accordance with the passage of real-world time, and if the player wins the lottery, the request is provisionally granted to the player. The conditions for issuing a request (e.g., the interval between lotteries, the probability of winning, and the content of the request, etc.) vary depending on the character registration status (the number of registered characters, various parameters, etc.). The content of the request includes, for example, dungeon exploration and monster slaying.

[0075] The player can officially register or delete a provisionally registered request via a screen similar to the provisionally registered character management screen 60 described above. When a provisionally registered request is officially registered, a value corresponding to "official registration" is set as the request status type of the corresponding request in the request management table 1514. On the other hand, when a provisionally registered request is deleted, a value corresponding to "non-registration" is set as the request status type of the corresponding request in the request management table 1514. When a request is officially registered, the player's coins are consumed (the number of coins consumed varies depending on the content of the request). When a request is officially registered, a request information display area 584 corresponding to the newly registered request is added to the tab corresponding information display area 58.

[0076] When the start button 5841 is selected, one or more characters participating in the request are automatically set, and the execution of the request begins. The number of characters participating in the request is set in advance based on the content of the request. The player can also change the characters participating in the request via a screen not shown. In this example, one character can only participate in one request at the same time. The player can also have multiple requests in progress at the same time.

[0077] 11 is a flowchart illustrating a process executed by the server 10 for a started request. As shown in the figure, the server 10 first waits for a predetermined time to elapse (NO in step S200). The predetermined time here is a time that is determined in advance based on the contents of the request, and can also be said to be the time required to complete the contents of the request.

[0078] Then, when a predetermined time has elapsed (YES in step S200), the server 10 determines whether the request will be successful (step S210). Specifically, the success or failure of the request is determined through a lottery according to a predetermined probability of winning.

[0079] If the request is successful (YES in step S220), the server 10 increases the character's rank and grants the equipment (step S230). Specifically, the rank of the corresponding character is updated (increased by 1) in the character management table 1512, and the information on items held by the corresponding player is updated in the player information table 1511. The equipment to be granted is preset according to the content of the request. The player can equip the acquired equipment to the character, and can also sell the equipment to earn coins.

[0080] After the character is ranked up and equipped, if the request is to defeat a monster (YES in step S240), the server 10 updates the player's most recent monster defeat date and time (step S250). Specifically, in the player information table 1511, the most recent monster defeat date and time of the corresponding player is updated to the current date and time.

[0081] On the other hand, if the request fails (NO in step S220), the server 10 draws a lottery to see whether the characters who participated in the request will die, and kills the characters who win the lottery (step S260). Specifically, in the character management table 1512, the character status type of the corresponding character is updated to a value corresponding to "death."

[0082] Here, a description will be given of a monster attack on a guild. Fig. 12 is a flowchart illustrating a process executed by the server 10 to determine whether a monster has attacked a guild of each player. As shown in the figure, the server 10 first waits for a predetermined time to elapse from the latest monster defeat date and time (NO in step S300).

[0083] Then, when a predetermined time has elapsed (YES in step S300), the server 10 kills the character and reduces the level of the facility (step S310). Specifically, in the character management table 1512, the character status type of the corresponding character is updated to a value corresponding to "death", and the level value of the corresponding facility is updated (decreased by a predetermined value) in the facility management table 1513. Thus, in this example, if a request to defeat a monster is not successful for a certain period of time, the player's guild is attacked by a monster, the character dies, and the level of the facility is reduced.

[0084] Here, the process of turning a character into a heroic spirit will be explained. In this example, when a character's rank (which increases according to the success of a request) reaches a predetermined value or higher, the character changes from "registration" to "hero." Specifically, in the character management table 1512, the character status type of the corresponding character is updated to a value corresponding to "hero." Then, a character that has become a "hero" can be "turned into a heroic spirit."

[0085] 13 illustrates the character information display area 583 when the corresponding character is a hero (i.e., the rank is equal to or greater than a predetermined value). In the character information display area 583 in this state, as shown in the figure, a heroic spirit button 5833 is disposed on the lower right side of the level progress indicator 5832. The button 5833 is an object for instructing the corresponding character (hero) to be heroic spirit.

[0086] When the hero button 5833 is selected, the corresponding character changes from "Hero" to "Heroic Spirit" (predetermined state). Specifically, in the character management table 1512, the character state type of the corresponding character is updated to a value corresponding to "Heroic Spirit".

[0087] Furthermore, when a character becomes a Heroic Spirit, an NFT, which is a non-fungible token managed on a blockchain, is issued and the NFT is associated with the Heroic Spirit character. The issuance of the NFT is requested from the token management server 22, which is communicatively connected to the game providing server 10 via a communication network 20. The token management server 22 has a hardware configuration as a general computer, and has a function for managing NFTs. Such NFTs are managed, for example, on the Ethereum platform.

[0088] 14 is a sequence diagram illustrating the processing performed between the game providing server 10 and the token management server 22 when issuing an NFT in response to turning a character into a heroic spirit. First, the game providing server 10 transmits a request to issue an NFT to the token management server 22 (step S400). As shown in the figure, the request to issue an NFT is made along with the token management account of the corresponding player and the URL of the reference destination (image data) of the NFT. The token management account of the player is managed in the player information table 1511. Furthermore, the URL of the reference destination of the token is generated randomly and includes the name of the image file of the character, etc.

[0089] Next, the token management server 22 that has received the request to issue the NFT issues the NFT (step S410). Specifically, the token management server 22 issues an NFT that is owned by the token management account received from the game providing server 10 and references the URL also received. The reference URL is recorded on the blockchain as part of the metadata of the NFT. In response to the issuance of the NFT, the token management server 22 also transmits a token ID that identifies the issued NFT to the game providing server 10.

[0090] Next, the game providing server 10 receives and registers the token ID from the token management server 22 (step S420). Specifically, the value of the received token ID is set for the token ID of the corresponding character in the character management table 1512. In this way, the character that has been turned into a heroic spirit is managed in association with the NFT.

[0091] The NFT associated with the heroic character becomes the subject of trading in the NFT trading intermediary function of the token management service provided by the token management server 22. For example, in the token management service, when the owner is changed in response to a trade of an NFT, and a request accompanied by a token ID and a token management account of the transferee is received from the token management server 22, the game providing server 10 changes the owner of the character corresponding to the received token ID to the player corresponding to the token management account also received (in the character management table 1512, the player account of the corresponding character is changed to a value corresponding to the changed player). Thus, in this example, the heroic character can be traded through trading of NFTs in the token management service.

[0092] In this example, the characters that have been turned into heroic spirits are not eligible for training or requests. In other words, the characters that have been turned into heroic spirits cannot be used in the first game, and the values ​​of various parameters are also fixed. The characters that have been turned into heroic spirits are also hidden in the corresponding character information display area 583 in the tab corresponding information display area 58.

[0093] In this example, a charge may be required when turning a character into a heroic spirit. The charge may be in the form of real value (currency, etc.) or virtual value (item, etc.). The charge when turning a character into a heroic spirit may cover only the Ethereum gas fee required to issue the NFT, or may include an NFT issuance fee.

[0094] In this example, the character may be transformed into a heroic spirit (free of charge) by consuming a heroic spirit item (stamina) that recovers over a predetermined time (e.g., 24 hours). In this case, the predetermined time may be shortened through a charge (time-saving charge). The charge may be made in real value (currency, etc.) or virtual value (item, etc.). The greater the number of characters that have been transformed into heroic spirits, the longer the predetermined time required to recover the heroic spirit item may be. Such a mechanism may prevent the issuance of an excessive number of NFTs.

[0095] The war button 55 on the top screen 50 is an object for playing a war game (second game) in which players battle with other players. The war game is played using characters that have been turned into heroic spirits.

[0096] 15 is a flow chart illustrating a process executed by the server 10 when a war game is played. As shown in the figure, the server 10 first accepts the selection of a force (step S500). Specifically, the selection of the force to which the player belongs from among three forces (teams) is accepted via a screen not shown.

[0097] Next, the server 10 accepts the selection of a party (step S510). Fig. 16 illustrates a party selection screen 70 for selecting a party, which is output on the player terminal 30. As illustrated, the screen 70 has a party information display area 72 that displays information about individual parties, and a confirmation button 74. In this example, the player can set up to three parties, and on the party selection screen 70, up to three party information display areas 72 are arranged vertically.

[0098] The party information display area 72 has a player spirit character information display area 721 that displays information about the player spirit characters included in the corresponding party, and a heroic spirit character information display area 722 that displays information about the heroic spirit characters included in the corresponding party. In this example, the party is composed of one player spirit character and up to 10 heroic spirit characters. In the party information display area 72, one or more heroic spirit character information display areas 722 are arranged side by side.

[0099] In this example, the player can create up to three player spirit characters. The player spirit characters are created by consuming experience points. In response to the creation of the player spirit characters, a new record is created in the character management table 1512, and a corresponding value is set. The player spirit characters are characters exclusive to the war game, and are not used in the first game (development and requests).

[0100] Returning to the flowchart of FIG. 15, the server 10 then accepts the selection of a battlefield (step S520). FIG. 17 illustrates a battlefield selection screen 80 for selecting a battlefield, which is output on the player terminal 30. As illustrated, the screen 80 has a battlefield information display area 82 that displays information about each battlefield, and a confirmation button 84. In this example, multiple battlefields are prepared for each district (there are four districts corresponding to the east, west, north and south), and the player can select the battlefield in which his or her party will participate. In the battlefield selection screen 80, multiple battlefield information display areas 82 are arranged vertically.

[0101] Returning to the flowchart of FIG. 15, the server 10 next accepts the setting of the number of battle days (step S530). Specifically, the setting of the number of battle days (number of days in real time) by the player is accepted via a screen not shown. Thus, in this example, the player can specify the number of battle days on the battlefield. When the number of battle days is specified, the player's stamina is consumed. The amount of stamina consumed increases as the number of battle days increases. As described above, stamina is restored according to the passage of real time. The time required for stamina recovery may be shortened through charging (time-saving charging). The charging may be performed by real value (currency, etc.) or virtual value (item, etc.).

[0102] Next, the server 10 locks the heroic spirit characters (step S540). Specifically, for each heroic spirit character included in the party participating in the battlefield, the owner of the corresponding NFT is temporarily changed from the player to the game operator. Such a change in the owner of the NFT is performed via the token management server 22. In this way, the heroic spirit characters participating in the war are prohibited from trading via the corresponding NFT.

[0103] Then, the server 10 conducts a battle on the battlefield (step S550). Specifically, matching of battle opponents is performed periodically, and a battle with the opponent's party is conducted. In the matching, players of other forces on the same battlefield are matched. In the battle, the characters included in the party attack the opponent's characters in turn, and each attack deals damage based on the parameters (e.g., attack power and defense power) possessed by each character. Such attacks are performed in turns, and continue until a predetermined number of turns are completed. A character whose HP reaches 0 is in a dead state. The parameters of the character applied in the battle are determined when the character is transformed into a heroic spirit.

[0104] Such battles on the battlefield are repeated until the set number of battle days (number of days in real time) has passed or all characters in the party are dead (NO in step S560). Then, when the set number of battle days has passed or all characters in the party are dead, the server 10 determines the battle result (step S570). The battle result is determined based on the results of the battle on the battlefield, and for example, a reward for the player is determined. The reward includes items that can be used in the war game, experience points for the player's spiritized character, and items that can be used for facilities.

[0105] Next, the server 10 accepts an instruction to revive the dead heroic character (step S580). Figure 18 shows an example of a heroic spirit revival instruction screen 90 for accepting an instruction to revive the dead heroic spirit character. As shown in the figure, the screen 90 has a dead hero information display area 92 that displays information about the dead heroic spirit character, a revival button 94 with the text "Resurrect" added, and a delete button 96 with the text "Do not revive".

[0106] In this example, one heroic character can be revived a predetermined number of times (e.g., eight times), and the player can instruct the revival of a dead heroic character via the heroic spirit revival instruction screen 90. The revival of a heroic spirit character is performed through a charge (the consumption of real value (currency, etc.) or virtual value (item, etc.)). When the revival button 94 is selected, the dead heroic spirit character becomes a normal "heroic spirit" state, accompanied by a charging process. The number of times a heroic spirit character is revived may be recorded on the blockchain in association with the corresponding NFT.

[0107] On the other hand, the delete button 96 on the heroic spirit revival instruction screen 90 is an object for instructing the deletion of a dead heroic spirit character. When the button 96 is selected, the character status type of the corresponding heroic spirit character in the character management table 1512 is changed from a value corresponding to "death" to a value corresponding to "deletion." The corresponding NFT is also deleted, and specifically, the owner of the corresponding NFT is changed to a deletion address (burn address) via the token management server 22.

[0108] In this example, when a dead heroic character is deleted, the initial equipment of the heroic character is given to the player as a legacy. The legacy can be used as equipment for the player's heroic character. It is also possible to combine multiple legacy items to strengthen the legacy or to obtain a different legacy.

[0109] Returning to the flowchart of FIG. 15, the server 10 then unlocks the heroic spirit characters (step S590). Specifically, for each heroic spirit character, the owner of the corresponding NFT is returned from the game operator to the player. As described above, the change of the owner of the NFT is performed via the token management server 22.

[0110] In the above example, facilities with various special effects can be constructed. For example, the special effects include an effect of postponing the next monster attack, an effect of automatically defeating the next monster attack (no damage occurs), an effect of preventing the death of a character when a request fails, and an effect of increasing the upper limit of the number of characters or items that can be possessed. Facilities with such special effects may be charged instead of or in addition to gold.

[0111] In the above example, the heroic spirit characters provided by the game operator may be acquired through trading (purchasing) the corresponding NFTs, and the war game may be played using the heroic spirit characters. In addition, such heroic spirit characters may be made available for purchase only when a certain purchase condition is met, for example, they may be made available for purchase only during an event period, or based on the results of the first or second game, or the total play time.

[0112] In the above example, a periodic charge (such as a monthly charge) may be made to increase the efficiency of obtaining available coins and experience points over real time. A periodic charge may also be made to allow a predetermined number of characters to be turned into heroes during a corresponding period (e.g., each month) (without being charged each time).

[0113] In the above example, a character whose rank is equal to or greater than a predetermined value can be turned into a heroic spirit, but the condition for turning a character into a heroic spirit may be other conditions. For example, the value of a parameter other than rank may be equal to or greater than a threshold value. Furthermore, a character may be turned into a heroic spirit based on the progress of the first game.

[0114] The game providing server 10 according to the present embodiment described above changes an object used in the first game (e.g., guild management and adventurer training) to a predetermined state in response to an instruction from a player (e.g., turning a character into a heroic spirit) when a predetermined condition is satisfied (e.g., when a character's rank reaches a predetermined value or more), and the object in the predetermined state is used in a second game (e.g., a war game) and can be traded in a predetermined service different from the first and second games (e.g., can be traded through NFT trading in a token management service), thus promoting trading of objects outside the game when certain conditions are satisfied. In other words, the server 10 promotes trading of appropriate game objects outside the game.

[0115] In other embodiments of the present invention, some or all of the functions of the game providing server 10 in the above-described embodiments may be realized by cooperation between the game providing server 10 and the player terminal 30, or may be realized by the player terminal 30.

[0116] In another embodiment of the present invention, the object may be changed to a predetermined state in response to an instruction from the player even if the predetermined condition is not satisfied. In this case, when the object is changed to the predetermined state while the predetermined condition is satisfied, an additional effect that is more advantageous than when the predetermined condition is not satisfied may be generated, and the additional effect may include, for example, the granting of an item (material reward), the strengthening of parameters (numerical reward), and an advantage in the game progress for a certain period of time (such as a reduction in stamina recovery time) (temporal reward).

[0117] The processes and procedures described herein may be realized by software, hardware, or any combination thereof, other than those explicitly described. For example, the processes and procedures described herein may be realized by implementing logic corresponding to the processes and procedures in a medium such as an integrated circuit, a volatile memory, a non-volatile memory, or a magnetic disk. In addition, the processes and procedures described herein may be implemented as a computer program corresponding to the processes and procedures, and executed by various computers.

[0118] Although processes and procedures described herein are described as being performed by a single device, software, component, or module, such processes or procedures may be performed by multiple devices, software, components, and / or modules. Also, the software and hardware elements described herein may be realized by combining them into fewer components or breaking them down into more components.

[0119] In this specification, even if a component of the invention is described as either singular or plural, or described without limitation to either singular or plural, the component may be either singular or plural unless the context requires otherwise. [Explanation of symbols]

[0120] 10 Game provider server 11. Computer Processors 111 Management function control section 113 Game progress control unit 15. Storage 151 Various Tables 1511 Player Information Table 1512 Character Management Table 1513 Facility Management Table 1514 Request Management Table 30 Player terminal 40 Server-side programs 42 Terminal side program 50 Main Screen 60 Provisional character management screen 70 Party selection screen 80 Battlefield Selection Screen 90 Heroic Spirit Resurrection Instruction Screen

Claims

1. A system for providing a game, comprising one or more computer processors, the one or more computer processors comprising: A process of controlling progress of a first game in which a first object owned by a player is used; a process of changing the first object into a predetermined state in response to an instruction from the player when a first condition is satisfied; controlling a progress of a second game in which the first object in the predetermined state is used; the first object in the predetermined state is tradeable via a predetermined service different from the first game and the second game; system.

2. The process of changing the first object includes associating a non-fungible token managed in a blockchain platform with the first object after the change to the predetermined state; The first object in the predetermined state is tradable through trading of the token in the predetermined service. The system of claim 1.

3. the first condition is a condition that is satisfied in response to the first game progressing to a predetermined stage; The system of claim 1.

4. the first condition is a first parameter of the first object, the first condition being a condition that is satisfied when a value of the first parameter that varies in accordance with progress of the first game reaches a threshold value; The system of claim 1.

5. the first object has a second parameter that varies according to progress of the first game; the second parameter does not change after the first object changes to the predetermined state; The system of claim 1.

6. the one or more computer processors further execute a process of eliminating, at a predetermined timing, the first object that has not changed to the predetermined state after the first condition is satisfied. The system of claim 1.

7. the second game further uses a second object in the predetermined state acquired by the player through the predetermined service; The system of claim 1.

8. The second game further uses a third object that is not tradeable through the predetermined service and is not used in the first game. The system of claim 1.

9. the one or more computer processors further execute a process of eliminating the first object in the predetermined state that satisfies a second condition in accordance with the progress of the second game. The system of claim 1.

10. the process of destroying the first object includes canceling the destruction of the first object when a predetermined value is consumed by the player. The system of claim 9.

11. the process of destroying the first object includes making it impossible to cancel the destruction of the first object when the number of times the destruction of the first object has been canceled in response to the consumption of the predetermined value reaches a threshold value; The system of claim 10.

12. the process of eliminating the first object includes, in response to the eliminating of the first object, granting an item that was set for the first object to the player. The system of claim 9.

13. 1. A method for providing a game, executed by one or more computers, comprising: controlling progress of a first game in which a first object owned by a player is used; changing the first object to a predetermined state in response to an instruction from the player when a first condition is satisfied; controlling progress of a second game in which the first object in the predetermined state is used, the first object in the predetermined state is tradeable via a predetermined service different from the first game and the second game; method.

14. A program for providing a game, comprising: A process of controlling progress of a first game in which a first object owned by a player is used; a process of changing the first object to a predetermined state in response to an instruction from the player when a first condition is satisfied; controlling a progress of a second game in which the first object in the predetermined state is used; the first object in the predetermined state is tradeable via a predetermined service different from the first game and the second game; program.

Images