Game server, game processing method, and computer program

Abstract

To provide a game server, a privilege imparting method, and a computer program capable of enhancing a motivation for a user to continue a game.SOLUTION: A game server 110 is a game server 110 for executing a game to determining winning or losing by a result of a battle of a plurality of turns includes: a turn execution unit 12 for executing battle processing on the basis of parameters of an object put in a field for each turn; and a parameter managing unit 11 for updating the parameters of the object accompanying the battle processing, and bringing parameters in a second turn following a first turn into an initial value for the object in which the parameters are equal to or lower than a predetermined threshold in the first turn.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a game server, a game processing method, and a computer program. [Background technology]

[0002] Conventionally, card games have been offered in which players play against opponents using decks containing multiple cards. Players of such card games devise strategies to quickly defeat opponents and devise ways to win against as many opponents as possible. [Prior art documents] [Patent documents]

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

[0004] In card games, even when players of the same skill level compete against each other, if they get a bad draw from the first turn, the game tends to go against them, making it very difficult to turn the tables and win. Furthermore, players who realize they cannot win often end up surrendering midway through the game, meaning many players are unable to enjoy the match to the end.

[0005] For example, if a player is at a disadvantage but has the possibility of turning the tables in the next turn, the game becomes more interesting and players are likely to continue the match without surrendering. If it is possible to prevent opponents from surrendering, more players will be able to enjoy the match to the end.

[0006] The present invention has been made in consideration of the above circumstances, and aims to provide a game server, a game processing method, and a computer program for a highly entertaining game that includes multiple battles. [Means for solving the problem]

[0007] A game server according to a first aspect of the present invention is a game server that executes a game in which victory or defeat is determined based on the results of a battle over multiple turns, and includes a turn execution unit that executes battle processing based on parameters of objects placed on the field for each turn, and a parameter management unit that updates the parameters of the objects in accordance with the battle processing, and, for objects whose parameters in the first turn have fallen below a predetermined threshold, sets the parameters in the second turn following the first turn to their initial values.

[0008] A game processing method according to a second aspect of the present invention is a game processing method for executing a game in which victory or defeat is determined based on the results of a battle over multiple turns, and for each turn, battle processing is executed based on parameters of objects placed on the field, the parameters of the objects are updated in accordance with the battle processing, and for objects whose parameters in the first turn are below a predetermined threshold, the parameters in the second turn following the first turn are set to their initial values.

[0009] A computer program according to a third aspect of the present invention is a computer program that causes a computer to execute the game processing method according to the second aspect. [Effects of the Invention]

[0010] According to the present invention, it is possible to provide a game server, a game processing method, and a computer program for a highly entertaining game that includes multiple battles. [Brief explanation of the drawings]

[0011] [Figure 1]FIG. 1 is a diagram illustrating an example of the configuration of a game system including a game server according to an embodiment. [Figure 2] FIG. 2 is a block diagram schematically illustrating an example of the configuration of a game system according to an embodiment. [Figure 3] FIG. 3 is a diagram illustrating an example of object information stored in a game server according to an embodiment. [Figure 4] FIG. 4 is a diagram illustrating an example of field information stored in a game server according to an embodiment. [Figure 5] FIG. 5 is a flowchart illustrating an example of the progress of a game provided by a game server according to an embodiment. [Figure 6] FIG. 6 is a diagram illustrating an example of rules of a game provided by a game server of an embodiment. [Figure 7] FIG. 7 is a diagram schematically illustrating an example of an object used in a game provided by a game server of an embodiment. [Figure 8] FIG. 8 is a diagram schematically illustrating another example of an object used in a game provided by the game server of one embodiment. [Figure 9] FIG. 9 is a flowchart illustrating an example of the battle rules of a game provided by the game server of one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0012] An example of a game server, a lottery execution method, and a computer program according to an embodiment of the present invention will be described in detail below with reference to the drawings. Note that in the following description, configurations and elements that are the same as or similar to configurations that have already been described will be assigned the same reference numerals and descriptions thereof will be omitted.

[0013] FIG. 1 is a diagram illustrating an example of the configuration of a game system including a game server according to an embodiment. The game system of this embodiment is, for example, a system for operating and managing a game using a blockchain. Note that the game system is not limited to a system for operating and managing a blockchain game, but can also be applied to a system for managing and operating a game distributed from a game server 110.

[0014] The game system includes a game server 110 and an NFT server 120, and can be communicatively connected to a CEX (Centralized Exchange) 300, a DEX (Decentralized Exchange) 400, a marketplace 500, and one or more user terminals 200 via a network.

[0015] CEX300 is a cryptocurrency exchange operated by a specific company. In this embodiment, CEX300 transfers cryptocurrency information to the game system 100 in response to a request from the game system 100. Examples of CEX300 include Coincheck (registered trademark), bitFlyer (registered trademark), and BITPOINT (registered trademark). CEX300 is also capable of conducting cryptocurrency transactions with the user terminal 200, and can transfer cryptocurrency information to the user terminal 200 in response to a request from the user terminal 200.

[0016] DEX400 is a cryptocurrency exchange that does not have an operating company and that automatically realizes the exchange of cryptocurrencies and tokens using smart contracts. In this embodiment, DEX400 transfers cryptocurrency information to the game system 100 in response to a request from the game system 100. Examples of DEX400 include Uniswap (registered trademark) and PancakeSwap (registered trademark). In addition, DEX400 is also capable of conducting cryptocurrency transactions with the user terminal 200, and can transfer cryptocurrency and token information to the user terminal 200 in response to a request from the user terminal 200.

[0017] The user terminal 200, for example, comprises at least one processor and a memory in which a program executed by the processor is recorded, and is configured to be able to realize various functions by software or a combination of software and hardware.

[0018] The user terminal 200 is an electronic device such as a computer, and may be, for example, a television receiver (including an Internet television), a PC (Personal Computer), a mobile terminal (for example, a tablet, a smartphone, a laptop, a feature phone, a digital music player, an e-book reader, a smartwatch, etc.), a game device (a home game console, a portable game console), a VR (Virtual Reality) terminal, an AR (Augmented Reality) terminal, etc., but is not limited to these. Note that the number of user terminals 200 connected to the network may be zero, or may increase or decrease at any time.

[0019] In this embodiment, the user terminal 200 is, for example, a smartphone, and is able to run a blockchain game supplied from the game system 100 by downloading and installing a blockchain-based game application provided by the game server 110. Alternatively, the user terminal 200 may be, for example, a smartphone, and be able to run a blockchain game supplied from the game system 100 on a browser without downloading and installing a blockchain-based game application provided by the game server 110.

[0020] The NFT server 120 is a server that converts images (still images and videos), audio, and other types of digital files into NFTs (non-fungible tokens) by recording them on a blockchain (distributed ledger) as unique, non-fungible data units (blocks). For example, the NFT server 120 can convert in-game assets in the game server 110 into NFTs upon request and provide the in-game assets converted into NFTs to users.

[0021] The marketplace 500 is an online platform where digital assets utilizing NFTs can be bought, sold, and exchanged. A user operating the user terminal 200 can convert in-game assets owned by the game system 100 into NFTs through the process described below, and sell the NFT-converted in-game assets on the marketplace 500. Users can also purchase digital assets being sold on the marketplace 500. Examples of the marketplace 500 include TofuNFT (registered trademark) and OpenSea (registered trademark).

[0022] The game server 110 is a server that provides a game using a blockchain (a blockchain game, hereinafter sometimes simply referred to as a game) that can be played on the user terminal 200. The game server 110 has a function to sell game media (e.g., in-game currency such as paid stones) using crypto assets, and a function to sell game media (e.g., in-game currency) using legal tender (e.g., Japanese yen, dollars, etc.).

[0023] The game server 110 manages the value of game media (in-game assets such as tickets and items, and in-game currency) purchased by users using crypto assets. Note that the game media in this embodiment include at least in-game assets (for example, characters, items usable in the game, cards (objects) corresponding to characters, weapons and equipment that can be worn by characters, cards for activating character skills, etc.) and in-game currency (for example, paid stones, unpaid stones, etc.).

[0024] In this embodiment, the game server 110 can handle multiple types of tokens as crypto assets. In a blockchain game provided by the game server 110, for example, the game content that can be purchased with one of the multiple types of crypto assets may be different from the game content that can be purchased with other of the multiple types of crypto assets, and some of the multiple types of crypto assets may be usable for all purposes, while others may be usable only for specific purposes.

[0025] Next, an example of the configuration of the game server 110 and the NFT server 120 shown in FIG. 1 will be described. FIG. 2 is a block diagram schematically illustrating an example of the configuration of a game system according to an embodiment.

[0026] The NFT server 120, for example, comprises at least one control unit (processor) 121 and a memory in which a program executed by the control unit 121 is recorded, and is configured to be able to realize various functions by software or a combination of software and hardware. The NFT server 120 may be configured as a single server device, or may include multiple server devices and function as a single virtual server device.

[0027] The NFT server 120 includes a control unit 121, a memory unit 123, an input unit 124, an output unit 125, and a communication unit 126. The input unit 124 is operated by the administrator of the NFT server 120 and may include a user interface such as a mouse or keyboard for inputting various information (for example, information to change the numerical values ​​of various settings of the NFT server 120), as well as various sensors such as a microphone or touch panel.

[0028] The output unit 125 includes, for example, a monitor that visually presents information to the administrator of the NFT server 120. The output unit 125 may also include audio output means, such as a speaker, that audibly supplies information to the administrator of the NFT server 120.

[0029] The communication unit 126 can transmit information received from outside to the configuration within the NFT server 120, and can also transmit information received from the configuration within the NFT server 120 to the outside. The communication unit 126 can be connected to the game server 110, the user terminal 200, etc., so as to be able to communicate with them via a network such as the Internet.

[0030] The storage unit (including memory) 123 of the NFT server 120 comprises, for example, a main storage unit and an auxiliary storage unit. The main storage unit may include, for example, a ROM (read-only memory) and a RAM (random-access memory). The ROM is a non-volatile memory used exclusively for reading data, and can store data and various setting values ​​used by the processor when performing various processes. The RAM can also be used as a so-called work area for temporarily storing data when the processor performs various processes. The main storage unit in this embodiment is, for example, a RAM.

[0031] The secondary storage unit of the NFT server 120 is a non-transitory computer-readable storage medium of a processor-based computer. The secondary storage unit is, for example, an EEPROM (registered trademark) (electric erasable programmable read-only memory), a HDD (hard disk drive), or an SSD (solid state drive).

[0032] The auxiliary storage unit of the NFT server 120 can store, for example, data used by the processor when performing various processes, programs, data generated by processing by the processor, various setting values, etc. The auxiliary storage unit may also store information necessary for personal authentication during payment processing performed by the processor, and personal information such as credit card numbers and account information (legal tender account information, cryptocurrency account information, etc.). For example, information used for personal authentication and personal account information may be stored in an external database accessible by the NFT server 120.

[0033] The control unit 121 of the NFT server 120 is typically a CPU (Central Processing Unit) and / or GPU (Graphics Processing Unit), but may also be a microcomputer, FPGA (Field Programmable Gate Array), DSP (Digital Signal Processor), etc. The control unit 121 of the NFT server 120 can realize various functions of the NFT server 120 by executing programs such as system software, application software, or firmware stored in the memory unit 123.

[0034] The processor of the NFT server 120 includes an NFT processing unit 122. The NFT processing unit 122 acquires an NFT request signal from, for example, the control unit 111 included in the game server 110. The NFT processing unit 122 uses the digital data of the in-game assets, information about the creator of the digital data, and information about the owner of the digital data, which are included in the NFT request signal from the game server 110, to generate a distributed ledger (blockchain) in which the in-game assets to be converted into NFTs are treated as unique, non-fungible data units. Note that the NFT processing of the in-game assets by the NFT processing unit 122 can use existing methods.

[0035] After the NFT conversion process is complete, the NFT processing unit 122 outputs an NFT conversion process completion notification to the control unit 111 via the network. The NFT conversion process completion notification may include information such as information about the creator of the NFT, information about the owner of the NFT, identification information (identifier) ​​of the in-game asset that has been NFTed, and the date and time when the NFT conversion was completed. The NFT processing unit 122 transmits data about the in-game asset for which the NFT conversion process has been completed to the user terminal 200 (or to the user terminal 200 via the game server 110) via the network.

[0036] The game server 110 includes, for example, at least one processor and a memory in which a program executed by the processor is recorded, and is configured to be able to realize various functions by software or a combination of software and hardware. The game server 110 may include multiple server devices and function as a single virtual server device.

[0037] In this embodiment, the game server 110 includes a control unit 111, a memory unit 113, an input unit 114, an output unit 115, and a communication unit 116. The control unit 111, the memory unit 113, the input unit 114, the output unit 115, and the communication unit 116 are connected to each other via a bus communication line and can transmit and receive data between them. Note that the control unit 111, the memory unit 113, the input unit 114, the output unit 115, and the communication unit 116 may be configured to transmit and receive data between them via wireless communication or the like.

[0038] The input unit 114 is operated by an administrator of the game server 110 and may include a user interface such as a mouse or keyboard for inputting various information (for example, information for changing the numerical values ​​of various settings of the game server 110), and various sensors such as a microphone or touch panel.

[0039] The output unit 115 includes, for example, a monitor that visually presents information to the administrator of the game server 110. The output unit 115 may also include audio output means, such as a speaker, that audibly supplies information to the administrator of the game server 110.

[0040] The communication unit 116 can transmit information received from the outside to the components within the game server 110, and can also transmit information received from the components within the game server 110 to the outside. The communication unit 116 is communicatively connected to the NFT server 120, the user terminal 200, the CEX 300, the DEX 400, the marketplace 500, and the NFT server 120 via a network such as the Internet.

[0041] The storage unit 113 includes, for example, a main storage unit and an auxiliary storage unit. The main storage unit may include, for example, a ROM (read-only memory) and a RAM (random-access memory). The ROM is a non-volatile memory used exclusively for reading data, and can store data and various setting values ​​used by the control unit 111 when performing various processes. The RAM may be used as a so-called work area for temporarily storing data when the control unit 111 performs various processes. The main storage unit in this embodiment is, for example, a RAM, and is used as a memory.

[0042] The auxiliary storage unit is a non-transitory computer-readable storage medium of a computer centered around the control unit 111. The auxiliary storage unit is, for example, an EEPROM (registered trademark) (electric erasable programmable read-only memory), an HDD (hard disk drive), or an SSD (solid state drive).

[0043] The auxiliary storage unit can store data and programs used by the control unit 111 when it performs various processes, data generated by the processes in the control unit 111, various setting values, and the like. The auxiliary storage unit stores various information such as user information 31, object information 32, field information 33, history information 34, and game rules.

[0044] 3 is a diagram showing an example of object information stored in a game server according to an embodiment. In this specification, an object is an in-game asset corresponding to a character, item, skill, magic, etc. used in battles in a game provided by the game server 110, and corresponds to, for example, a card used in battles in a card game. Note that objects used in battles are not limited to cards, and may be any medium corresponding to a character, item, skill, magic, etc.

[0045] The object information 32 includes information on multiple forms (including normal and descended states) of characters, items, skills, magic, etc. corresponding to each of multiple objects (cards) used in the game, and is stored, for example, in a table and stored in an auxiliary storage unit. For example, for each object corresponding to a character, item, skill, magic, etc. used in battles in a card game, the object information 32 may include parameters such as object identification information (or identification information of in-game assets such as the corresponding character or item), name, cost, attribute (e.g., light, dark, etc.), weapon equipment value (e.g., weapon, shield, decoration), HP (hit points), LV (level), MP (magic points), attack type, attack power, attack range, defense power (DEF), speed (SPEED), defensive characteristics (e.g., "strong against physical attacks" or "weak against magic"), special ability (skill), sphere slot (equipment information for an item that provides a positive correction to the ability of a character or item), and these parameters in the descended state. Furthermore, the object information 32 may include image data of the object (card) and image data of characters, items, skills, magic, and the like associated with the object.

[0046] For example, in the object information 32 shown in FIG. 3, for a character with object identification information (No.) "10001," name "A," and attribute "light," the following information is stored: normal cost "1," normal HP "1," normal attack type "physical," normal attack power "1," normal attack range "short range," normal speed "12," and normal special ability "When registered: 1 draw."

[0047] Also, for example, in the object information 32 shown in Figure 3, for a character with object identification information (No.) "10001", name "A", and attribute "light", the following information is stored: cost at time of descent "2", HP at time of descent "2", attack type at time of descent "physical", attack power at time of descent "2", attack range at time of descent "short range", speed at time of descent "12", and special ability at time of descent "at time of registration: 2 draw".

[0048] FIG. 4 is a diagram illustrating an example of field information stored in a game server according to an embodiment. Field information 33 is information about the field (battlefield) where battles take place in a card game, and is stored in the auxiliary storage unit as a table such as that shown in FIG. 4. The battlefield is where objects such as cards are placed when a user (player character) plays the game. Field information 33 may include information such as field identification information, field name, field effect, and field image.

[0049] The auxiliary memory unit also stores user information 31, such as game history information of the user playing the game (or the player character who acts in the game field in response to the user's operations to progress through the game), information on in-game assets owned by the user (including information on game media owned by the user (items, cards, in-game currency, etc.)), user level, preferential level, various points awarded to the user, and a list of multiple cards (objects) included in a deck constructed by the user, in association with the user identification information (user identifier or player character identifier) ​​of the user playing the game.

[0050] The historical information may include, for example, billing history information, battle history information, login history information, lottery (gacha) history information, user level (or player character level) history information, user (or player character) strengthening and development history information, character level history information, character skill history information, character equipped item history information, character strengthening and development history information, item purchase history information, conversion of in-game assets to NFTs, ranking history information, and usage history information for game media (paid stones, other in-game currency, etc.) and in-game assets (e.g., characters, items, etc.), each of which is associated with a user identifier and a corresponding date and time.

[0051] The information on the user's in-game assets includes, for example, the identifier of the user's player character, the identifier of a character owned by the user, the identifier of an item owned by the user, and the identifier of an object (card) owned by the user. The identifier of the player character, the character identifier, the item identifier, and the object identifier are associated with the user identifier and stored in the storage unit 113.

[0052] The user's in-game currency information includes information on the paid stones and free stones currently owned by the user, as well as information on the user's paid stone purchase history. The user's in-game currency information may include, for example, the number of paid stones purchased by the user, the number of free stones owned by the user, the date and time of the paid stone purchase, and the cryptocurrency price of the paid stones at the date and time of the paid stone purchase. The number of paid stones purchased by the user (number of paid stones purchased), the date and time of the paid stone purchase, and the cryptocurrency price of one paid stone at the date and time of the paid stone purchase are associated with the user identifier.

[0053] In the game server 110 of this embodiment, information on multiple types of paid stones used in the game is stored by type in the storage unit 113. The multiple types of paid stones may be categorized, for example, according to the means by which the user acquired the paid stones. Furthermore, each of the multiple types of paid stones may be assigned a use purpose. For example, paid stones purchased with crypto assets other than the first crypto asset or legal tender may be usable for participating in lotteries (gacha), and paid stones purchased with the first crypto asset may be usable for developing, strengthening, and refining in-game assets, as well as for participating in lotteries (gacha). Furthermore, a specific lottery (gacha) may be configured to be executable only with specific paid stones.

[0054] The auxiliary memory unit may also store the latest selling price (unit price) of game media such as in-game currency in crypto assets, the latest selling price (unit price) of game media such as in-game currency in legal tender, and the latest value of crypto assets relative to legal tender.

[0055] The storage unit 113 may be built into the game server 110 or may be externally attached to the game server 110. Furthermore, the data stored in the storage unit 113 may be shared among the game server 110, the NFT server 120, and other servers (such as servers that perform payment processing).

[0056] The control unit 111 is typically a CPU (Central Processing Unit) and / or a GPU (Graphics Processing Unit), but may also be a microcomputer, an FPGA (Field Programmable Gate Array), a DSP (Digital Signal Processor), etc. The control unit 111 can realize various functions of the game server 110 by executing programs such as system software, application software, or firmware stored in the storage unit 113.

[0057] The control unit 111 includes a battle processing unit 10, an in-game asset management unit 13, a user management unit 14, and a display processing unit 15. The display processing unit 15 generates display data for updating the display of the display of the user terminal 200 and supplies the display data to the user terminal 200, for example, as the game provided by the game server 110 progresses.

[0058] The user management unit 14 manages information about users and player characters who play games provided by the game server 110, such as authenticating users and user terminals 200, strengthening, training, and managing the levels of users (or player characters), and managing user payment information.

[0059] The user management unit 14 has a function for managing user information (user information 31) obtained by a user playing a game (user information management function). The user management unit 14 has a function for managing information obtained by a user playing a game, and for example, when initial settings for a game are performed on the user terminal 200 owned by the user, the user management unit 14 generates a user identifier and starts managing the play information of the user.

[0060] For example, when a user plays a game and is charged, the user information management function records the user identifier, the charged amount, and the charging date and time in the storage unit 113 in association with each other. In addition, for example, when a user logs in, the user information management function associates the user identifier with the login date and time and records them in the memory unit 113, and when the user logs out, it associates the user identifier with the logout date and time and records them in the memory unit 113.

[0061] In addition, the user information management function, for example, when a user's user level increases by playing a game, associates the user's identifier, the user level, and the date and time when the user level increased, and records them in the memory unit 113.

[0062] Furthermore, for example, when a user purchases an item by playing a game, the user information management function records the user identifier, the item identifier, and the date and time of the item purchase in association with each other in the storage unit 113.

[0063] Furthermore, the user information management function, for example, associates information about a user's ranking as a result of the user playing a game with the user identifier and records this information in the storage unit 113. For example, the ranking information may include information such as the user's ranking when participating in an in-game tournament, and the identifiers of in-game assets (player characters, characters, items, etc.) used by the user in the tournament.

[0064] For example, when a user plays a game with a player character and the level of the player character increases, the user information management function associates the user identifier, the player character identifier, the player character level, and the date and time when the player character level increased, and records them in the memory unit 113.

[0065] For example, when a user acquires a player character or strengthens or develops the character, the user information management function records in memory unit 113 the user's identifier, the player character's identifier, the acquisition date and time, identification information for the strengthening or development performed, and the date and time when the strengthening or development was performed, in association with each other.

[0066] The in-game asset management unit 13, for example, manages in-game assets such as characters, items, and objects (cards) owned by users (that can be used in battles) in the game provided by the game server 110, manages the strengthening and leveling of in-game assets, and manages the conversion of in-game assets into NFTs.

[0067] The in-game asset management unit 13 has a function of managing information on in-game assets used in the game provided by the game server 110 (in-game asset information management function). For example, when a user acquires a character (a character corresponding to an object) by playing a game or when the character is strengthened or developed, the in-game asset information management function records in memory unit 113 the user's identifier, the character's identifier, the acquisition date and time, identification information for the strengthening or development performed, and the date and time the strengthening or development was performed, in association with each other.

[0068] Furthermore, for example, when a character's level increases as a result of the user playing the game, the in-game asset information management function associates the user's identifier, the character's identifier, the increased level, and the date and time when the level increased in the storage unit 113. For example, the in-game asset management function may associate an awakening ID, which is an identifier indicating that the in-game character's level has reached a certain level, or that the in-game character's level has exceeded the limit of its ability value and become capable of being strengthened (awakened) after reaching a certain level, with the character's identification information and the date and time when the character awakened in the storage unit 113.

[0069] Furthermore, for example, when a user plays a game and pits characters (characters corresponding to objects) against each other, the in-game asset information management function associates the user identifier, the character identifier, the battle identifier, the date and time of the battle, and the battle result, and records them in the storage unit 113. The in-game asset information management function may, for example, manage the experience points and the like of the characters used by the user in the battle, and strengthen or level up the characters according to the experience points.

[0070] The in-game asset management function can set a list of cards (objects) that a user can own according to the user's level and experience points. The in-game asset management function may unlock the card list for a user who meets a predetermined condition (e.g., a predetermined level, experience points, amount of money charged, etc.), making the card list available for the user to own (or use).

[0071] Furthermore, the in-game asset management function can, based on a user's operation, register one or more cards corresponding to characters owned by the user (that are in a usable state) into a deck (a card set combining multiple cards) as cards to be used in battle. In response to a user's operation to select a card to register in the deck, the in-game asset management function may, for example, associate the identifier of the selected card (or character) and a flag indicating that it has been registered in the deck with the user identifier and record them in the storage unit 113.

[0072] The in-game asset management function may allow each user to create multiple decks. Furthermore, if a user can select a player to play a card game from among multiple player characters, multiple decks may be created for each player character. A player character's deck may be configured to allow registration of only cards of the type, such as attributes, that the player character can use.

[0073] An upper limit may be set for the number of cards (objects) that can be registered in one deck. The upper limit for the number of cards (objects) that can be registered in one deck may be set for each type of attribute, etc., and the upper limit for the number that can be registered may be set for each name of the corresponding character or item. In this embodiment, the user can register up to 20 cards in a deck, and up to two cards of the same character (same name) can be registered in a deck.

[0074] Furthermore, for example, when a user equips a character with an item by playing a game, the in-game asset information management function associates the user identifier, the character identifier, the item identifier, and the date and time the item was equipped in the storage unit 113. For example, when a user equips a character owned by the user with an item such as exclusive equipment for the character, the in-game asset information management function may further associate the user identifier, the character identifier, the item identifier, and the date and time the item was equipped in the storage unit 113 with an exclusive equipment ID.

[0075] Furthermore, for example, when a user draws a lottery (gacha), the in-game asset information management function associates the user's identifier, the date and time the gacha was drawn, and the result of the gacha (for example, the identifier of the in-game asset (including game content) obtained through the gacha), and records them in the storage unit 113. For example, the identifier of the in-game asset may include a switch flag that switches whether the user can use the in-game asset in the game. The in-game asset information management function may switch the switch flag to switch between a state in which the in-game asset is usable by the user in the game and a state in which it is unusable. An in-game asset that is unusable may be treated as not owned by the user on the game play screen.

[0076] Furthermore, for example, when a user converts in-game assets into NFTs by playing a game, the in-game asset information management function associates the user identifier, the identifier of the NFTed in-game assets, the date and time when the NFT conversion was performed (for example, the date and time when the NFT conversion was completed or the date and time when the NFT conversion process completion notification was received), and the NFT identifier, and records them in memory unit 113.

[0077] In addition, when the in-game asset information management function receives a request (return request signal) from a user to make in-game assets that have already completed the NFT process usable in the game, it associates the user identifier, the identifier of the in-game assets that have been NFTed, the date and time the NFT was made usable in the game, and the NFT identifier, and records them in the memory unit 113.

[0078] The in-game asset management unit 13 may have a conversion function. The conversion function has a function of making the in-game asset associated with the user identifier convertible to an NFT when, for example, the history information associated with the user identifier satisfies a predetermined condition (NFT conversion condition).

[0079] The conversion function receives a conversion request signal from the user terminal 200 via the communication unit 116, requesting the conversion of in-game assets into NFTs. The conversion request signal includes the user's user identifier and the identifier of the in-game assets that the user wishes to convert into NFTs. In response to the conversion request signal acquired from the user terminal 200 via the communication unit 116, the conversion function acquires history information associated with the corresponding user identifier from the storage unit 113. The conversion function may enable the conversion of the in-game assets associated with the user identifier into NFTs when the acquired history information satisfies a predetermined condition. Note that the conversion function may wait for conversion request information from the user terminal 200 after enabling the conversion of the in-game assets associated with the user identifier into NFTs when the history information associated with the user identifier in the storage unit 113 satisfies a predetermined condition.

[0080] When the conversion function receives a conversion request signal and the historical information associated with the user identifier satisfies predetermined conditions, it makes the in-game assets associated with the user identifier convertible to NFTs and generates an NFT conversion request signal that requests the NFT server to convert the in-game assets into NFTs.

[0081] The NFT request signal includes at least digital data such as image data corresponding to the in-game assets to be NFTed, information about the creator of the in-game assets to be NFTed, and information about the owner of the in-game assets to be NFTed. Note that the information about the creator and the information about the owner of the in-game assets may be the same information, and the information about the creator and the information about the owner of the in-game assets may include a user identifier for the game. The conversion function sends an NFT request signal to the NFT server 120.

[0082] When the conversion function receives an NFT process completion notification from the NFT server (information about the creator of the NFT, information about the owner of the NFT, identification information for the in-game assets that have been NFTed, and the date and time when the NFT process was completed), it puts the in-game assets that have been NFTed and stored in memory unit 113 in association with the user identifier into a state where they are not owned by the user in the game. When the conversion function receives an NFT process completion notification from the NFT server, it may switch a switch flag for the in-game assets that have been NFTed, making the in-game assets unusable by the user in the game.

[0083] The battle processing unit 10 has a function of processing a battle between multiple users (player characters) using cards (objects) such as characters in a game provided by the game server 110. In this embodiment, an example will be described in which the game server 110 provides a game in which victory or defeat is determined by the results of a battle between players over multiple turns.

[0084] The battle processing unit 10 includes a parameter management unit 11 and a turn execution unit 12. The turn execution unit 12 matches users who wish to battle with each other in response to user operations. When a user wishes to battle, the turn execution unit 12 may allow the user to select a player to play the card game with from multiple player characters owned by the user. The turn execution unit 12 may, for example, match opponents from among users who satisfy predetermined conditions, match player characters who face each other on the game field (play environment) as opponents, match opponents from among users participating in a game event, match users with similar levels or fighting power as opponents, or match opponents based on past battle results or experience points.

[0085] Furthermore, the turn execution unit 12 may match a virtual user (NPC: Non-Player Character) operated by a computer (CPU) as an opponent. In a match against an NPC, the user does not need to worry about making the opponent wait, and can proceed while checking the operation, which lowers the hurdle for a user who has been away from the game to return to the game.

[0086] The turn execution unit 12 may present information about the opponent to the user via the display processing unit 15, and complete the matching by confirming whether or not the user intends to battle. When the user matching is complete, the turn execution unit 12 sets up a deck of cards for each user based on information about cards (objects) registered in the deck by the matched user (or player character). The turn execution unit 12 shuffles the multiple cards registered in the deck and sets up the deck of cards in a face-down state (a state in which the characters, parameters, etc. of the cards are not visible to the user) stacked vertically on the game field. The turn execution unit 12, for example, associates a user identifier, the order of the cards in the deck, and the identifiers of the cards in the storage unit 113.

[0087] Furthermore, as the game progresses, the turn execution unit 12 may associate identifiers (such as flags) that distinguish between cards that are face down as a deck to the user, cards that become the user's hand after being dealt (drawn), cards that the user did not select (discard) as part of their hand after being dealt, cards that the user played from their hand onto the battlefield, and cards that have disappeared in the battle (HP has reached zero) with the identifiers of the cards, and record these in the storage unit 113. The turn execution unit 12 associates the identifiers of the cards played onto the battlefield with identifiers that identify the positions of the cards on the battlefield, and records these in the storage unit 113.

[0088] In the game provided by the game server 110 of this embodiment, each battle includes multiple turns. In this embodiment, each battle includes up to five turns. In the game provided by the game server 110 of this embodiment, each turn includes a main phase and a battle phase, and multiple users battling in each turn progress through the game simultaneously.

[0089] The main phase of each turn precedes the battle phase and is the stage where preparations for the battle of each turn are made. In the main phase, for example, the battlefield is selected, cards are dealt (drawn) from the deck, and characters from the hand are summoned to the battlefield. The battle phase of each turn includes multiple attack phases, during which each of the multiple characters summoned to the battlefield attacks.

[0090] When a turn in a battle begins, the turn execution unit 12 first performs processing of the main phase. In the main phase, the turn execution unit 12 first selects a battlefield to be applied to the turn that is about to begin. For example, the turn execution unit 12 probabilistically selects and applies one of a plurality of preset battlefields for each of a plurality of turns.

[0091] For example, the turn execution unit 12 may select and apply a battlefield that does not affect (does not include) any character in the first turn. From the second turn to the fifth turn, the turn execution unit 12 may randomly change the terrain (field) on which the battle takes place and apply a battlefield that affects each character. The effect of the battlefield may be an advantageous effect targeted at a specific character, such as increasing the HP of all characters on the battlefield by 3 or increasing the attack power of a character with a red attribute by 5. The turn execution unit 12 may apply a battlefield that has a wider range of effect with each passing turn.

[0092] When the battlefield is set for each turn, the turn execution unit 12 sets the cards played on the battlefield in response to a user operation. When the cards played on the battlefield are confirmed, the turn execution unit 12 ends the main phase and starts processing the battle phase.

[0093] If a character corresponding to a card on the battlefield has a special ability that is activated when summoned or before the start of a battle, the turn execution unit 12 causes the object's special abilities to be exerted in sequence (in order of speed), and all of them are activated before the character attacks. Note that special abilities that are activated after the battle has begun (such as the attack phase of a character with a special ability) or before the end of the turn (such as after all attack phases have ended) will not be activated at this time, but will be activated at the appropriate time depending on the progress of the turn.

[0094] In the battle phase, the turn execution unit 12 performs character attacks for each attack phase according to the placement positions of cards on the field and the parameters of the characters corresponding to the cards. In each turn, the turn execution unit 12 selects a character to attack in each attack phase based on parameters related to the attack order in the battle for the characters corresponding to the multiple cards placed on the battlefield, and executes the attack of the selected character. In this embodiment, the parameter related to the attack order is speed (SPEED), and the turn execution unit 12 executes attacks of objects within a predetermined attack range in descending order of speed value. Therefore, the battle proceeds automatically by the computer without the user having to perform an operation to select a character to attack. In principle, a character's attack target is the opposing character closest to the attacking character. However, the character's attack target may change depending on the character's special abilities, etc.

[0095] Furthermore, when the speed values ​​of characters corresponding to multiple cards played on the battlefield are equal (the parameters are the same), the turn execution unit 12 may probabilistically select a character to attack from among multiple characters having the same speed value and execute a battle using the selected character, or may determine the order in which attacks will be made by referring to parameters other than the speed of multiple characters having the same speed value.

[0096] By setting the attack order for characters with the same parameters probabilistically, users who are at a disadvantage can hope to turn the tables. As a result, users can enjoy the game to the end without having to surrender midway through the battle.

[0097] The turn execution unit 12 ends a turn when all characters sent to the battlefield by any of the competing users (or player characters) are annihilated (when the HP of all characters reaches zero). Furthermore, even during a battle, the turn execution unit 12 ends a turn when the HP of the user or player character reaches zero.

[0098] The turn execution unit 12 ends the match when the HP of one of the competing users (player characters) reaches zero or when five turns are completed, and the user with the greater HP at the end of the match wins.

[0099] In accordance with the battle processing of the turn execution unit 12, the parameter management unit 11 updates parameters corresponding to characters (cards) on the battlefield, and for characters whose parameters have fallen below a predetermined threshold (for example, zero) in the first turn, sets the parameters for the second turn following the first turn to their initial values ​​(values ​​at the start of a battle including multiple turns). For example, for a character whose HP has fallen to zero in the first turn, the parameter management unit 11 sets parameters such as HP to their initial values ​​at the start of the second turn following the first turn, returning them to a state where they have not received any damage.

[0100] In response to this, parameter management unit 11 does not set the parameters of a character whose parameters did not fall below a predetermined threshold value in the first turn (the parameters exceeded the predetermined threshold value at the end of the first turn) to their initial values ​​in the second turn following the first turn, but leaves them as they were at the end of the first turn. For example, parameter management unit 11 does not set the parameters such as HP of a character whose HP did not become zero in the first turn to their initial values ​​at the start of the second turn following the first turn, but leaves them in the damaged state.

[0101] By setting the card parameters as described above, a user's character that was at a disadvantage at the end of the previous turn can start the battle in an advantageous position in the next turn, allowing the users battling to enjoy a close battle without feeling like they are at a disadvantage, and to enjoy the game to the end.

[0102] Furthermore, the parameter management unit 11 sets user parameters for the user (or player character) playing the game for each turn, and consumes the user's user parameters (energy value) according to the parameters (energy value) of the card placed on the battlefield by the user's operation. For example, the parameter management unit 11 sets the initial energy value for each of multiple turns so that it increases as the game progresses. As a result, the energy available to the user increases with each turn, which allows for a wider range in the number and strength of characters that can be summoned to the battlefield, allowing for a more dynamic game development in later turns. Therefore, the user can enjoy the battle until the last turn without having to surrender midway through.

[0103] Furthermore, the parameter management unit 11 may increase (by about 2) the energy value that the player character at a disadvantage can obtain in the next turn when the difference in HP between the player character and the opponent player character is a predetermined number (about 20). Note that the parameter management unit 11 may increase the SPEED of the character on the battlefield of the player character at a disadvantage in the next turn by a predetermined number, or may increase the number of battle crystals acquired by a predetermined number, for the player character at a disadvantage when the difference in HP between the player character and the opponent player character is a predetermined number (about 20). The turn execution unit 12 may increase the number of cards that the player character at a disadvantage can draw by a predetermined number, for the player character at a disadvantage when the difference in HP between the player character and the opponent player character is a predetermined number (about 20).

[0104] In either case, the possibility of a player character at a disadvantage being able to turn the tables is increased, and the user can enjoy the battle right up to the last turn without having to surrender midway through the battle.

[0105] Furthermore, the parameter management unit 11 sets the parameters of cards placed on the battlefield according to the effect of the battlefield applied to that turn by the turn execution unit 12. In the game provided by the game server 110 of this embodiment, the battlefield is forcibly changed randomly each turn, which means that a character that was dominant on the battlefield applied in the previous turn may no longer be dominant on the battlefield applied in the next turn. Conversely, a character that was at a disadvantage in the previous turn may become dominant in the next turn. This means that even if the game ends in a state of disadvantage, the user can hope for a comeback in the next turn, allowing them to enjoy the game to the end.

[0106] The parameter management unit 11 reduces the HP of the opponent user (player character) by the sum of the costs or the attack power of characters (characters remaining on the battlefield) whose HP is 1 or more at the end of the turn. The parameter management unit 11 may set the user's HP to a predetermined initial value (for example, 40) at the start of the first turn.

[0107] The parameter management unit 11 manages parameters for strengthening the player character (battle crystal) and parameters for the strengthened state of the character in battle. When a battle involving multiple turns involving multiple player characters begins, the parameter management unit 11 sets the strengthening parameters (battle crystals) possessed by the player characters to their initial values ​​(zero). When a player character attacks, the parameter management unit 11 increments the player character's battle crystal by one. Note that an upper limit may be set for the value of the battle crystal. In this embodiment, the upper limit for the battle crystals in each battle is five.

[0108] In each battle turn, the user can select a character on the battlefield during their own character's attack phase and put the selected character into a Brave state (strengthened state) by consuming a predetermined number of Battle Crystals. Note that the user can also further strengthen a character in the Descended state by consuming Battle Crystals to put the character into a Brave state.

[0109] When the parameter management unit 11 receives the identifier of the selected character and a command to put the character into a Brave state from the user terminal 200, it consumes a predetermined value (e.g., 5) from the player character's Battle Crystal to strengthen the parameters of the selected character.

[0110] If there is a character in a brave state on the battlefield, the turn execution unit 12 ignores the SPEED values ​​of the characters on the battlefield and first executes an attack by the character in the brave state among all the characters.

[0111] In response to an attack by a character in a Brave state, parameter management unit 11 inflicts damage to the HP of the attacked character equal to the attack power value of the character multiplied by a predetermined coefficient greater than 1 (for example, 1.5) (fractions are rounded down). At this time, parameter management unit 11 may ignore the defensive power of the attacked character.

[0112] For example, when a character in the descended state becomes brave, parameter management unit 11 ignores the defensive power of the attacked character when attacking and inflicts damage to the HP of the attacked character equal to a value (rounded down) obtained by multiplying the attack power value of the character in the descended state by a predetermined coefficient greater than 1 (for example, 2). Here, when a character in the descended state becomes brave, parameter management unit 11 may inflict damage to the opponent character equal to a value obtained by multiplying the attack power value by a larger coefficient than when a character in the normal state becomes brave.

[0113] After a battle including multiple turns has ended, the parameter management unit 11 may strengthen the player character or characters that won the battle by increasing their parameters.

[0114] As described above, in the game provided by the game server 110 of this embodiment, it is possible to increase the possibility that a user (player character) who is at a disadvantage in the battle situation can turn the situation around in the next turn, thereby improving the interest of the game. As a result, users will play the match to the end without dropping out midway, and more users will be able to enjoy the match to the end. That is, according to this embodiment, it is possible to provide a game server, a game processing method, and a computer program for a highly entertaining game that includes multiple battles.

[0115] Next, an example of rules will be described along with the progress of the game provided by the game server 110. 5 is a flowchart illustrating an example of the progression of a game provided by a game server according to an embodiment. Here, an example is described in which a battle involving multiple turns is carried out by multiple player characters.

[0116] When the conditions for starting a battle are met, the turn execution unit 12 matches the player characters who will be the opponents (step SA1). At this time, the turn execution unit 12 may present information on candidate opponents to the user via the display processing unit 15, allowing the user to select an opponent. The battle is fought between multiple player characters, and may be, for example, a one-on-one individual battle or a multiple-on-multiple team battle. When the turn execution unit 12 confirms with both users that they intend to fight, it decides on the opponents and ends the matching.

[0117] Once the opponent is determined, the turn execution unit 12 sets N=1 (step SA2) and performs processing of the main phase of the Nth turn. First, the turn execution unit 12 selects a battlefield for the Nth turn (step SA3). The turn execution unit 12 may randomly select one to be applied to the Nth turn from among all battlefields. The probability of a battlefield being applied to a turn may be set in advance, in which case the turn execution unit 12 selects a battlefield to be applied to the Nth turn according to the set probability. Alternatively, applicable turns of a battlefield may be set in advance, and the turn execution unit 12 may randomly (or according to probability) select one from multiple battlefields that can be applied to the Nth turn.

[0118] When a battlefield is selected, the turn execution unit 12 creates a deck of cards using information about cards registered in the decks of the competing player characters, and deals a predetermined number of cards to the player characters as their hands, starting from the top of the deck (step SA4). The number of cards dealt (drawn) from the deck to the player characters may correspond to the number of turns, or may be increased or decreased depending on the effect of the battlefield applied to the turn, or may be increased or decreased depending on the special ability of the summoned character. In this embodiment, for example, in the first turn, the turn execution unit 12 deals five cards from the deck to the player characters, and in each of the second to fifth turns, the turn execution unit 12 deals one card from the deck to the player characters.

[0119] If the deck of cards runs out before the end of several turns of the battle, the player character who has run out of cards may be declared defeated, or the player character who has run out of cards may continue the battle without drawing.

[0120] There may be an upper limit on the number of cards that a player character can hold in their hand. If the number of cards in their hand reaches the upper limit, the player character cannot add cards drawn (dealt) from the deck to their hand. Therefore, if a player character has the upper limit of cards in their hand, they can either not draw cards from the deck, draw cards from the deck and then discard (remove) either the drawn card or their hand, or discard (remove) a card from their hand and draw a new card from the deck. As a general rule, characters that have been removed by a player character or removed from the battlefield to increase their energy cannot be used in that match.

[0121] Next, the turn execution unit 12 sets a period (time limit) during which the player character places cards from their hand on the battlefield and selects a character to be summoned to the battlefield (step SA5). The card selection period may be different for each of the multiple turns. For example, the card selection period may be 30 seconds for the first and second turns, 40 seconds for the third and fourth turns, and 1 minute for the final (fifth) turn. This is because the first turn requires time to understand the initial hand, the third turn requires time to select cards obtained in the descending state, and the fifth turn requires time to select cards in the descending state and possesses a large amount of energy, and as the turns progress, more time is required for card selection.

[0122] During this period, the player character places cards of the selected character from their hand onto the battlefield. An upper limit may be set on the number of cards that the player character can place onto the battlefield. After the user selects the cards to be placed onto the battlefield and has placed the cards of the characters that the player character will summon to predetermined positions on the battlefield, the user can notify the game server 110 of the end by operating the user terminal 200, without waiting for the set period (time limit) to elapse.

[0123] The turn executing unit 12 waits until a predetermined period of time has elapsed unless it receives a notification that the user has finished selecting the character to be summoned (step SA6, No). The turn executing unit 12 completes the selection of the character to be summoned when the predetermined period of time has elapsed or when it receives a notification that the user has finished selecting the character to be summoned (step SA6, Yes). Note that if the predetermined period of time has elapsed before the user has finished the selection, the turn executing unit 12 may complete the selection of the character to be summoned by assuming that the character on the card placed on the battlefield by the user has been selected at the time the predetermined period of time has elapsed.

[0124] The turn execution unit 12 may be configured to allow the user to extend the period for selecting a character to summon by using game media such as paid stones. The turn execution unit 12 may be configured to allow the user to extend the period for selecting a character to summon by consuming paid stones, for example, for a player character competing against an NPC. If the opponent is an NPC, the user will not abandon the match midway even if the selection period is extended, and it is considered that the user who extended the period will continue the game without abandoning midway in order to avoid wasting the paid stones that they have consumed.

[0125] When the player character has completed selecting a card, the parameter management unit 11 subtracts the sum of the costs of one or more characters (cards) placed on the battlefield from the energy parameter of the player character, thereby completing the summoning of the character.

[0126] The energy of a player character is a parameter set for each turn. The parameter management unit 11 assigns a value to the player character at the start of each of multiple turns, with more energy being assigned to the player character in later turns. In a game provided by the game server 110 of this embodiment, for example, the parameter management unit 11 assigns 5 energy to the player character in the first turn, 6 energy in the second turn, 7 energy in the third turn, 8 energy in the fourth turn, and 10 energy in the fifth turn. In addition, in the second or subsequent turns, the parameter management unit 11 may assign a predetermined value (e.g., 1) of energy to the player character only in that turn by removing from the battlefield a character (card) that the player character inherited from the previous turn. The removed card may be treated as a discarded card and may be unavailable for use in subsequent battles.

[0127] Note that an upper limit is set on the number of cards that can be placed on the battlefield, and the player character can place cards at preset positions on the battlefield. The turn execution unit 12 associates, for example, the summoned character (card corresponding to the character), the position of the card, the battle identifier, the number of turns, and the user identifier, and records them in the storage unit 113.

[0128] 6 is a diagram illustrating an example of the rules of a game provided by a game server according to an embodiment. In FIG. 6, as an example, it is assumed that two player characters P1 and P2 corresponding to two users are engaged in a one-on-one battle.

[0129] Player character P1 can place one card from his hand into each of spaces C1 to C6 on the battlefield FLD. Of the spaces C1 to C6 on player character P1's side, spaces C1 to C3 are in the back row, and spaces C4 to C6 are in the front row. Player character P2 can place one card from his hand into each of spaces C7 to C12 on the battlefield FLD. Of the spaces C7 to C12 on player character P2's side, spaces C7 to C9 are in the front row, and spaces C10 to C12 are in the back row. The position of the space where a card is placed affects the range of the card's abilities, attack range, attack line, etc. in battle. Note that the card placement shown in Figure 6 is an example and is not limited to this.

[0130] Attack ranges include, for example, close range (attacks the nearest enemy character), long range (attacks the farthest enemy character), all (attacks all enemy characters, dealing the same amount of damage to all enemy characters), line (attacks the nearest enemy character, dealing the same amount of damage to all enemy characters in the same line), and piercing (attacks the nearest enemy character, dealing the same damage to the enemy character directly behind the attacked character).

[0131] For example, the order of distance from the card for spaces C7 and C10 is (1) space C4, (2) space C5, (3) space C1, (4) space C6, (5) space C2, and (6) space C3. For example, the order of distance from the card for spaces C8 and C11 is (1) space C5, (2) spaces C4 and C6, (3) space C2, and (4) space C1 and C3. For example, the order of distance from the card for spaces C9 and C12 is (1) space C6, (2) space C5, (3) space C3, (4) space C4, (5) space C2, and (6) space C1. If there is an opponent character at an equal distance within the attack range of the attacking character, the turn execution unit 12 may probabilistically select the opponent character to be attacked.

[0132] FIG. 7 is a diagram schematically illustrating an example of an object used in a game provided by a game server of an embodiment. 7 shows a schematic diagram of a card, which is an example of an object used in a game provided by the game server 110. The card displays the corresponding character's name "J", cost value "7", speed value "6", attribute "light", attack type "magic", attack range "all", special ability (skill), HP "8", DEF "8", ATK "4", etc.

[0133] FIG. 8 is a diagram schematically illustrating another example of an object used in a game provided by the game server of one embodiment. FIG. 8 shows a schematic example of another form of the card shown in FIG. 7. For example, the card shown in FIG. 7 is in a normal state (first form), and the card shown in FIG. 8 is a card in an advent state (second form) corresponding to the same character as the card shown in FIG. 7. The character corresponding to the advent state card is in an awakened state, in which at least some of the parameters in the normal state have been strengthened. The card of the advent state character "J", the corresponding character name "J", cost value "8", SPEED value "6", attribute "light", attack type "magic", attack range "all", special ability (skill), HP "12", DEF "10", ATK "6", etc. are displayed.

[0134] In this embodiment, characters corresponding to all cards have parameters in a normal state and parameters in a descended state. The turn execution unit 12 may switch the cards included in the deck from the normal state to the descended state in response to a predetermined condition being satisfied in a battle. For example, the turn execution unit 12 may set the cards included in the deck to the descended state in turns of a specific order (the third turn and the fifth turn).

[0135] In turns of a specific order (the third and fifth turns), the turn execution unit 12 distributes (draws) multiple cards (two cards in the third turn, four cards in the fifth turn) from the deck instead of the usual distribution (draw), and allows the player character to add one of the distributed cards to his / her hand in the descending state. Cards not selected by the player character for his / her hand are discarded and cannot be used in battle.

[0136] The turn execution unit 12 may treat a card that is included in the player character's hand in the descending state in a turn of a specific order as being in the descending state in subsequent turns, or may switch it to the normal state in the next turn.

[0137] Furthermore, in a game provided by the game server 110, a player character may be able to own both normal state cards and descended state cards. In the latter case, for example, an upper limit may be set on the number of descended state cards that can be included in a deck.

[0138] In this embodiment, any card in the game deck can be summoned in the descended state, creating a situation in which a player character who is at a disadvantage can aim for a sudden reversal. The possibility of a reversal makes users want to play the game until the end without giving up, and reduces the number of users who drop out mid-battle.

[0139] Next, the turn execution unit 12 executes the Nth turn of the match (step SA7). 9 is a flowchart for explaining an example of the battle rules of a game provided by the game server of one embodiment, and is a flowchart for explaining in detail step SA7 of the flowchart shown in FIG.

[0140] The HP of the player character at the start of the first turn battle is set to an initial value (full value). In this embodiment, the initial value of the HP of the player character is 40. Note that the HP of the player character at the start of the first turn by the turn execution unit 12 is not limited to the above, and may be the HP at the end of the previous battle, or may be the HP at the end of the previous battle after recovery due to items or the passage of time.

[0141] At the start of the battle, the turn execution unit 12 causes the display processing unit 15 to make the characters selected by each player character appear on the battlefield on the display of the user terminal 200.

[0142] If a character summoned to the battlefield has a special ability that is activated when it appears, the turn execution unit 12 activates the special ability in descending order of the character's SPEED value, which is one of the character's ability values, and activates the special ability at the time of appearance for all characters on the battlefield before the character starts attacking (step SB0). Note that the turn execution unit 12 may alternately activate the special ability of the character on the battlefield of one player's character and the character on the battlefield of the other player's character, or may activate the special ability of the character on the battlefield of both player's characters in SPEED order. For characters with the same SPEED value, the turn execution unit 12 probabilistically activates the special ability of one of the characters.

[0143] That is, the turn execution unit 12 sets K=1, determines whether or not the character on the battlefield with the Kth highest SPEED value has a special ability, and if so, activates that special ability. Note that K is a positive integer equal to or greater than 1 and is the total number of characters on the battlefield. The turn execution unit 12 sequentially increments the value of K, and activates the special abilities of all characters on the battlefield in descending order of SPEED value.

[0144] Examples of character special abilities include "Damage Null 1," "Double Attack," "Combine 1," "Resurrection," "Chant+," "Servant," and "On Attack: Deals damage to enemy player equal to own attack power." The timing at which a character's special ability is activated varies depending on the special ability. For example, there may be a special ability that is activated before a character starts attacking each turn, a special ability that is activated when a character attacks, a special ability that is activated when a character is attacked, a special ability that is activated when a character is summoned to the battlefield, or a special ability that is activated after all attacks by characters on the battlefield have been completed but before the end of the turn.

[0145] For example, if a character has the special ability of "double attack," the turn execution unit 12 causes the character to perform a double attack. At this time, for example, if the HP of the opponent character becomes zero after the first attack, the character may perform a second attack on another opponent character. If the character is in an enhanced state such as a brave state, the attack power of both attacks may be multiplied by a predetermined multiplier (a value greater than 1).

[0146] For example, if a character has the special ability "Combined 1," when the character appears (is summoned) on the battlefield, the turn execution unit 12 causes one ally character on the battlefield to leave the battlefield and grants the character the special ability of the removed ally character.

[0147] For example, if a character has the special ability of "Resurrection," parameter management unit 11 will revive the character with HP of 1 only once in that turn when the character's HP reaches zero in battle. The HP of a character revived by the special ability "Resurrection" is not limited to 1, and may be any value between 1 and the maximum value. If the character also has the special ability of "Servant," parameter management unit 11 will revive the character with HP of 1 one more time in that turn (twice in total) when the character's HP reaches zero in battle. If the character's HP reaches zero again after being revived a predetermined number of times, parameter management unit 11 will enable the special ability to be used in the next turn as an initial state.

[0148] For example, if a character has the special ability "Chant+," the parameter management unit 11 increases the attack power of the character after the character attacks. The parameter management unit 11 may increase the attack power by a predetermined value each time the character attacks, or may increase the attack power only after the character's first attack of each turn. After increasing the attack power of the character, the parameter management unit 11 maintains the increased attack power until the end of the battle.

[0149] For example, if a character has the special ability "When attacking: inflict damage equal to its own attack power on an enemy player," the parameter management unit 11 inflicts damage from the character's attack on the player character before inflicting it on an opponent character on the battlefield. Regardless of whether the character is in an enhanced state or not, the parameter management unit 11 treats the damage to the player character as damage equal to the attack power before the character is enhanced. Note that if the player character's HP reaches zero during a battle, the turn execution unit 12 ends the turn at that point.

[0150] Next, the turn execution unit 12 sets M=1 (step SB1) and executes an attack by the character with the Mth highest SPEED value among all characters on the battlefield (step SB2). The turn execution unit 12 executes an attack according to the character's special ability. Note that the turn execution unit 12 may alternately execute attacks by characters on the battlefield of one player's character and characters on the battlefield of the other player's character in SPEED order, or may execute attacks by characters on the battlefield of both player's characters in SPEED order. For characters with the same SPEED value, the turn execution unit 12 executes an attack by one of the characters probabilistically.

[0151] The parameter management unit 11 identifies the attacked character according to the range of the attack executed in step SB2 (short distance, long distance, all, in a line, piercing, etc.), and updates the parameters of the identified character (step SB3). If the attack range is short distance, the parameter management unit 11 updates the parameters of, for example, the opponent character closest to the attacking character. If the attack range is entire, the parameter management unit 11 updates the parameters of, for example, all opponent characters of the attacking character.

[0152] The parameter management unit 11 calculates damage using the attack power value of the attacking character and the defense power value of the attacked character. At this time, the parameter management unit 11 takes into consideration the special ability of the attacked character. For example, if the attacked character's special ability is "Damage Nullification 1," the parameter management unit 11 will nullify the first damage that the character receives after the start of the battle process.

[0153] For example, the parameter management unit 11 may update the parameters by subtracting the difference (damage) obtained by subtracting the attack power (ATK) value of the attacking character from the defense power (DEF) value of the attacked character from the HP of the attacked character.

[0154] Alternatively, for example, the parameter management unit 11 may calculate damage by subtracting the value obtained by multiplying the defensive power value of the attacked character by a predetermined percentage from the value obtained by multiplying the offensive power value of the attacking character by a predetermined percentage. In the latter case, the percentages by which the offensive power value and defensive power value are multiplied may be set in advance, or may be set probabilistically within a predetermined range (0% to 100%).

[0155] When a character completes an attack, the parameter management unit 11 adds strengthening parameters (called battle crystals in this embodiment) possessed by the player character that made the attack. Strengthening parameters will be described in detail later.

[0156] Next, the turn execution unit 12 determines whether the HP of at least one of the attacked characters has reached zero (step SB4). If the HP of any of the attacked characters has reached zero (a predetermined threshold or less) (step SB4, Yes), the character whose HP has reached zero is removed from the battlefield and becomes unusable in the turn that includes the time of the determination (step SB5).

[0157] Next, the turn execution unit 12 determines whether or not all characters on the battlefield of the attacked player have been annihilated as a result of eliminating the characters in step SB5 (step SB6).

[0158] If the HP of the attacked character does not become zero (below a predetermined threshold) in step SB4 (No in step SB4), and if all of the attacked player's characters are not annihilated in step SB6 (No in step SB6), the turn execution unit 12 determines whether M has reached the total number of characters on the battlefield (=Mmax) (step SB8). If M has not reached the total number of characters on the battlefield (No in step SB8), the turn execution unit 12 increments M by one (step SB9) and sequentially performs the processes from step SB2.

[0159] If M reaches the total number of characters on the battlefield (=Mmax) (step SB8, Yes), the turn execution unit 12 sequentially performs the processes from step SB1. In step SB6, if all the characters on the battlefield of the attacked player are annihilated (step SB6, Yes), the parameter management unit 11 inflicts damage to the HP of the opponent player's character equal to the cost or attack power of the characters remaining on the battlefield (step SB7), and ends the battle processing.

[0160] When the Nth turn battle ends, the turn execution unit 12 drops (exits) characters that have not been eliminated and remain on the battlefield from the battlefield to a lower level, and determines whether N is the upper limit of the number of turns (=5) or whether either player's HP is zero (step SA8). If N is not the upper limit of the number of turns and both players' HP are not zero (step SA8, No), the parameter management unit 11 resets the parameters of the characters that were eliminated in the Nth turn battle to their initial values ​​(for example, a state where they have been restored to their maximum values), and the turn execution unit 12 returns the characters to the battlefield for the (N+1)th turn (step SA9).

[0161] At this time, if the character whose parameters have been restored to their initial values ​​has a special ability, the parameter management unit 11 also sets the character's special ability to its initial state where it is not being used. The parameters of a character that does not disappear during the Nth turn of the battle but remains on the battlefield and falls (exits) from the battlefield to a lower level after the battle ends are not restored, and are maintained in the state they were in at the end of the Nth turn of the battle. Therefore, in the (N+1)th turn battle, characters that have not received any damage will return to the battlefield of the player character that was at a disadvantage in the previous turn, and characters that have maintained their damaged state up until the previous turn will remain in the battlefield of the player character that was at a disadvantage in the previous turn. This means that in the (N+1)th turn, there is a chance that a player character that was at a disadvantage in the Nth turn will be able to turn the tables.

[0162] Next, the turn execution unit 12 increments N by one (step SA10), returns to step SA3, and performs the process for the next turn. In step SA8, if N is the upper limit of the number of turns, or if the HP of any player is zero (step SA8, Yes), the turn executing unit 12 ends the battle process.

[0163] According to the game server, game processing method, and computer program of this embodiment, for example, even if a player is at a disadvantage in the battle situation, it is possible to increase the possibility of a turnaround in the next turn, thereby improving the entertainment value of the game. As a result, players of the game provided by the game server of this embodiment are likely to continue the battle without surrendering, which reduces the chances of their opponent surrendering, allowing more players to enjoy the battle to the end. In other words, according to this embodiment, it is possible to provide a game server, game processing method, and computer program for a highly entertaining game that includes multiple battles.

[0164] The present invention is not limited to the above-described embodiments, and various modifications can be made in the implementation stage without departing from the spirit of the invention. Furthermore, the embodiments may be implemented in appropriate combinations, in which case the combined effects can be obtained. Furthermore, the above-described embodiments include various inventions, and various inventions can be extracted by combining selected elements from the disclosed elements. For example, if the problem can be solved and the desired effect can be obtained even if some elements are deleted from all elements shown in the embodiments, the configuration from which these elements are deleted can be extracted as an invention. [Explanation of symbols]

[0165] 10...Battle processing unit, 11...Parameter management unit, 12...Turn execution unit, 13...In-game asset management unit, 14...User management unit, 15...Display processing unit, 31...User information, 32...Object information, 33...Field information, 34...History information, 100...Game system, 110...Game server, 111...Control unit, 113...Memory unit, 114...Input unit, 115...Output unit, 116...Communication unit, 120...NFT server, 121...Control unit, 122...NFT processing unit, 123...Memory unit, 124...Input unit, 125...Output unit, 126...Communication unit, 200...User terminal, 300...CEX, 400...DEX, 500...Marketplace

Claims

1. A game server that executes a game in which victory or defeat is determined based on the results of a battle that has been conducted over multiple turns, a turn execution unit that executes a battle process based on parameters of the object placed on the field for each turn; a parameter management unit that updates the parameters of the object in accordance with the battle processing, and, for the object whose parameters in the first turn have become equal to or less than a predetermined threshold value, sets the parameters in the second turn following the first turn to their initial values.

2. the parameter management unit sets user parameters for the user playing the game for each turn, and consumes the user parameters of the user in accordance with the object placed on the field by an operation of the user; the initial values ​​of the user parameters in the plurality of turns become larger as the game progresses; The game server according to claim 1.

3. the turn execution unit probabilistically applies any one of the plurality of fields for each turn; the parameter management unit sets the parameters of the object placed in the field in accordance with the field applied to the turn. The game server according to claim 1.

4. a turn execution unit that associates one or more of the plurality of objects with a user playing the game based on an operation of the user, each of a plurality of said objects being associated with a plurality of forms of said parameter; the turn execution unit sets the object associated with the user in the preset turn to a form different from a form in other turns; The game server according to claim 1.

5. the turn execution unit, when the parameters related to the order of attacks in the battle among the plurality of objects placed on the field are equal, determines the order probabilistically and executes the battle among the plurality of objects. The game server according to claim 1.

6. A game processing method for executing a game in which victory or defeat is determined based on the results of a battle that has been conducted over multiple turns, comprising: For each turn, a battle process is performed based on parameters of the object placed on the field; A game processing method in which the parameters of the object are updated in accordance with the battle processing, and for the object whose parameters in the first turn have become equal to or less than a predetermined threshold, the parameters in the second turn following the first turn are set to their initial values.

7. A computer program for causing a computer to execute the game processing method according to claim 6.

Images