Game device, game processing method, and program

Abstract

To provide technology that enables players to maintain their motivation to play games. [Solution] A game device comprising: a first control unit that receives a designation of a character to be lent from among the characters owned by the first player from a first terminal used by the first player; a second control unit that receives a request from the second player to borrow the character to be lent from the first player from a second terminal used by the second player; and a game control unit that sets the first player to be unable to use the character to be lent in the game while the second player is borrowing the character to be lent.

Description

Technical Field

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

Background Art

[0002] In recent years, online games have been provided in which players clear missions called quests using a group combining a plurality of characters they possess (for example, Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In such online games, quests of various difficulty levels are provided, and in many cases, by clearing quests with higher difficulty levels, it is possible to obtain rarer (rare) items and characters.

[0005] However, for example, immediately after a player starts a game, it is common for the status and skills of the characters they possess to be low. Then, the player can only clear limited quests with low difficulty levels, and there is a possibility of losing the motivation to play the game.

[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 have the motivation to play the game.

Means for Solving the Problems

[0007] A game device according to one aspect of the present invention includes: a first control unit that receives a designation of a character to be lent from among the characters owned by the first player from a first terminal used by the first player; a second control unit that receives a request from the second player to borrow the character to be lent from the first player from a second terminal used by the second player; and a game control unit that sets the first player in a state where they cannot use the character to be lent in the game while the second player is borrowing the character to be lent. [Effects 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 players to maintain their motivation to play the game. [Brief explanation of the drawing]

[0009] [Figure 1] This figure shows an example of the system configuration of the game system according to this embodiment. [Figure 2] This is a diagram showing an example of a screen for creating a deck. [Figure 3] This figure shows an example of the hardware configuration of a game server and terminal. [Figure 4] This figure shows an example of the functional block structure of a game server. [Figure 5] This figure shows an example of a player management database and an example of a character ownership management database. [Figure 6] This figure shows an example of the functional block configuration of a terminal. [Figure 7] This flowchart shows an example of the processing procedure for specifying the characters to be lent and the players who are candidates for lending them. [Figure 8] This figure shows an example of a screen for selecting characters to be borrowed. [Figure 9] This figure shows an example of a screen that accepts the selection of a player to be borrowed. [Figure 10]This is a flowchart illustrating an example of the processing procedure when a character is borrowed. [Figure 11] This figure shows an example of a screen for accepting character borrowing requests. [Figure 12] This figure shows an example of the character list screen and the character details screen. [Modes for carrying out the invention]

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

[0011] <System Configuration> Figure 1 shows an example of the system configuration of the game system 1 according to this embodiment. The game system 1 shown in Figure 1 comprises 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 via a communication network N such as the Internet, intranet, wireless LAN, or mobile communication.

[0012] The game server 10 is a device that performs some of the functions necessary for the terminal 20 to provide the game, such as managing various information about the player or executing some of the game's processing. The game server 10 may consist of one or more information processing devices, or it may be configured using a virtual server (such as a cloud server).

[0013] The terminal 20 is a terminal that provides games to players, and the players 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 GPS (Global Positioning System) or the like.

[0014] <Game Overview> Next, the 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 forming a deck with the character selected from the plurality of characters he or she possesses and clearing quests using the formed deck. In addition, the player can grow into a stronger character by synthesizing the obtained plurality of characters, or challenge quests with a higher difficulty level by strengthening the attributes of the characters using items.

[0015] Here, a quest is a term that means a mission whose clear condition is to satisfy a predetermined certain condition. 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 condition, and when the quest is cleared, a reward is given to the player or the story of this game progresses.

[0016] Also, a deck is a term that means a group combining a plurality of characters. When a player challenges a quest, the player can advantageously progress the quest by selecting characters with suitable abilities to clear the quest and forming a deck. An example of a screen for deck formation is shown in FIG. 2. As shown in FIG. 2, the player selects three characters to form a deck. In this game, the player battles against enemy monsters by operating four characters, which are three characters (main, sub1, sub2) included in the deck formation plus one character of another player.

[0017] Players can register as friends with other players. Friend registration means that players construct a predetermined relationship in advance within this game. In this game, when one player sends a request indicating a desire to register as a friend with another player, and the other player who receives the request approves the request, friend registration is performed between the players. In this game, when players play cooperatively among those who have registered as friends, the rewards and the like that can be obtained increase compared to when playing among players who have not registered as friends.

[0018] This game provides a mechanism that allows players to lend and borrow characters. The player who is the recipient of the loan (the player who borrows the character, hereinafter referred to as the "loan recipient player") can incorporate the borrowed character into the deck formation and use it. On the other hand, the player who lends the character (hereinafter referred to as the "loan source player") cannot use the character until the lent character is returned. The lent character is automatically returned to the loan source player when a predetermined period elapses.

[0019] <Hardware Configuration> Figure 3 shows an example of the hardware configuration of a game server 10 and a terminal 20. The game server 10 and terminal 20 have a CPU (Central Processing Unit) 11, memory, a storage device 12 such as an HDD (Hard Disk Drive) and / or an SSD (Solid State Drive), a communication interface 13 for wired or wireless communication, an input device 14 for receiving 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] <Functional Block Configuration> Figure 4 shows an example of the 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 medium. The non-transitory storage medium is not particularly limited, but may be a storage medium such as a USB memory or CD-ROM. The storage unit 103 can be realized using the storage device 12 provided by the game server 10.

[0021] The terminal control unit 101 controls the processing performed on terminal 20 regarding the game by generating the information necessary to run the game and sending it to terminal 20. For example, when displaying a screen on terminal 20 that lists the characters owned by the player, the terminal control unit 101 sends the data necessary to generate the screen (such as the latest status of each character) to terminal 20. The terminal control unit 101 also receives various instructions from terminal 20 that have been received by terminal 20 from the player and passes the received instructions to the game control unit 102. If 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] Furthermore, the terminal control unit 101 (first control unit) receives the designation of the character to be lent (hereinafter referred to as "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) receives a request from the borrowing player (second player) to borrow the character from terminal 20 (second terminal) and notifies the game control unit 102.

[0023] Furthermore, the terminal control unit 101 may also display a screen on the borrowing player's terminal 20 that accepts a request to borrow a character when the lending player and the borrowing player are associated in a predetermined relationship (for example, when they are registered as friends).

[0024] Furthermore, the terminal control unit 101 may also cause the terminal 20 used by the lending player and the terminal 20 of the borrowing player to display a screen on the borrowing player's terminal 20 that accepts a request to borrow a character.

[0025] Furthermore, the terminal control unit 101 may receive a designation from the terminal 20 used by the lending player of players who are permitted to borrow the character (hereinafter referred to as "candidate players") and notify the game control unit 102. Also, if the borrowing player has been designated as a candidate player by the lending player, the terminal control unit 101 may display a screen on the borrowing player's terminal 20 that accepts a request to borrow the character.

[0026] Furthermore, the terminal control unit 101 may be controlled to prevent the borrowing player from changing the attributes of the borrowed character while the game is running. For example, the terminal control unit 101 may be controlled to not display the borrowed character on the screen that accepts the operation to change the attributes. Here, attributes include, for example, the character's status (e.g., level, attack power, luck, HP, etc., as described later) and skills (e.g., special attack abilities, etc.).

[0027] The game control unit 102 provides various functions necessary for running the game, which are performed on the game server 10 side. For example, the game control unit 102 provides functions to unlock new quests and new monsters according to each player's game progress, functions to manage the characters each player owns, functions to manage various settings made by each player in the game, functions to manage the lending and borrowing of characters between players, and functions to back up the game data held by the terminal 20.

[0028] Furthermore, the game control unit 102 processes the settings so that the lending player cannot use the borrowed character in the game while the character is on loan. In addition, the game control unit processes the return of the character to the lending player when a predetermined period of time has elapsed since the borrowing player started using the character.

[0029] The memory unit 103 stores the player management DB and the owned character management DB. The player management DB manages the game data owned by each player. The owned character management DB manages the characters owned by each player.

[0030] Figure 5(a) shows an example of a player management database. The player management database shown in Figure 5(a) shows the 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 the name (appearance) set by the player within the game.

[0031] The "Friend List" stores the player IDs of registered friends. Here, "Location Information" is the location information indicating the current location of the device 20 used by the player. "Experience Points" is the player's experience points, and a predetermined amount of experience points are added each time a quest is completed. In this game, the more difficult the quest, the more experience points are gained. "Rank" is the player's status, which is determined by their experience points. As the rank increases, players can play quests that are limited to players of a certain rank or higher, and new items and obtainable monsters will be unlocked.

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

[0033] Figure 5(b) shows an example of a character ownership management database. The "Player ID" is an ID that indicates the player who owns the character. The "Character ID" is an ID that uniquely identifies the character owned by the player. In this game, players can own multiple characters of the same type, and can increase the character's stats by combining characters of the same type. The Character ID may be a combination of an ID that uniquely identifies the character type and an ID that uniquely identifies the character of the same type owned by the player. In the example in Figure 5(b), 1105-003 indicates that it is the third character acquired among characters of character type 1105.

[0034] "Level" indicates a character's level. As the level increases, the character's HP, attack power, and speed increase. The level cap depends on the character's rarity. Characters with higher rarity have a higher level cap. "Luck" indicates the amount of luck a character possesses. Luck increases 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.

[0035] "HP (Hit Points)", "Attack Power", and "Speed" are status values ​​that indicate a monster's vitality and attack ability. "Status Enhancement / Skill Enhancement" indicates the status of items that enhance a character's status and skills. The "Lending / Borrowing Flag" is a flag that indicates whether the character is available to lend to a specified player (waiting to be lent), is currently lent to another player (on loan), is currently borrowed from another player (borrowed), or does not fall into any of the above categories (not set). "Waiting to be lent (Candidate for lending: 0101)" indicates that the character with character ID 1010-001 is available to lend to the player with player ID 0101. "Currently borrowed (Recipient: 0103)" indicates that the character with character ID 1100-001 is currently 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 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 labor described in this embodiment, and may be divided in any way.

[0037] Figure 6 shows an example of the functional block configuration of terminal 20. 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 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 medium. The non-transitory storage medium is not particularly limited, but may be a storage medium such as a USB memory or CD-ROM. The storage unit 204 can be realized using the storage device 12 provided by terminal 20.

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

[0039] The UI unit 202 has the function of receiving various inputs from the player and displaying various game screens on the display. The UI unit 202 also displays game screens according to instructions from the terminal control unit 101 of the game server 10. For example, if the UI unit 202 receives an instruction from the game server 10 to gray out some buttons, it will display a game screen with those buttons grayed out.

[0040] The game control unit 203 works in conjunction with the game server 10 to provide various functions necessary to run the game. For example, the game control unit 203 provides functions such as calculating the amount of damage an ally character receives from an attack by an enemy character, notifying the game server 10 of the calculated damage amount, and sending game data held by the terminal 20 to the game server 10 for backup.

[0041] The memory unit 204 stores the game data necessary for the game control unit 203 to run the game. The game data includes character image data, game scenarios, and the like.

[0042] <Detailed processing procedure> Next, we will explain the processing procedure when characters are lent or borrowed in Game System 1.

[0043] (Designation of characters to be borrowed and potential players to borrow them) In this game, players who allow character lending must pre-designate the character to be lent and the potential lending players.

[0044] Figure 7 is a flowchart showing an example of the processing procedure for specifying the characters to be lent and the players who are candidates for lending them.

[0045] In step S10, the UI unit 202 of terminal 20 displays a screen showing a list of characters owned by the player, and accepts the player's selection of a character to be lent out from among the characters owned by the player. Subsequently, in step S11, the communication unit 201 of terminal 20 sends information indicating the selected character to the game server 10. The terminal control unit 101 of the game server 10 receives this information from terminal 20 and sets the "lending / borrowing flag" of the character to be lent out in the owned character management DB to "waiting for lending".

[0046] Figure 8 shows an example of a screen for selecting a character to lend. First, when button B10, which is displayed on menu screen A10 related to character lending, is pressed, the screen transitions to the character lending settings menu screen A11. Next, when button B11, which is used to specify (or change) a character to lend, 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 lend on screen A12, the icon of the selected character is displayed in display area B13 on screen A10. Return to Figure 7 and continue the explanation.

[0047] In step S12, the UI unit 202 of terminal 20 accepts the selection of a candidate player for lending on a screen displaying a list of registered friends. In step S13, the communication unit 201 of terminal 20 sends information indicating the selected candidate player for lending to the game server 10. The terminal control unit 101 of the game server 10 receives this information from terminal 20 and adds the player ID of the candidate player for lending to the "lending / borrowing flag" set in the processing procedure of step S11.

[0048] Figure 9 shows an example of a screen for selecting a player to lend out. First, when button B10 displayed on menu screen A10 is pressed, the screen transitions to the character lending settings menu screen A11. Next, on the screen shown in A11, when button B21 for setting (or changing) a player to lend out is pressed, screen A22 is displayed, which shows a list of players that the player has registered as friends. In the example in Figure 9, icons B22-1 to B22-6, which represent players who have registered as friends, are displayed.

[0049] When a candidate player is selected on screen A22, the screen transitions to screen A23, which indicates that the character is currently available for loan. If the candidate player selected on screen A22 borrows the character, the icon of the borrowed character will be displayed in gray in display area B23 of menu screen A11. Additionally, the remaining time until the borrowed character is returned will be displayed near the icon.

[0050] The game control unit 102 may also limit the number of characters a player can lend out at one time. To enable such a restriction, the terminal control unit 101 may display a screen on the terminal 20 that allows only one character to be selected for lending (Figure 8). In addition, the terminal control unit 101 may display a screen on the terminal 20 that allows only one candidate player to be selected for lending (Figure 9).

[0051] (Borrowing characters) In this game, borrowing a character is permitted only if the lending player and the borrowing player are registered as friends, and both players are within a specified range.

[0052] Figure 10 is a flowchart showing an example of the processing procedure when a character is borrowed.

[0053] In step S20, the terminal control unit 101 of the game server 10 receives a request to borrow a 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 for players who are located within a predetermined distance from the current location of the player who wishes to borrow the character (the current location of terminal 20) and who are registered as friends. If no such player is found, the process ends; if such a player is found, the process proceeds to step S21.

[0054] In step S21, the game control unit 102 searches for players among the friend-registered players found in the processing procedure of step S20 who have registered a player who wishes to borrow a character (borrowing player) as a candidate borrowing player. More specifically, the game control unit 102 accesses the owned character management DB and searches whether there is a record in each record of a character owned by each friend-registered player found in the processing procedure of step S20 in which the "borrowing flag" is set to "waiting for loan" and the player ID of the player who wishes to borrow the character is registered.

[0055] In step S22, the terminal control unit 101 displays a screen on the terminal 20 that accepts the selection of the character to be borrowed. This screen displays a list of characters that the lending player, who was searched in step S21, has designated as characters to be borrowed. The UI unit 202 of the terminal 20 also notifies the game server 10 of the character specified on this screen. Upon receiving this notification, the terminal control unit 101 accepts the selection of the character to be borrowed from the borrowing player. The terminal control unit 101 then notifies the game control unit 102 that the selection has been accepted.

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

[0057] Figure 11 shows an example of a screen for accepting character borrowing requests. When the button B30 for accepting character borrowing requests is pressed on the menu screen A10 related to character borrowing, the screen transitions to screen A31, which indicates that the system is searching for available characters. Once the search for available characters is complete, the screen transitions to screen A32, which displays a list of available characters. In the example in Figure 11, screen A32, which displays a list of available characters, shows one character, B31. Note that if multiple characters are displayed on this screen, it means that there are multiple lending players who have set the player viewing this screen as a candidate player for borrowing.

[0058] When a character is selected on screen A32, the user transitions to menu screen A10. On menu screen A10, the icon of the selected character is displayed in grayed-out area B32. The remaining time until the character must be returned is also displayed near the icon.

[0059] Alternatively, the lending player may be required to specify a password (keyword) for lending the character in advance. The borrowing of the character may then be permitted only if the password entered by the borrowing player matches the password specified by the lending player.

[0060] In this case, the terminal control unit 101 receives the password (keyword) specified by the lending player when lending a character in the processing procedure of step S10 or step S12 in Figure 7, and registers it in the owned character management DB. Subsequently, the terminal control unit 101 may receive the password specified by the borrowing player in the processing procedure of step S22 in Figure 10, and display only the characters to be lent by the lending player who specified a password that matches the received password on the screen of the terminal 20 (screen A32 in Figure 11). An example of an input box for receiving the password from the borrowing player is shown in the upper right of screen A31 in Figure 11.

[0061] The game control unit 102 may also limit the number of characters a player can borrow at one time. To enable such a restriction, the terminal control unit 101 may display the screen for accepting character borrowing requests (screen A10 in Figure 11) in a state where button B30 cannot be pressed while the player is already borrowing a character.

[0062] (Processing related to the lending player) The terminal control unit 101 and the game control unit 102 control the system so that the lending player cannot use the character while it is on loan from the time the character is loaned to the borrowing player until it is returned. For example, if the lending player selects the loaned character and attempts to perform a predetermined action, the terminal control unit 101 may display an error message on the terminal 20 indicating that the predetermined action cannot be performed. Alternatively, the button that accepts the execution of the predetermined action may be displayed on the terminal 20 in a state where the player cannot press it (for example, by being grayed out).

[0063] The specified actions include, specifically, including a loaned character in a deck formation, including a loaned character in a deck formation and deploying it in a quest, combining a loaned character with other characters (including setting up automatic combination), giving a loaned character items that enhance their stats or skills, and selling a loaned character. Additionally, removing a player who has lent a character from your friend list may also be restricted.

[0064] The terminal control unit 101 may gray out characters that are currently on loan on the various game screens on the lending player's side, or it may add a string or label indicating that a character is on loan to the character and display it.

[0065] A character currently on loan may be forcibly returned upon instruction from the lending player. If a quest using the loaned character is being executed at the time the lending player's instruction is received, the use of the loaned character may be permitted until the quest is completed, and after the quest is completed, the use of the loaned character may be restricted (made prohibited). If a loaned character is forcibly returned, the lending player will be able to execute quests using that character even if the borrowing player is using that character in a quest. In addition, a loaned character may be returned to the lending player upon instruction from the borrowing player.

[0066] In this game, there are special quests that require the completion of multiple subquests. In these special quests, a character used to complete any one of the subquests is sealed and cannot be used in any of the other subquests. However, in this embodiment, it may be permitted to lend out the sealed character.

[0067] In this game, there are parameters that are determined by the sum of the stats of the characters you own, or by the total number of characters that possess certain stats. These parameters may be kept unchanged even when characters are lent out.

[0068] This game has a feature where a character's HP increases depending on the number of times it is used. Regarding this feature, it may be decided that when a borrowed player uses a character, it will not be counted towards the usage count.

[0069] The game control unit 102 of the game server 10 is equipped with a function to back up game data in preparation for changes in terminal models or malfunctions of terminals 20. When a lending player restores game data that was backed up while the character was being lent out, the remaining time until the character is returned may also be restored as is. For example, if game data was backed up when there were 24 hours remaining until the character was returned, and then restored 36 hours after the backup, the remaining time until the character is returned may remain at 24 hours.

[0070] (Processing related to borrowing players) The game control unit 102 allows the borrowing player to freely incorporate the borrowed character into their deck. It also allows the borrowing player to return the borrowed character at any time.

[0071] The terminal control unit 101 may also display a string or label indicating that a character is currently borrowed on various game screens on the borrowing player's side. A specific example is shown using the figure. Figure 12(a) is an example of a character list screen. Figure 12 The screen shown in (a) displays tag B40, indicating that the character is borrowed. Figure 12(b) is an example of a character details screen. The screen shown in Figure 12(b) displays tag B41, indicating that the displayed character is borrowed.

[0072] This game includes missions that are completed by collecting many characters that appear in the game, but borrowed characters may not be counted as collectibles for those missions.

[0073] In this game, titles are awarded based on the maximum number of hits on an enemy character in a single attack action and the maximum amount of damage dealt to an enemy character in a single attack action. However, if a borrowed character is included in the characters in your deck, these maximum values ​​may be prevented from being updated.

[0074] As mentioned earlier, some quests in this game have a feature where characters are sealed and cannot be used in other subquests. However, borrowed characters may not be sealed even after completing subquests.

[0075] The borrowed character's stats and skills may be the same as those immediately before borrowing, or they may be the same as those immediately before borrowing, with a predetermined weight and predetermined skills added.

[0076] The terminal control unit 101 may display an error message on the terminal 20 indicating that the borrowing player cannot perform a predetermined action when the borrowing player selects a borrowed character and attempts to perform a predetermined action, or it may display a button on the terminal 20 that accepts the execution of the predetermined action in a state where the player cannot press it (for example, by being grayed out).

[0077] The specified actions are, specifically, the actions of combining a borrowed character with other characters. Examples of actions that may be restricted include setting up automatic synthesis, various actions that change stats or skills (for example, granting items that enhance stats), and selling a character that is currently on loan. Additionally, removing a player who is currently using a borrowed character from your friend list may also be restricted.

[0078] In this game, a function is provided that allows players to pre-register multiple deck configurations in order to easily change deck configurations according to the characteristics of the quest. If a returned character is included in a registered deck configuration, the terminal control unit 101 or game control unit 102 may either display the position where the returned character was set as empty when displaying the registered deck configuration on the terminal 20 screen, or it may automatically set another character. In the latter case, the other character may be set to the character acquired first, or to a randomly selected character. In this game, all characters must be set in the registered deck configuration with registration number 1. Therefore, the other character may be automatically set in the registered deck configuration with registration number 1.

[0079] The game control unit 102 may, when restoring game data backed up by a borrowing player while they are using the character, restore it without changing the time remaining until the character is returned. For example, if game data backed up when there are 24 hours remaining until the character is returned is restored 36 hours after the backup, the time remaining until the character is returned may be set to 24 hours.

[0080] This game has a feature that allows you to record the deck composition at the time of quest completion as a deck history, and reflect the recorded deck history in one of the registered deck compositions mentioned above. If there is a deck history that includes returned characters, you can choose not to accept the operation to reflect that deck history in the deck composition, or you can choose to leave the position where the returned characters were set empty. As mentioned above, the specification is that all characters must be set in the registered deck composition, specifically deck composition number 1. Therefore, if an operation is performed to reflect a deck history that includes returned characters in the registered deck composition number 1, you can choose not to accept that operation on the screen that reflects the deck history.

[0081] <Summary> According to the embodiment described above, by enabling players to lend and borrow characters from each other, for example, a beginner who has just started playing the game can borrow a powerful character from a veteran player they know to take on quests. Veteran players can also lend characters they don't normally use to beginner players. This will stimulate communication among players and increase the chances of clearing even difficult quests, thus helping players maintain their motivation to continue playing the game.

[0082] On the other hand, if beginner players could always borrow powerful characters from veteran players, it would be the same as beginner players owning powerful characters from the start, potentially disrupting the game balance. Therefore, in this embodiment, the lending and borrowing of characters is limited to players who are registered as friends and who are physically close to each other. This ensures that character borrowing is only permitted in limited circumstances, thus preventing the disruption of the game balance.

[0083] The embodiments described above are provided to facilitate understanding of the present invention and are not intended to limit its interpretation. The flowcharts, sequences, elements, and their arrangement, materials, conditions, shapes, and sizes described in the embodiments are not limited to those exemplified and can be modified as appropriate. Furthermore, configurations shown in different embodiments can be partially substituted or combined. [Explanation of Symbols]

[0084] 1...Game system, 10...Game server, 11...CPU, 12...Storage device, 13...Communication interface, 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 receives a designation from the first player's terminal, which is used by the first player, of a character to be lent out from among the characters owned by the first player. A second control unit receives a request from the second player's second terminal to borrow the character subject to the loan from the first player, A game control unit that sets the first player unable to use the borrowed character in the game while the second player is borrowing the borrowed character, A game device having a game device.

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

3. The second control unit controls the second terminal to display a screen for receiving the request when the first terminal and the second terminal are within a predetermined distance of each other. The game device according to claim 1 or 2.

4. The first control unit receives a designation from the first terminal of a candidate player who is authorized to borrow the character to be borrowed. The second control unit controls the second terminal to display a screen for accepting the request when the first player designates the second player as the candidate player for loan. The game device according to any one of claims 1 to 3.

5. The second control unit controls the system so that when the second player plays a game using the character to be lent, it does not accept any operation from the second player to change the attributes of the character to be lent. The game device according to any one of claims 1 to 4.

6. The game control unit performs a process to return the character to the first player when a predetermined period has elapsed since the second player began borrowing the character. The game device according to any one of claims 1 to 5.

7. A game processing method executed by a game device, The game device receives a request from the first player, via a first terminal used by the first player, to specify a character to be lent out from among the characters owned by the first player. The game device receives a request from a second terminal used by the second player to borrow the character to be lent from the first player, The game device is configured in such a state that the first player cannot use the character to be rented in the game while the second player is using the character to be rented. A game processing method having

8. On the computer, The first player uses a first terminal to receive a designation of a character to be lent from among the characters owned by the first player, The second player receives a request from a second terminal used by the second player to borrow the character to be lent from the first player, The steps include: setting the first player in a state where he cannot use the borrowed character in the game while the second player is borrowing the borrowed character; A program to execute.

Images