Game device, game processing method, and program

Abstract

To provide a technique that allows a player to continue to have a desire to play a game.SOLUTION: A game device includes: a first control unit for receiving designation of a character to be lent among the characters owned by a first player, from a first terminal used by the first player; a second control unit for receiving a request that the character to be lent is borrowed from the first player, from a second terminal used by a second player; and a game control unit for setting a state in which the first player cannot use the character to be lent in the game, while the second player borrows the character to be lent.SELECTED DRAWING: Figure 4

Description

[Technical field]

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

[0002] In recent years, online games have been provided in which a player uses a group of multiple characters that the player owns to complete missions called quests (see, for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2015-134036 A Summary of the Invention [Problem to be solved by the invention]

[0004] In these online games, quests of various levels of difficulty are provided, and the more difficult the quests are cleared, the more rare the items and characters can be obtained.

[0005] However, for example, immediately after a player starts a game, the status and skills of the character that the player possesses are generally low. In this case, the player may lose motivation to play the game because the player can only clear a limited number of quests with low difficulty.

[0006] Therefore, an object of the present invention is to provide a game device, a game processing method, and a program that enable a player to continue to be motivated to play a game. [Means for solving the problem]

[0007] A game device according to one embodiment of the present invention has a first control unit that receives, from a first terminal used by the first player, a designation of a character to be loaned 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 loaned from the first player, and a game control unit that sets a state in which the first player cannot use the character to be loaned in the game while the second player is borrowing the character to be loaned. Effect of the Invention

[0008] According to the present invention, it is possible to provide a game device, a game processing method, and a program that enable a player to continue to be motivated to play a game. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram illustrating an example of a system configuration of a game system according to an embodiment of the present invention. [Diagram 2] A figure showing an example of a screen for organizing a deck. [Diagram 3] FIG. 2 is a diagram illustrating an example of the hardware configuration of a game server and a terminal. [Figure 4] FIG. 2 is a diagram illustrating an example of a functional block configuration of a game server. [Diagram 5] FIG. 11 is a diagram showing an example of a player management DB and an example of a possessed character management DB. [Figure 6] FIG. 2 is a diagram illustrating an example of a functional block configuration of a terminal. [Figure 7] 13 is a flowchart showing an example of a processing procedure for specifying a character to be lent and a candidate player for lent. [Figure 8] FIG. 13 is a diagram showing an example of a screen for accepting the designation of a character to be lent. [Figure 9] FIG. 13 is a diagram showing an example of a screen for accepting designation of a candidate player for lending. [Figure 10]13 is a flowchart showing an example of a processing procedure when borrowing a character. [Figure 11] FIG. 13 is a diagram showing an example of a screen for accepting borrowing of a character. [Figure 12] 13A and 13B are diagrams showing an example of a character list screen and a character detail screen. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] A preferred embodiment of the present invention will be described with reference to the accompanying drawings. In each drawing, the same reference numerals are used to denote the same or similar configurations. This embodiment can be applied to a game in which a player (may be called a user) owns multiple characters and can train the characters by clearing quests, but it can also be applied to any game in which a player owns and can train characters, such as a role-playing game, an action game, a puzzle game, or a shooting game.

[0011] <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.

[0012] The game server 10 is a device that performs some of the functions required for the terminal 20 to provide a game, such as managing various information related to players 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).

[0013] 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.

[0014] <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.

[0015] Here, a quest is a term that means a mission that must be cleared by satisfying certain predetermined conditions. A quest may also be called an exploration or a task. A player who participates in a quest can clear the quest by satisfying the certain conditions, and when the player clears a quest, a reward is given to the player and the story of the game progresses.

[0016] Moreover, a deck is a term that means a group made up of multiple characters. When challenging a quest, a player can advance the quest advantageously by selecting characters with the appropriate abilities to clear the quest and organizing a deck. An example of a screen for organizing a deck is shown in FIG. 2. As shown in FIG. 2, a player selects three characters to organize a deck. In this game, a player fights enemy monsters by controlling four characters, including the three characters (main, sub 1, sub 2) included in the deck and one character belonging to another player.

[0017] A player can register other players as friends. Registering a friend means that players build a predetermined relationship in advance within the game. In the 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 the game, when players who have registered friends cooperate to play together, the rewards and the like that can be obtained are increased compared to when players who have not registered each other as friends play together.

[0018] 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.

[0019] <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, an 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.

[0020] <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 device 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 device 12 included in the game server 10.

[0021] The terminal control unit 101 generates information necessary for executing 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 a screen displaying a list of characters owned by the player is displayed on the terminal 20, the terminal control unit 101 transmits data necessary for generating the screen (such as the latest status of each character) to the terminal 20. Furthermore, the terminal control unit 101 receives various instructions from the terminal 20 that the terminal 20 has accepted 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.

[0022] In addition, the terminal control unit 101 (first control unit) accepts the 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. The (second control unit) accepts a request to borrow a lending target character from the terminal 20 (second terminal) used by the lending destination player (second player), and notifies the game control unit 102 of the request.

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

[0024] In addition, the terminal control unit 101 may be configured to display a screen on the terminal 20 of the recipient player that accepts a request to borrow a character when the terminal 20 used by the lending player and the terminal 20 of the recipient player are located within a specified distance.

[0025] 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 target character, and notify the game control unit 102. When the lending destination player is designated as a lending candidate player by the lending player, the terminal control unit 101 may also cause the lending destination player's terminal 20 to display a screen for accepting a request to borrow a character.

[0026] Furthermore, the terminal control unit 101 may perform control so as not to accept an operation by the lending destination player to change the attributes of the borrowed character during game execution. 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, the attributes include, for example, the character's status (e.g., level, attack power, luck, HP, etc., which will be described later) and skills (e.g., special attack abilities, etc.).

[0027] The game control unit 102 provides functions that are performed by the game server 10 among various functions necessary for executing the present game. For example, the game control unit 102 provides a function for opening new quests, new monsters, etc. according to the game progress of each player, a function for managing characters possessed by each player, a function for managing various settings, etc., performed by each player in the game, a function for managing the lending and borrowing of characters performed between players, and a function for backing up game data possessed by the terminal 20.

[0028] The game control unit 102 also performs a process of setting so that the lending player cannot use the lent character in the game while the character is being lent. Furthermore, when a predetermined period of time has elapsed since the lending destination player started to borrow the character, the game control unit performs a process of returning the character to the lending player.

[0029] 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.

[0030] Fig. 5(a) is a diagram showing an example of a player management DB. The player management DB shown in Fig. 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 in this game. "Nickname" is a name (calling) set by a player in the game.

[0031] The "friend list" stores the player IDs of players who have registered as friends. Here, the "location information" is location information indicating the current location of the terminal 20 used by the player. The "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 higher the difficulty of the quest, the more experience points can be obtained. The "rank" is the player's status determined according to the 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.

[0032] "Stamina" is a parameter that is consumed 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 you can also force recovery by using certain items.

[0033] FIG. 5(b) is a diagram showing an example of the owned character management DB. The "player ID" is an ID indicating the player who owns the character. The "character ID" is an ID that uniquely identifies the character owned by the player. In this game, the player can own multiple characters of the same type, and can increase the status of the character by synthesizing characters of the same type. The character ID may be an ID that combines an ID that uniquely identifies the type of character and an ID that uniquely identifies characters of the same type owned by the player. In the example of FIG. 5(b), 1105-003 indicates that the character is the third character obtained among the characters of the character type 1105.

[0034] "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 are included in the deck, the higher the chance of obtaining more items by clearing a quest.

[0035] "HP (Hit Points)", "Attack Power" and "Speed" are status values ​​that indicate the life force and attacking ability of the 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 the character is lent to another player (on loan), whether the character has been borrowed from another player (on loan), or whether the character does not fall into either category (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.

[0036] 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 division of the functions provided by the terminal control unit 101 and the functions provided by the game control unit 102 is not limited to the division described in this embodiment, and may be divided in any manner.

[0037] 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 device 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 204 can be realized by using the storage device 12 included in the terminal 20.

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

[0039] The UI unit 202 has a function of accepting various inputs from a player and displaying various game screens on a display. The UI unit 202 also displays a game screen according to an instruction 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 a game screen in which the buttons are grayed out.

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

[0041] The storage unit 204 stores game data necessary for the game control unit 203 to execute the game. The game data includes image data of characters, a game scenario, and the like.

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

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

[0044] FIG. 7 is a flowchart showing an example of a processing procedure for designating a lendable character and a lendable candidate player.

[0045] 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. Then, in step S11, the communication unit 201 of the terminal 20 transmits information indicating the selected character 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.

[0046] FIG. 8 is a diagram showing an example of a screen for accepting the designation of a character to be lent. First, when a button B10 for making various settings related to character lending, which is displayed on a menu screen A10 related to character lending and borrowing, is pressed, a setting menu screen A11 related to character lending is displayed. Next, when a button B11 for designating (or changing) a character to be lent is pressed on the screen shown in A11, a screen A12 is displayed on which a list of characters owned by the player is displayed. When the player selects a character to be lent on the screen A12, an icon of the selected character is displayed in the display area B13 of the screen A10. Returning to FIG. 7, the explanation will be continued.

[0047] In step S12, the UI unit 202 of the terminal 20 accepts the selection of a lending candidate player 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 lending candidate player 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 lending candidate player to the "lending / borrowing flag" set in the processing procedure of step S11.

[0048] Fig. 9 is a diagram showing an example of a screen for accepting the designation of a lending candidate player. First, when a button B10 displayed on a menu screen A10 is pressed, a transition to a setting menu screen A11 related to lending of a character is made. Next, when a button B21 for setting (or changing) a lending candidate player is pressed on the screen shown in A11, a screen A22 is displayed in which a list of the player and players registered as friends is displayed. In the example of Fig. 9, icons B22-1 to B22-6 indicating players registered as friends are displayed.

[0049] When a player is selected on screen A22, the screen transitions to screen A23, which indicates that the character is available for loan. In this state, if the player is selected on screen A22 and borrows a character to be loaned, the icon of the character being loaned is displayed in a grayed-out state in display area B23 of menu screen A11. In addition, the time until the loaned character is returned is displayed near the icon.

[0050] The game control unit 102 may limit the number of characters that a player can simultaneously lend to one. To enable such a restriction, the terminal control unit 101 may cause the terminal 20 to display a screen (FIG. 8) for accepting the designation of lendable characters, on which only one lendable character can be selected. The terminal control unit 101 may also cause the terminal 20 to display a screen (FIG. 9) for accepting the designation of lendable candidate players, on which only one lendable candidate player can be selected.

[0051] (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.

[0052] FIG. 10 is a flowchart showing an example of a processing procedure when borrowing a character.

[0053] In step S20, the terminal control unit 101 of the game server 10 accepts a request to borrow a 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.

[0054] In step S21, the game control unit 102 searches for players who have registered the player who wishes to borrow a character (the player to whom the character is to be borrowed) as a lending candidate 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 a 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.

[0055] In step S22, the terminal control unit 101 causes the terminal 20 to display a screen for accepting the designation of a character to be borrowed. The screen displays a list of characters designated as characters to be lent 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 a 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.

[0056] In step S23, the game control unit 102 changes the "lending / borrowing flag" of the record of the character borrowed by the lending destination player in the possessed character management DB to "borrowed."

[0057] FIG. 11 is a diagram showing an example of a screen that accepts borrowing of a character. When a button B30 that accepts borrowing of a character is pressed on a menu screen A10 related to lending and borrowing of characters, the screen transitions to a screen A31 that indicates that a borrowable character is being searched for. When the search for a borrowable character is completed, the screen transitions to a screen A32 that displays a list of borrowable characters. In the example of FIG. 11, one character B31 is displayed on the screen A32 that displays the list of borrowable characters. Note that a case in which a plurality of characters are displayed on the screen is when there are a plurality of lending source players who have set the player referring to the screen as a lending candidate player.

[0058] 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 lent character is displayed near the icon.

[0059] 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.

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

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

[0062] (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).

[0063] Specifically, the predetermined actions include an action of incorporating the loaned character into a deck composition, an action of incorporating the loaned character into a deck composition and dispatching it on a quest, an action of combining the loaned character with another character (including an action of setting up automatic combination), an action of giving the loaned character an item that strengthens its status or skill, an action of selling the loaned character, etc. In addition, an action of deleting the player who is loaning the character from the friend registration may also be restricted.

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

[0065] 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 (prohibited) after the execution of the quest is completed. When the loaned character is forcibly returned, the loaning player can 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.

[0066] Among the quests provided in this game, there is a special quest in which the clearing condition is to clear all of the sub-quests. In this special quest, the character used to clear any one of the sub-quests is sealed and cannot be used in other sub-quests. However, in this embodiment, it may be possible to allow the sealed character to be lent out.

[0067] 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 lent out.

[0068] In this game, there is a function that increases the HP of a character according to the number of times the character is used. Regarding this function, when the lending destination player uses the lending character, it may be possible to set it so that the number of times the character is used is not counted.

[0069] The game control unit 102 of the game server 10 has a function of backing up game data in preparation for a change in model of the terminal 20, a breakdown, etc. When the game data backed up while the lending player is lending a character is restored, the time until the character is returned may also be restored as is. For example, when 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.

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

[0071] 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 will be shown using figures. FIG. 12(a) is an example of a character list screen. FIG. 12 The screen shown in (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.

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

[0073] In this game, a title is given according to the maximum number of times an attack hits an enemy character in one attack action and the maximum amount of damage inflicted on an enemy character in one attack action. However, if the characters organized in the deck include borrowed characters, these maximum values ​​may not be updated.

[0074] As mentioned above, some quests provided in this game have a feature that seals the character and makes it impossible to use the character in other subquests. However, borrowed characters may not be sealed even if the character completes the subquest.

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

[0076] 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 performance of the specified action in a state that the player cannot press (for example, grayed out).

[0077] Specifically, the prescribed action is the action of combining the borrowed character with another character. These include actions that change the status or skills (including the action of setting up automatic synthesis), actions that change the status or skills (for example, adding an item that strengthens the status), actions that sell 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.

[0078] 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 empty 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 acquired earliest or may be set to a randomly selected character. In this game, all characters must be set for the deck composition with registration number 1 among the registered deck compositions. Therefore, other characters may be automatically set for the deck composition with registration number 1.

[0079] When restoring game data backed up while the borrowed character was being used by the player, the game control unit 102 may restore the game data without changing the time until the character is returned. For example, if game data backed up when there are 24 hours left until the character is returned is restored 36 hours after the backup, the time until the character is returned may be changed to 24 hours.

[0080] In this game, a function is provided that allows the deck composition at the time of clearing a quest to be recorded as a deck history, and the recorded deck history to be reflected in one of the previously registered deck compositions. If a deck history including a returned character exists, the operation to reflect the 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, among the registered deck compositions, the deck composition of registration number 1 is specified such that all characters must be set. Therefore, when an operation is performed to reflect the deck history including the returned character in the deck composition of registration number 1, the operation may not be accepted on the screen that reflects the deck history.

[0081] <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.

[0082] On the other hand, if a beginner player could always borrow a powerful character from a veteran player, it would be the same as if the beginner player had a powerful character from the beginning, and the game balance would be disrupted. 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 allows the borrowing of characters only in limited situations, making it possible to prevent the game balance from being disrupted.

[0083] 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. are not limited to those illustrated, and can be changed as appropriate. In addition, configurations shown in different embodiments can be partially replaced or combined with each other. [Explanation of symbols]

[0084] 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

1. 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 a request to borrow the character to be lent from the first player from a second terminal used by a second player; a game control unit that sets a state in which the first player cannot use the lending character in the game while the second player is borrowing the lending character; A game device having the above configuration.

2. the second control unit controls the second terminal to display a screen for accepting the request when the first player and the second player are associated with each other in a predetermined relationship; 2. The game device according to claim 1.

3. the second control unit controls the second terminal to display a screen for accepting the request when the first terminal and the second terminal are present within a predetermined distance; 3. A game device according to claim 1 or 2.

4. The first control unit accepts, from the first terminal, a designation of a candidate player to be permitted to lend the character to be lent, the second control unit controls the second terminal to display a screen for accepting the request when the first player has designated the second player as the lending candidate player; 4. A game device according to claim 1.

5. the second control unit performs control so as not to accept, when the second player plays a game using the character to be lent, an operation to change an attribute of the character to be lent from the second player; 5. A game device according to claim 1.

6. the game control unit performs a process of returning the lending character to the first player when a predetermined period of time has elapsed since the second player started to borrow the lending character.

6. A game device according to claim 1.

7. A game processing method executed by a game device, comprising: a step of receiving, by the game device, 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 step of receiving, by the game device, a request to borrow the character to be lent from the first player, from a second terminal used by a second player; a step of setting, by the game device, a state in which the first player cannot use the lent character in the game while the second player is borrowing the lent character; The game processing method includes:

8. On the computer, receiving, 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; receiving a request to borrow the character to be lent from the first player from a second terminal used by a second player; A step of setting a state in which the first player cannot use the lent character in the game while the second player is borrowing the lent character; A program for executing the above.

Images