JP7583306B2 - GAME DEVICE, GAME PROCESSING METHOD AND PROGRAM - Google Patents

Description

The present invention relates to a game device, a game processing method, and a program.

In recent years, online games have been provided in which players use groups of multiple characters they own to complete missions called quests (see, for example, Patent Document 1).

JP 2015-134036 A

In these online games, players are provided with quests of various levels of difficulty, and are often structured so that players can obtain rarer items and characters by clearing more difficult quests.

However, for example, immediately after a player starts a game, it is common for the status and skills of the character they possess to be low. This means that the player will be able to clear only a limited number of quests with low difficulty, which may cause the player to lose motivation to continue playing the game.

The present invention aims to provide a game device, a game processing method, and a program that enable players to maintain their motivation to play the game.

A game device according to one aspect of the present invention has a first control unit that receives, from a first terminal used by a first player, a designation of a character to be lent from among characters owned by the first player, a second control unit that receives, from a second terminal used by a second player, a request to borrow the character to be lent from the first player, and a game control unit that sets a state in which the first player cannot use the character to be lent in the game while the second player is borrowing the character to be lent.

The present invention provides a game device, a game processing method, and a program that enable a player to maintain their motivation to play the game.

FIG. 1 is a diagram illustrating an example of a system configuration of a game system according to an embodiment of the present invention. A figure showing an example of a screen for organizing a deck. FIG. 2 is a diagram illustrating an example of the hardware configuration of a game server and a terminal. FIG. 2 is a diagram illustrating an example of a functional block configuration of a game server. 1A and 1B are diagrams showing an example of a player management DB and an example of a possessed character management DB. FIG. 2 is a diagram illustrating an example of a functional block configuration of a terminal. 13 is a flowchart showing an example of a processing procedure for specifying a character to be lent and a candidate player for lent. FIG. 13 is a diagram showing an example of a screen for accepting the designation of a character to be lent. FIG. 13 is a diagram showing an example of a screen for accepting designation of a candidate player for lending. 13 is a flowchart showing an example of a processing procedure when borrowing a character. FIG. 13 is a diagram showing an example of a screen for accepting borrowing of a character. 13A and 13B are diagrams showing an example of a character list screen and a character detail screen.

A preferred embodiment of the present invention will be described with reference to the attached drawings. In each drawing, parts with the same reference numerals have the same or similar configurations. This embodiment can be applied to games in which a player (which may be called a user) owns multiple characters and can develop the characters by clearing quests, but it can also be applied to any game in which a player can own and develop characters, such as role-playing games, action games, puzzle games, shooting games, etc.

<System Configuration>
Fig. 1 is a diagram showing an example of a system configuration of a game system 1 according to this embodiment. The game system 1 shown in Fig. 1 includes a game server 10 (game device) and a plurality of terminals 20. The game server 10 and the terminals 20 are connected to each other so as to be able to communicate with each other via a communication network N such as the Internet, an intranet, a wireless LAN, or mobile communication.

The game server 10 is a device that performs some of the functions required for the terminal 20 to provide the game, such as managing various information related to the player and executing some of the game processing. The game server 10 may be composed of one or more information processing devices, or may be composed of a virtual server (such as a cloud server).

The terminal 20 is a terminal that provides a game to a player, and the player can execute the game according to this embodiment by operating the terminal 20. The terminal 20 is, for example, a computer such as a mobile phone (including a smartphone), a tablet, a personal computer, an arcade game device, or a consumer game device. The terminal 20 notifies the game server 10 of its own position detected using a GPS (Global Positioning System) or the like.

＜Game Overview＞
Next, an overview of the game provided by the game system 1 according to this embodiment will be described. In the game provided by the game system 1 (hereinafter referred to as "this game"), the player can obtain new characters and items by organizing a deck with characters selected from a plurality of characters owned and clearing quests using the organized deck. In addition, the player can challenge quests with higher difficulty by developing a stronger character by synthesizing the plurality of characters obtained, or by strengthening the attributes of the character using items.

Here, a quest is a term that refers to a mission that can be cleared by meeting certain predetermined conditions. A quest is also called an exploration or a task. A player who participates in a quest can clear the quest by meeting the certain conditions. Clearing a quest gives the player a reward and progresses the story of the game.

A deck is a term that means a group made up of multiple characters. When challenging a quest, a player can advance through the quest with an advantage by selecting characters with the appropriate abilities to clear the quest and forming a deck. An example of a screen for forming a deck is shown in Figure 2. As shown in Figure 2, a player selects three characters to form a deck. In this game, the player fights enemy monsters by controlling four characters: the three characters included in the deck (main, sub 1, sub 2) and one other player's character.

Players can register other players as friends. Registering a friend means that players build a predetermined relationship in advance within the game. In this game, one player sends a request to another player to register them as friends, and the other player who receives the request approves the request, thereby registering the players as friends. In this game, when players who have registered friends cooperate to play together, the rewards and other benefits that can be obtained increase compared to when players who have not registered each other as friends play together.

This game provides a mechanism that allows players to lend and borrow characters. The player to whom the character is loaned (the player who borrows the character) (hereafter referred to as the "loaning player") can use the borrowed character by incorporating it into their deck. On the other hand, the player who lends the character (hereafter referred to as the "lending player") cannot use the character until it is returned. The loaned character is automatically returned to the lending player after a specified period of time has passed.

<Hardware Configuration>
3 is a diagram showing an example of the hardware configuration of the game server 10 and the terminal 20. The game server 10 and the terminal 20 each have a CPU (Central Processing Unit) 11, a storage device 12 such as a memory, a HDD (Hard Disk Drive) and/or an SSD (Solid State Drive), a communication IF (Interface) 13 for wired or wireless communication, an input device 14 for accepting input operations, and an output device 15 for outputting information. The input device 14 is, for example, a keyboard, a touch panel, a mouse, and/or a microphone. The output device 15 is, for example, a display and/or a speaker.

<Function block configuration>
FIG. 4 is a diagram showing an example of a functional block configuration of the game server 10. The game server 10 includes a terminal control unit 101, a game control unit 102, and a storage unit 103. The terminal control unit 101 and the game control unit 102 can be realized by the CPU 11 of the game server 10 executing a program stored in the storage unit 12. The program can be stored in a storage medium. The storage medium storing the program may be a non-transitory computer readable storage medium. The non-transitory storage medium is not particularly limited, and may be, for example, a storage medium such as a USB memory or a CD-ROM. The storage unit 103 can be realized by using the storage unit 12 provided in the game server 10.

The terminal control unit 101 generates information necessary to execute the game and transmits it to the terminal 20, thereby controlling the processing performed on the terminal 20 side for the game. For example, when the terminal 20 is caused to display a screen displaying a list of characters owned by the player, the terminal control unit 101 transmits data necessary to generate the screen (such as the latest status of each character) to the terminal 20. The terminal control unit 101 also receives various instructions from the terminal 20 that the terminal 20 has received from the player, and passes the received instructions to the game control unit 102. Note that when there are multiple terminals 20 (first terminal 20, second terminal 20) in the game system 1, the terminal control unit 101 that controls the first terminal 20 may be called the first control unit, and the terminal control unit 101 that controls the second terminal 20 may be called the second control unit.

The terminal control unit 101 (first control unit) also receives a designation of a character to be lent (hereinafter, referred to as a "lent character") from the terminal 20 (first terminal) used by the lending player (first player) and notifies the game control unit 102.
(Second control unit) accepts a request to borrow the lending target character from the terminal 20 (second terminal) used by the lending destination player (second player) and notifies the game control unit 102 .

In addition, when the lending player and the lending recipient player are associated in a predetermined relationship (for example, when they are registered as friends), the terminal control unit 101 may cause the lending recipient player's terminal 20 to display a screen accepting a request to borrow a character.

In addition, when the terminal 20 used by the lending player and the terminal 20 of the borrowed player are located within a predetermined distance, the terminal control unit 101 may cause the terminal 20 of the borrowed player to display a screen accepting a request to borrow a character.

The terminal control unit 101 may also receive, from the terminal 20 used by the lending player, a designation of a player (hereinafter referred to as a "lend candidate player") who is permitted to lend the lending character, and notify the game control unit 102. The terminal control unit 101 may also display, on the terminal 20 of the lending recipient player, a screen for accepting a request to borrow a character, when the lending recipient player is designated as a lending candidate player by the lending player.

The terminal control unit 101 may also perform control so as not to accept an operation by the borrowed player to change the attributes of the borrowed character while the game is being played. For example, the terminal control unit 101 may perform control so as not to display the borrowed character on a screen that accepts an operation to change the attributes. Here, attributes include, for example, the character's status (e.g., level, attack power, luck, HP, etc., described below) and skills (e.g., special attack abilities, etc.).

The game control unit 102 provides functions that are performed by the game server 10 among various functions necessary to execute the game. For example, the game control unit 102 provides functions such as a function to unlock new quests and new monsters according to each player's game progress, a function to manage characters owned by each player, a function to manage various settings made by each player in the game, a function to manage the lending and borrowing of characters between players, and a function to back up game data owned by the terminal 20.

The game control unit 102 also performs processing to set the character so that the lending player cannot use the lent character in the game while the character is lent. The game control unit also performs processing to return the character to the lending player when a predetermined period of time has passed since the borrowing player started to borrow the character.

The storage unit 103 stores a player management DB and a possessed character management DB. The player management DB manages game data possessed by each player. The possessed character management DB manages characters possessed by each player.

Figure 5(a) is a diagram showing an example of a player management DB. The player management DB shown in Figure 5(a) shows game data necessary for explaining this embodiment, and may also include game data not shown. "Player ID" is an ID that uniquely identifies a player within this game. "Nickname" is a name (calling) within the game set by the player.

The "friend list" stores the player IDs of players who have registered as friends. Here, "location information" is location information that indicates the current location of the terminal 20 used by the player. "Experience points" are the player's experience points, and a certain amount of experience points is added each time a quest is cleared. In this game, the more difficult the quest, the more experience points can be obtained. "Rank" is the player's status that is determined according to experience points, and as the rank increases, quests that are limited to players of a certain rank or higher can be played, and new items and monsters that can be obtained are unlocked.

"Stamina" is a parameter that is consumed in order to challenge a quest, and if you run out of stamina you will not be able to challenge the quest. Stamina is a parameter that recovers over time, but it can also be forcibly recovered by using certain items.

Figure 5(b) is a diagram showing an example of a possessed character management DB. "Player ID" is an ID that indicates the player who possesses a character. "Character ID" is an ID that uniquely identifies a character possessed by a player. In this game, a player can possess multiple characters of the same type, and can increase a character's status by combining characters of the same type. A character ID may be an ID that combines an ID that uniquely identifies a character's type with an ID that uniquely identifies a character of the same type possessed by the player. In the example of Figure 5(b), 1105-003 indicates that the character obtained third out of the characters of character type 1105.

"Level" indicates the character's level. As the level increases, the character's HP, attack power, and speed also increase. The upper limit of the level depends on the character's rarity. The rarer the character, the higher the upper limit of the level. "Luck" indicates the amount of luck a character has. Luck can be increased by combining characters of the same type. The more characters with high luck you include in your deck, the higher the chance of obtaining more items by clearing quests.

"HP (Hit Points)", "Attack Power" and "Speed" are status values that indicate the life force and attacking ability of a monster. "Status Enhancement/Skill Enhancement" indicates the status of items that enhance the character's status and skills. "Lending/Borrowing Flag" is a flag that indicates whether the character is available to be lent to the specified player (waiting to be lent), whether it is lent to another player (on loan), whether it is borrowed from another player (on loan), or whether it is neither of these (not set). "Waiting to be lent (Lending candidate: 0101)" indicates that the character with character ID 1010-001 is available to be lent to the player with player ID 0101. "Borrowing (Lending destination: 0103)" indicates that the character with character ID 1100-001 is lent to the player with player ID 0103.

In this embodiment, the functions provided by the terminal control unit 101 may be provided by the game control unit 102, or the functions provided by the game control unit 102 may be provided by the terminal control unit 101. In other words, the functions provided by the terminal control unit 101 and the functions provided by the game control unit 102 are not limited to the division of roles described in this embodiment, and may be divided in any manner.

FIG. 6 is a diagram showing an example of a functional block configuration of the terminal 20. The terminal 20 includes a communication unit 201, a UI (User Interface) unit 202, a game control unit 203, and a storage unit 204. The communication unit 201, the UI unit 202, and the game control unit 203 can be realized by the CPU 11 of the terminal 20 executing a program stored in the storage unit 12. The program can be stored in a storage medium. The storage medium storing the program may be a non-transitory computer readable medium. The non-transitory storage medium is not particularly limited, and may be, for example, a storage medium such as a USB memory or a CD-ROM. The storage unit 204 can be realized using the storage unit 12 provided in the terminal 20.

The communication unit 201 has the function of performing various communications with the game server 10 using the communication IF 13.

The UI unit 202 has a function of accepting various inputs from the player and displaying various game screens on the display. The UI unit 202 also displays the game screen according to instructions from the terminal control unit 101 of the game server 10. For example, when an instruction to gray out some buttons is received from the game server 10, the UI unit 202 displays the game screen in which the buttons are grayed out.

The game control unit 203 provides various functions necessary for executing the game by working with the game server 10. For example, the game control unit 203 provides functions such as a function for calculating the amount of damage that an ally character will receive from an attack by an enemy character, a function for notifying the game server 10 of the calculated amount of damage, and a function for transmitting game data held by the terminal 20 to the game server 10 for backup purposes.

The memory unit 204 stores game data necessary for the game control unit 203 to execute the game. The game data includes character image data, game scenarios, etc.

<Details of the process>
Next, a process for lending and borrowing a character in the game system 1 will be described.

(Designation of character to be lent and candidate player for lending)
In this game, a player who allows the lending of a character designates in advance the character to be lent and the potential player.

Figure 7 is a flowchart showing an example of the processing steps for specifying a character to be lent and a candidate player for lending.

In step S10, the UI unit 202 of the terminal 20 accepts a selection of a character to be lent from among the characters owned by the player on a screen showing a list of characters owned by the player. Next, in step S11, the communication unit 201 of the terminal 20 transmits information indicating the character for which the selection has been accepted to the game server 10. The terminal control unit 101 of the game server 10 receives the information from the terminal 20 and sets the "lend/borrow flag" of the character to be lent in the owned character management DB to waiting for lending.

Figure 8 shows an example of a screen that accepts the designation of a character to be lent. First, when button B10, which is displayed on menu screen A10 related to character lending and borrowing, and which allows the user to make various settings related to character lending, is pressed, the screen transitions to a setting menu screen A11 related to character lending. Next, when button B11, which allows the user to designate (or change) the character to be lent, is pressed on the screen shown in A11, the screen transitions to screen A12, which displays a list of characters owned by the player. When the player selects a character to be lent on screen A12, the icon of the selected character is displayed in display area B13 of screen A10. Returning to Figure 7, we will continue with the explanation.

In step S12, the UI unit 202 of the terminal 20 accepts the selection of a candidate player for loan on a screen showing a list of players who are registered as friends. In step S13, the communication unit 201 of the terminal 20 transmits information indicating the selected candidate player for loan to the game server 10. The terminal control unit 101 of the game server 10 receives the information from the terminal 20 and adds the player ID of the candidate player for loan to the "loan/borrow flag" set in the processing procedure of step S11.

Figure 9 shows an example of a screen that accepts the designation of a candidate player for loan. First, when button B10 displayed on menu screen A10 is pressed, a setting menu screen A11 related to character loan is displayed. Next, when button B21 for setting (or changing) a candidate player for loan is pressed on the screen shown in A11, screen A22 is displayed that displays a list of the player and players who are registered as friends. In the example of Figure 9, icons B22-1 to B22-6 indicating players who are registered as friends are displayed.

When a player is selected as a potential lender on screen A22, the screen transitions to screen A23, which indicates that lending is currently being solicited. In this state, if the player is selected as a potential lender on screen A22 and borrows a character to be lent, the icon of the character that is now on loan is displayed in a grayed-out state in display area B23 of menu screen A11. In addition, the time remaining until the loaned character is returned is displayed near the icon.

The game control unit 102 may limit the number of characters that a player can lend out at one time to one. To enable such a restriction, the terminal control unit 101 may cause the terminal 20 to display a screen (FIG. 8) that accepts the designation of characters to be lent out, on which only one character to be lent out can be selected. The terminal control unit 101 may also cause the terminal 20 to display a screen (FIG. 9) that accepts the designation of potential players to be lent out, on which only one player to be lent out can be selected.

(Character Borrowing)
In this game, borrowing of a character is permitted if the lending player and the borrower player have been registered as friends and if the lending player and the lending player are within a specified range.

Figure 10 is a flowchart showing an example of the processing procedure when borrowing a character.

In step S20, the terminal control unit 101 of the game server 10 accepts a request to borrow the lendable character from the terminal 20 of the player who wishes to borrow the character. Next, the game control unit 102 of the game server 10 searches the player management DB to search for players who are within a predetermined distance from the current location of the player who wishes to borrow (the current location of the terminal 20) and who are registered as friends. If the player does not exist, the process ends, and if the player does exist, the process proceeds to step S21.

In step S21, the game control unit 102 searches for players who have registered the player who wishes to borrow the character (the player to whom the character is to be borrowed) as a potential lending player among the registered friend players found in the processing procedure of step S20. More specifically, the game control unit 102 accesses the owned character management DB and searches for a record in which the "lending/borrowing flag" in each record of the character owned by each registered friend player found in the processing procedure of step S20 is set to "waiting for lending" and the player ID of the player who wishes to borrow the character is registered.

In step S22, the terminal control unit 101 causes the terminal 20 to display a screen for accepting the designation of the character to be borrowed. The screen displays a list of characters designated as loanable characters by the lending player searched for in step S21. The UI unit 202 of the terminal 20 also notifies the game server 10 of the characters designated on the screen. By receiving the notification, the terminal control unit 101 accepts the designation of the character to be borrowed by the lending destination player. The terminal control unit 101 notifies the game control unit 102 that the designation has been accepted.

In step S23, the game control unit 102 changes the "loan/borrow flag" of the record of the character borrowed by the borrowing player in the owned character management DB to "borrowed."

Figure 11 is a diagram showing an example of a screen that accepts the borrowing of a character. When the button B30 that accepts the borrowing of a character is pressed on the menu screen A10 related to the lending and borrowing of characters, the screen transitions to a screen A31 that indicates that a search for borrowable characters is in progress. When the search for borrowable characters is complete, the screen transitions to a screen A32 that displays a list of borrowable characters. In the example of Figure 11, one character B31 is displayed on the screen A32 that displays the list of borrowable characters. Note that multiple characters are displayed on this screen when there are multiple lending players who have set the player viewing this screen as a potential lending player.

When a character is selected on screen A32, the screen transitions to menu screen A10. The icon of the selected character is displayed in a grayed-out state in display area B32 of menu screen A10. In addition, the remaining time until the deadline for returning the loaned character is displayed near the icon.

In addition, a password (keyword) to be used when lending a character may be accepted in advance from the lending player, and borrowing of the character may be permitted if the password entered by the recipient player matches the password specified by the lending player.

In this case, the terminal control unit 101 accepts the password (keyword) specified by the lending player when lending a character in the processing procedure of step S10 or step S12 of FIG. 7, and registers it in the possessed character management DB. Next, the terminal control unit 101 may accept the password specified by the lending recipient player in the processing procedure of step S22 of FIG. 10, and display on the screen of the terminal 20 (screen A32 of FIG. 11) only the characters to be lent of the lending player who specified a password matching the accepted password. An example of an input box for accepting the password specified by the lending recipient player is shown in the upper right corner of screen A31 of FIG. 11.

The game control unit 102 may limit the number of characters that a player can borrow at one time to one. To enable such a restriction, the terminal control unit 101 may display button B30 in a state that cannot be pressed on the screen that accepts character borrowing (screen A10 in FIG. 11) while the player has already borrowed a character.

(Processing related to the lending player)
The terminal control unit 101 and the game control unit 102 perform control so that the lending player cannot use the lent character from the time the lending character is lent to the lending player until the character is returned. For example, when the lending player selects the lent character and attempts to perform a predetermined action, the terminal control unit 101 may cause the terminal 20 to display an error message indicating that the predetermined action cannot be performed. Alternatively, the terminal 20 may display a button that accepts the execution of the predetermined action in a state that the player cannot press (for example, grayed out).

Specific examples of specified actions include incorporating the loaned character into a deck, incorporating the loaned character into a deck and dispatching it on a quest, combining the loaned character with another character (including setting up automatic combination), giving the loaned character an item that enhances its status or skills, selling the loaned character, etc. In addition, restrictions may also be placed on the action of removing the player who is loaning the character from the friend list.

The terminal control unit 101 may display the loaned character in a grayed-out manner on various game screens of the loaning player, or may display the loaned character with a character string or label indicating that it is "loaned."

The loaned character may be forcibly returned at the instruction of the loaning player. If a quest using the loaned character is being executed at the time the instruction of the loaning player is received, the use of the loaned character may be permitted until the execution of the execution of the quest is completed, and the use of the loaned character may be restricted (made impossible) after the execution of the execution of the quest is completed. Then, when the loaned character is forcibly returned, the loaning player will be able to execute a quest using the character even while the loaned player is using the character in a quest. The loaned character may be returned to the loaning player at the instruction of the loaned player.

The quests provided in this game include special quests in which the clearing condition is to clear all of the subquests. In these special quests, the character used to clear any one of the subquests is sealed and cannot be used in other subquests. However, in this embodiment, it may be possible to allow the sealed character to be lent out.

In this game, there are parameters that are determined according to the total status of characters owned, or the total number of characters with a certain status. These parameters may be set not to change even when a character is loaned out.

In this game, there is a function that increases the HP of a character depending on the number of times the character is used. With regard to this function, if the lending player uses the lending character, it may be possible to set it so that it does not count the number of times it is used.

The game control unit 102 of the game server 10 has a function for backing up game data in case the terminal 20 is changed or broken. When the game data backed up while the lending player was lending a character is restored, the time until the character is returned may also be restored as is. For example, if game data backed up when there are 24 hours left until the character is returned is restored 36 hours after backup, the time until the character is returned may remain at 24 hours.

(Processing related to the loaned player)
The game control unit 102 allows the recipient player to freely incorporate the borrowed character into the deck composition, and also allows the recipient player to return the borrowed character at any time.

The terminal control unit 101 may add a character string or label indicating that the borrowed character is "on loan" to the various game screens of the borrowing player. A specific example is shown using figures. FIG. 12(a) is an example of a character list screen.
The screen shown in Fig. 12(a) displays a tag B40 indicating that the character is borrowed. Fig. 12(b) is an example of a character details screen. The screen shown in Fig. 12(b) displays a tag B41 indicating that the displayed character is borrowed.

In this game, missions are provided that can be completed by collecting many of the characters that appear in the game, but borrowed characters may not be counted as items to be collected in that mission.

In this game, titles are awarded according to the maximum number of times an enemy character is hit with an attack action and the maximum amount of damage inflicted on an enemy character with an attack action. However, if the characters organized into a deck include borrowed characters, these maximum values may not be updated.

As mentioned above, some quests provided in this game will seal characters so that they cannot be used in other side quests. However, borrowed characters may not be sealed even if the side quest is cleared.

The status and skills of the borrowed character may be the same as the status and skills immediately before borrowing, or may be the status and skills immediately before borrowing with a specified weight or skill added.

When the borrowed player selects the borrowed character and attempts to perform a specified action, the terminal control unit 101 may cause the terminal 20 to display an error message indicating that the specified action cannot be performed, or may cause the terminal 20 to display a button that accepts the execution of the specified action in a state that the player cannot press (e.g., grayed out).

Specifically, the predetermined actions include an action of combining the borrowed character with another character (including an action of setting up automatic combination), various actions of changing status or skills (for example, adding an item that strengthens a status), an action of selling the loaned character, etc. In addition, the action of deleting the player who is borrowing the character from the friend registration may also be restricted.

In this game, in order to easily change the deck composition according to the characteristics of the quest, a function is provided that allows multiple patterns of deck composition to be registered in advance. If a returned character is included in the registered deck composition, the terminal control unit 101 or the game control unit 102 may display the position where the character was set as blank when displaying the registered deck composition on the screen of the terminal 20, or may automatically set another character. In the latter case, the other character may be set to the character that was acquired first, or may be set to a randomly selected character. Note that in this game, all characters must be set for the deck composition with registration number 1 among the registered deck compositions. Therefore, another character may be automatically set for the deck composition with registration number 1.

When restoring game data that was backed up while the borrowed character was being used by the player, the game control unit 102 may restore the data without changing the time remaining until the character is returned. For example, if game data that was backed up when there were 24 hours remaining until the character was returned is restored 36 hours after the data was backed up, the time remaining until the character is returned may be set to 24 hours.

This game has a function that allows the deck composition at the time of clearing a quest to be recorded as deck history, and the recorded deck history to be reflected in one of the previously registered deck composition. If a deck history exists that includes a returned character, the operation to reflect that deck history in the deck composition may not be accepted, or the position where the returned character was set may be left blank. As mentioned above, of the registered deck compositions, the deck composition with registration number 1 is specified such that all characters must be set. Therefore, when an operation is performed to reflect a deck history that includes a returned character in the deck composition with registration number 1, the operation may not be accepted on the screen that reflects the deck history.

<Summary>
According to the embodiment described above, since it is possible for players to lend and borrow characters, for example, a beginner who has just started playing the game can borrow a powerful character from a veteran player who is close to him to challenge a quest. Veteran players can also lend characters that they do not normally use to beginner players. This not only stimulates communication between players, but also increases the possibility of clearing even difficult quests, making it possible for players to continue to be motivated to play the game.

On the other hand, if a novice player were always able to borrow powerful characters from veteran players, it would be the same as if the novice player had a powerful character from the start, which could upset the game balance. Therefore, in this embodiment, players who can lend and borrow characters are limited to players who are registered as friends and who are physically close to each other. This means that borrowing characters is only permitted in limited situations, making it possible to prevent the game balance from being upset.

The above-described embodiments are intended to facilitate understanding of the present invention, and are not intended to limit the present invention. The flow charts, sequences, elements included in the embodiments, and their arrangements, materials, conditions, shapes, sizes, etc., described in the embodiments are not limited to those exemplified, and may be modified as appropriate. In addition, configurations shown in different embodiments may be partially substituted or combined.

1... Game system, 10... Game server, 11... CPU, 12... Storage device, 13... Communication IF, 14... Input device, 15... Output device, 20... Terminal, 101... Terminal control unit, 102... Game control unit, 103... Storage unit, 201... Communication unit, 202... UI unit, 203... Game control unit, 204... Storage unit

Claims (4)

a processor, the processor comprising:
In a game in which game elements can be organized in advance into a plurality of registered decks including a first deck , when a game element to be lent out among game elements owned by a first player is borrowed by a second player and then the game element to be lent is returned,
When the game element to be lent is set in the first deck , another game element is set in place of the game element to be lent on a screen displaying the first deck ;
When the game element to be lent is set in a registered deck other than the first deck, the position of the game element to be lent is displayed as blank on a screen displaying the registered deck.
Information processing device. The processor:
In a game in which game elements can be organized in advance into a plurality of registered decks including a first deck , when a game element to be lent out among game elements owned by a first player is borrowed by a second player and then the game element to be lent is returned,
When the game element to be lent is set in the first deck , another game element is set in place of the game element to be lent on a screen displaying the first deck ;
When the game element to be lent is set in a registered deck other than the first deck, the position of the game element to be lent is displayed as blank on a screen displaying the registered deck.
Information processing methods. The processor:
In a game in which game elements can be organized in advance into a plurality of registered decks including a first deck , when a game element to be lent out among game elements owned by a first player is borrowed by a second player and then the game element to be lent is returned,
When the game element to be lent is set in the first deck , another game element is set in place of the game element to be lent on a screen displaying the first deck ;
When the game element to be lent is set in a registered deck other than the first deck, the position of the game element to be lent is displayed as blank on a screen displaying the registered deck.
A program that executes a process. A server and a terminal are provided,
The server,
In a game in which game elements can be organized in advance into a plurality of registered decks including a first deck, when a game element to be lent out among game elements owned by a first player is borrowed by a second player and then the game element to be lent is returned,
When the game element to be lent is set in the first deck, another game element is set in place of the game element to be lent on a screen displaying the first deck of the terminal;
When the game element to be lent is set in a registered deck other than the first deck, the position of the game element to be lent is displayed as blank on a screen of the terminal displaying the registered deck.
system.

Images