JP2020189177A - Game device, game processing method, and program - Google Patents

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

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

In recent years, players have been using groups that combine multiple characters they possess.
An online game that clears missions called quests is provided (for example, Patent Document 1).

JP-A-2015-134036

In such online games, quests of various difficulty levels are offered, and it is configured so that you can obtain rarer (rare) items and characters by clearing the quests with higher difficulty levels. Often there are.

However, for example, immediately after the player starts the game, the status and skill of the possessed character are generally low. Then, the player can only complete a limited number of low-difficulty quests, which may discourage him from playing the game.

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 his / her willingness to play a game.

In the game device according to one aspect of the present invention, the first control unit that accepts the designation of the character to be rented from the characters possessed by the first player from the first terminal used by the first player, and the second player The second control unit that receives a request to borrow the character to be rented from the first player from the second terminal to be used, and the first player rents out while the second player borrows the character to be rented. It has a game control unit that sets the target character so that it cannot be used in the game.

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 his / her willingness to play a game.

It is a figure which shows an example of the system structure of the game system which concerns on this embodiment. It is a figure which shows an example of the screen which performs deck organization. It is a figure which shows an example of the hardware configuration of a game server and a terminal. It is a figure which shows an example of the functional block composition of a game server. It is a figure which shows an example of a player management DB and an example of possession character management DB. It is a figure which shows an example of the functional block composition of a terminal. It is a flowchart which shows an example of the processing procedure at the time of designating a character to be lent and a candidate player for rent. It is a figure which shows an example of the screen which accepts the designation of the character to be lent. It is a figure which shows an example of the screen which accepts the designation of a loan candidate player. It is a flowchart which shows an example of the processing procedure at the time of borrowing a character. It is a figure which shows an example of the screen which accepts the borrowing of a character. It is a figure which shows an example of a character list screen and a character detail screen.

Preferred embodiments of the present invention will be described with reference to the accompanying drawings. In each figure, those having the same reference numerals have the same or similar configurations. The present embodiment can be applied to a game in which a player (which may be called a user) owns a plurality of characters and the player can train the characters by clearing the quest. Any game in which a character can be owned and trained can be applied to role-playing games, action games, puzzle games, shooting games, and the like.

<System configuration>
FIG. 1 is a diagram showing an example of the system configuration of the game system 1 according to the present 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 terminal 20 are the Internet, an intranet, or a wireless LA.
N, they are connected to each other so as to be able to communicate with each other via a communication network N such as mobile communication.

The game server 10 is a device that plays a part of the functions of the terminal 20 in providing the game, such as managing various information about the player and executing a part of the game. The game server 10 may be composed of one or a plurality of information processing devices.
It may be configured using a virtual server (cloud server, etc.).

The terminal 20 is a terminal that provides a game to a player, and the player can execute the game according to the present 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 is a GPS (Glo)
The game server 10 is notified of its own position detected by using the bal Positioning System) or the like.

<Game overview>
Subsequently, an outline of the game provided by the game system 1 according to the present embodiment will be described. In the game provided by the game system 1 (hereinafter referred to as "this game"), the player organizes a deck with a character selected from a plurality of possessed characters, and uses the organized deck to perform a quest. By clearing it, you can get new characters and items. In addition, the player can challenge more difficult quests by synthesizing multiple acquired characters to grow into stronger characters, or by using items to strengthen the character's attributes. ..

Here, the quest is a term meaning a mission whose clearing condition is to satisfy a certain predetermined condition. Quests are sometimes called explorations or tasks. The player who participated in the quest can clear the quest by satisfying the certain conditions, and when the quest is cleared, the player is rewarded and the story of this game progresses.

The deck is a term that means a group in which a plurality of characters are combined.
When challenging a quest, the player can advance the quest in an advantageous manner by selecting a character having an ability suitable for clearing the quest and organizing a deck. FIG. 2 shows an example of a screen for organizing a deck. As shown in FIG. 2, the player selects three characters to form a deck. In this game, the player operates four characters, which are the three characters (main, sub 1, sub 2) included in the deck formation, plus one character of another player, to become an enemy monster. fight.

The player can register friends with other players. Friend registration means that players build a predetermined relationship in advance in this game. In this game, one player sends a request to the other player to register as a friend, and the other player who receives the request approves the request, so that friend registration is performed between the players. In this game, when playing in cooperation between players who have registered friends, compared to when playing between players who have not registered friends,
The rewards that can be obtained will increase.

In this game, a mechanism for allowing the lending and borrowing of characters between players is provided. A player who lends a character (borrows a character) (hereinafter, referred to as a “lending player”) can incorporate the borrowed character into a deck formation and use it. On the other hand, the player who rents out the character (hereinafter referred to as "lending source player") cannot use the rented character until the rented character is returned. The rented character is automatically returned to the renting player after a predetermined period of time has passed.

<Hardware configuration>
FIG. 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 include a CPU (Central Processing Unit) 11, a memory, and H.
Storage device 12 such as DD (Hard Disk Drive) and / or SSD (Solid State Drive), communication IF (Interface) 13 for wired or wireless communication, input device 14 for accepting input operations, and output device for outputting information. Has 15. The input device 14, for example,
A keyboard, touch panel, mouse and / or microphone, etc. The output device 15 is, for example, a display and / or a speaker.

<Functional block configuration>
FIG. 4 is a diagram showing an example of a functional block configuration of the game server 10. Game server 1
0 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 the program stored in the storage device 12. In addition, the program can be stored in a storage medium. The storage medium containing the program is a non-transitory computer readable medium.
) May be. The non-temporary storage medium is not particularly limited, but may be, for example, a storage medium such as a USB memory or a CD-ROM. Further, the storage unit 103 is a game server 10.
It can be realized by using the storage device 12 provided in.

The terminal control unit 101 controls the processing performed on the terminal 20 side regarding the game by generating information necessary for executing the game and transmitting it to the terminal 20. For example, when displaying a screen for displaying a list of characters possessed by the player on the terminal 20, the terminal control unit 10
1 transmits data (latest status of each character, etc.) necessary for generating the screen to the terminal 20. Further, the terminal control unit 101 receives various instructions received from the player by the terminal 20 from the terminal 20, and passes the received instructions to the game control unit 102. When a plurality of terminals 20 (first terminal 20, second terminal 20) exist in the game system 1, the first terminal 20 is present.
The terminal control unit 101 that controls the terminal 20 may be referred to as a first control unit, and the terminal control unit 101 that controls the second terminal 20 may be referred to as a second control unit.

In addition, the terminal control unit 101 (first control unit) is a character to be rented (hereinafter, "character to be rented") from the terminal 20 (first terminal) used by the lending source player (first player).
Say. ) Is accepted and the game control unit 102 is notified. In addition, the terminal control unit 101
(Second control unit) receives a request from the terminal 20 (second terminal) used by the lending destination player (second player) to borrow the character to be rented, and notifies the game control unit 102.

Further, the terminal control unit 101 displays a screen for accepting a request to borrow a character when the lending source player and the lending destination player are associated with each other in a predetermined relationship (for example, when registered as a friend). It may be displayed on the terminal 20 of the lending player.

Further, the terminal control unit 101 displays a screen for accepting a request for borrowing a character when the terminal 20 used by the lending source player and the terminal 20 of the lending destination player are within a predetermined distance. It may be displayed on the terminal 20 of the above.

Further, the terminal control unit 101 accepts the designation of a player (hereinafter, referred to as a “lending candidate player”) that permits the lending target character from the terminal 20 used by the lending source player, and the game control unit 101. 102 may be notified. In addition, the terminal control unit 101
May display on the terminal 20 of the lending destination player a screen for accepting a request for borrowing a character when the lending destination player is designated as a lending candidate player by the lending source player.

Further, the terminal control unit 101 may control so as not to accept the operation of changing the attribute of the borrowed character by the lending player during the execution of the game. For example, the terminal control unit 101 may control so as not to display the borrowed character on the screen that accepts the operation of changing the attribute. Here, the attributes include, for example, the character's status (eg, level, attack power, rack, HP, etc. described later), skill (eg, special attack ability, etc.) and the like.

The game control unit 102 provides a function performed on the game server 10 side among various functions required for executing the game. For example, the game control unit 102 has a function of releasing new quests, new monsters, and the like according to the progress of each player's game, a function of managing characters possessed by each player, and various types performed by each player in the game. A function for managing the settings and the like, a function for managing the lending and borrowing of characters between players, a function for backing up game data possessed by the terminal 20, and the like are provided.

Further, in the game control unit 102, while the character is rented out, the lending source player
Performs a process to set the rented character so that it cannot be used in the game.
Further, the game control unit performs a process of returning the character to the lending source player when a predetermined period has elapsed since the lending player started borrowing the character.

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

FIG. 5A is a diagram showing an example of a player management DB. The player management DB shown in FIG. 5A shows game data necessary for the description of the present embodiment, and may include game data (not shown). The "player ID" is an ID that uniquely identifies a player in this game. The "nickname" is an in-game name (name) set by the player.

In the "friend list", the player ID of the player registered as a friend is stored. Here, the "position information" is position information indicating the current position of the terminal 20 used by the player.
The "experience value" is the experience value of the player, and a predetermined experience value is added each time the quest is cleared. In this game, the higher the difficulty level of the quest, the more experience points you can get. "Rank" is the status of the player determined according to the experience value, and when the rank becomes higher, quests limited to players of a predetermined rank or higher can be played, new items and monsters obtained are released. It is done.

"Stamina" is a parameter 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 it can also be forcibly recovered by using a specific item.

FIG. 5B is a diagram showing an example of the possessed character management DB. "Player ID" is
It is an ID indicating a player who possesses a character. The "character ID" is an ID that uniquely identifies a character possessed by the player. In this game, the player can have a plurality of characters of the same type, and can raise the status of the characters by synthesizing the characters of the same type. The character ID may be an ID that is a combination of an ID that uniquely identifies the character type and an ID that uniquely identifies the same type of character possessed by the player. In the example of FIG. 5B, 1105-003 indicates that the character is the third character obtained among the characters whose character type is 1105.

"Level" indicates the level of the character. As the level goes up, the character's HP, attack power, and speed go up. The upper limit of the level depends on the degree of rarity (rareness) of the character. The higher the degree of rarity, the higher the upper limit of the level. "
"Rack" indicates the amount of luck that the character has. Rack (luck) is increased by synthesizing characters of the same type. The more racked characters you organize into your deck, the more likely you are to get more items by completing quests.

"HP (hit point)", "attack power" and "speed" are status values indicating the vitality and attack ability of the monster. "Status enhancement / skill enhancement" indicates the status of granting items that enhance the character's status and skills. The "lending / borrowing flag" is a character that can be rented to a specified player (waiting for lending), a character that is rented to another player (renting), or a character borrowed from another player (rental).
It is a flag indicating either (borrowing) or a character that does not correspond to either (no setting). Character ID is 1 for "Waiting for lending (Lending candidate: 0101)"
It shows that the character of 010-001 can be lent to the player whose player ID is 0101. "Character ID is 1 while borrowing (lending destination: 0103)
It indicates that the character 100-001 is in a state of being rented out to the player whose player ID is 0103.

In the present embodiment, the game control unit 102 may provide the function provided by the terminal control unit 101, or the terminal control unit 101 may provide the function provided by the game control unit 102. Good. That is, the function provided by the terminal control unit 101 and the game control unit 10
The function provided by 2 is not limited to the division described in the present embodiment, and may be divided in any way.

FIG. 6 is a diagram showing an example of the functional block configuration of the terminal 20. The terminal 20 is a communication unit 20.
1, UI (User Interface) unit 202, game control unit 203, and storage unit 204 are included. The communication unit 201, the UI unit 202, and the game control unit 203 are the CPU 11 of the terminal 20.
However, this can be realized by executing the program stored in the storage device 12.
In addition, the program can be stored in a storage medium. The storage medium that stores the program is a computer-readable non-transitory storage medium (Non-transitory compute).
r readable medium) may be used. The non-temporary storage medium is not particularly limited, but may be, for example, a storage medium such as a USB memory or a CD-ROM. Further, the storage unit 204 can be realized by using the storage device 12 included in the terminal 20.

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

The UI unit 202 has a process of receiving various inputs from the player and a function of displaying various game screens on the display. Further, the UI unit 202 displays the game screen according to the 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.

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 has a function of calculating the amount of damage received by an ally character due to an attack from an enemy character, a function of notifying the game server 10 of the calculated amount of damage, and for backing up game data possessed by the terminal 20. It provides a function of transmitting to the game server 10.

The storage unit 204 stores game data necessary for the game control unit 203 to execute the game. Character image data, game scenarios, and the like are stored in the game data.

<Details of processing procedure>
Subsequently, in the game system 1, the processing procedure when the character is lent or borrowed will be described.

(Designation of lending target character and lending candidate player)
In this game, the player who allows the lending of the character specifies in advance the lending target character and the lending candidate player.

FIG. 7 is a flowchart showing an example of a processing procedure when designating a lending target character and a lending candidate player.

In step S10, the UI unit 202 of the terminal 20 accepts the selection of the character to be rented from the characters possessed by the player on the screen showing the list of characters possessed by the player. Subsequently, in step S11, the communication unit 201 of the terminal 20 transmits information indicating the character that has accepted the selection to the game server 10. Terminal control unit 1 of the game server 10
01 receives the information from the terminal 20 and sets the “lending / borrowing flag” of the lending target character in the possessed character management DB to the lending waiting.

FIG. 8 is a diagram showing an example of a screen that accepts the designation of the character to be lent. First, when the button B10 for making various settings related to character lending, which is displayed on the menu screen A10 related to character lending and borrowing, is pressed, the screen transitions to the character lending setting menu screen A11. Next, when the button B11 for designating (or changing) the character to be rented is pressed on the screen shown in A11, the screen transitions to the screen A12 in which the characters possessed by the player are displayed in a list. When the player selects a character to be rented on the screen A12, the 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.

In step S12, the UI unit 202 of the terminal 20 accepts the selection of the loan candidate player on the screen showing the list of the players registered as friends. In step S13, the terminal 20
Communication unit 201 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.

FIG. 9 is a diagram showing an example of a screen that accepts the designation of a loan candidate player. First, when the button B10 displayed on the menu screen A10 is pressed, the screen transitions to the setting menu screen A11 related to character lending. Next, on the screen shown in A11, when the button B21 for setting (or changing) the loan candidate player is pressed, the screen A22 displaying a list of the players and the 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.

When a loan candidate player is specified on the screen A22, the screen transitions to the screen A23 indicating that the loan is being solicited. In this state, when the lending candidate player selected on the screen A22 borrows the lending target character, the icon of the lending character is displayed in grayed out in the display area B23 of the menu screen A11. In addition, the time until the rented character is returned is displayed near the icon.

The game control unit 102 may limit the number of characters that the player can lend at the same time to one. In order to enable such restrictions, the terminal control unit 101 causes the terminal 20 to display a screen on which only one character to be rented can be selected for the screen (FIG. 8) for accepting the designation of the character to be rented. May be good. In addition, the terminal control unit 101
Regarding the screen (FIG. 9) for accepting the designation of the loan candidate player, the terminal 20 may display a screen in which only one loan candidate player can be selected.

(Character borrowing)
In this game, when a friend is registered with the lender player and the lender player and the lender player are within a predetermined range, the borrowing of the character is permitted.

FIG. 10 is a flowchart showing an example of a processing procedure when the character is borrowed.

In step S20, the terminal control unit 101 of the game server 10 receives a request for borrowing the character to be rented from the terminal 20 of the player who wants to borrow the character.
Subsequently, the game control unit 102 of the game server 10 searches the player management DB, exists within a predetermined distance from the current position (current position of the terminal 20) of the player who wishes to borrow, and is registered as a friend. Search for players. If the player does not exist, the process ends, and if the player exists, the process proceeds to step S21.

In step S21, the game control unit 102 searches for a player who has registered a player (lending destination player) who wants to borrow a character as a lending candidate player among the friend registered players searched in the processing procedure of step S20. .. More specifically, the game control unit 102 accesses the possessed character management DB, and sets the "lending / borrowing flag" in each record of the character owned by each friend registered player searched in the processing procedure of step S20 to "waiting for lending". "And, it searches whether there is a record in which the player ID of the player who wants 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. On the screen, a list of characters designated as lending target characters by the lending source player searched in step S21 is displayed. Also, the UI of the terminal 20
The unit 202 notifies the game server 10 of the character specified on the screen. Upon receiving the notification, the terminal control unit 101 accepts the designation of the character to be borrowed by the lending 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 “borrowing flag” of the character record borrowed by the lending player in the possessed character management DB to “borrowing”.

FIG. 11 is a diagram showing an example of a screen for accepting the borrowing of a character. On the menu screen A10 regarding lending and borrowing of characters, button B for accepting borrowing of characters
When 30 is pressed, the screen transitions to the screen A31 indicating that the borrowable character is being searched. When the search for borrowable characters is completed, the screen A32 for displaying the list of borrowable characters is displayed. In the example of FIG. 11, one character B31 is displayed on the screen A32 that displays a list of borrowable characters. The case where a plurality of characters are displayed on the screen is a case where there are a plurality of lender players who have set the player who is referencing the screen as a lending candidate player.

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

In addition, if the password (keyword) for lending the character is specified in advance from the lending player, and the password entered by the lending player matches the password specified by the lending player, the character Borrowing may be allowed.

In this case, the terminal control unit 101 accepts the designation of the password (keyword) when lending the character from the lending source player in the processing procedure of step S10 or step S12 of FIG. 7, and registers it in the possessed character management DB. deep. Subsequently, the terminal control unit 101 accepts the designation of the password from the lending player in the processing procedure of step S22 of FIG. 10, and terminals only the lending target character of the lending source player who has specified the password matching the accepted password. 20
May be displayed on the screen (screen A32 of FIG. 11). An example of an input box that accepts a password designation from a lender player is shown in the upper right of the screen A31 of FIG.

The game control unit 102 may limit the number of characters that the player can borrow at the same time to one. In order to enable such restrictions, the terminal control unit 101 displays the button B30 on the screen for accepting the borrowing of the character (screen A10 in FIG. 11) while the player has already borrowed the character. You may let it.

(Processing related to lending player)
The terminal control unit 101 and the game control unit 102 control the lending source player so that the lending character cannot be used from the time the lending target character is lent to the lending player until it is returned. For example, when the lending source player selects a rented character and tries to perform a predetermined action, the terminal control unit 101 causes the terminal 20 to display an error message that the predetermined action cannot be performed. You may. Alternatively, the button for accepting the execution of the predetermined action may be displayed on the terminal 20 in a state in which the player cannot press it (for example, a grayout display).

Specifically, the prescribed actions are the act of incorporating the rented character into the deck formation, the act of incorporating the rented character into the deck formation and dispatching to the quest, the act of synthesizing the rented character and other characters. (Including the act of setting automatic composition), the act of giving an item whose status or skill is enhanced to the rented character, the act of selling the rented character, and the like. Further, the act of deleting the lending destination player who lends the character from the friend registration may also be restricted.

The terminal control unit 101 may display the rented character in gray out on various game screens on the lending source player side, or a character string indicating that the rented character is "rented" or A label may be added and displayed.

The rented character may be forcibly returned according to the instruction of the renting player. If a quest using the rented character is being executed when the instruction of the lending source player is received, the use of the rented character is permitted until the running quest is completed. After the quest being executed is completed, the use of the rented character may be restricted (disabled). Then, when the rented character is forcibly returned, the lending player can execute the quest using the character even while the lending player is using the character in the quest. It will be possible. Further, the rented character may be returned to the lending source player according to the instruction of the lending destination player.

Among the quests provided in this game, there are special quests that must be cleared by clearing all of the multiple subquests. In the special quest, the character used to clear any one of the multiple subquests is sealed and cannot be used in other subquests. However, in this embodiment,
It may be allowed to lend the sealed character.

In this game, there are parameters determined according to the total number of characters possessed and the total number of characters having a predetermined status. The parameter may not change even when the character is rented.

In this game, there is a function of increasing the HP of the character according to the number of times the character is used. Regarding this function, when the lending player uses the rented character, it may not be counted in the number of uses.

The game control unit 102 of the game server 10 prepares for a model change or failure of the terminal 20.
It has a function to back up game data. When the lending player restores the game data backed up while lending the character, the time until the character is returned may be restored as it is. For example, if the game data backed up when the time until the character is returned is 24 hours is restored 36 hours after the backup, the time until the character is returned will remain at 24 hours. You may do it.

(Processing related to lending player)
The game control unit 102 allows the lender player to freely incorporate the borrowed character into the deck formation. In addition, the lender player is allowed to return the borrowed character at an arbitrary timing.

The terminal control unit 101 may add a character string or a label indicating "renting" to the borrowed character and display it on various game screens on the lending destination player side. A concrete example is shown with reference to a figure. FIG. 12A is an example of the character list screen. FIG. 12
On the screen shown in (a), a tag B40 indicating that the character is borrowed is displayed. FIG. 12B is an example of a character detail screen. On the screen shown in FIG. 12B, a tag B41 indicating that the displayed character is borrowed is displayed.

In this game, missions are prepared that are achieved by collecting a large number of characters that appear in the game, but borrowed characters may not be counted as collection targets in the mission.

In this game, titles are given according to the maximum number of hits on the enemy character in one attack action and the maximum number of damages inflicted on the enemy character in one attack action. However, if the decked characters include borrowed characters, these maximums may not be updated.

As mentioned above, some of the quests provided in this game have specifications that the character is sealed and cannot be used in other subquests. However, the borrowed character may not be sealed even if the subquest is cleared.

The status and skill of the character being borrowed may be the same as the status and skill immediately before borrowing, or may be the status and skill immediately before borrowing plus a predetermined weight and a predetermined skill.

When the lending player selects a borrowed character and tries to perform a predetermined action, the terminal control unit 101 sends an error message that the predetermined action cannot be performed.
The button for accepting the execution of the predetermined action may be displayed on the terminal 20 in a state in which the player cannot press the button (for example, grayed out display).

Specifically, the prescribed actions are the actions of synthesizing a borrowed character and other characters (including the actions of setting automatic synthesis), and various actions of changing stats and skills (for example, items that enhance stats). , Etc.), selling the rented character, etc. Further, the act of deleting the lender player who borrows the character from the friend registration may also be restricted.

In this game, in order to easily change the deck formation according to the characteristics of the quest, a function that allows the deck formation of a plurality of patterns to be registered in advance is provided. If the registered deck formation includes a returned character, the terminal control unit 101 or the game control unit 102 sets the character when displaying the registered deck formation on the screen of the terminal 20. The position may be displayed in the sky, or another character may be set automatically. In the latter case, the character acquired earliest may be set as the other character, or a randomly selected character may be set. In this game, among the registered deck formations, all characters must be set for the deck formation with registration number 1. Therefore, another character may be automatically set for the deck organization of registration number 1.

When the lending player restores the game data backed up while borrowing the character, the game control unit 102 may restore the game data without changing the time until the character is returned. For example, if the game data backed up when the time until the character is returned is 24 hours is restored 36 hours after the backup, the time until the character is returned will be 24 hours. You may do it.

In this game, a function is provided in which the deck formation at the time of clearing the quest is recorded as a deck history, and the recorded deck history can be reflected in any of the above-mentioned registered deck formations. If there is a deck history that includes the returned character, the operation to reflect the deck history in the deck formation may not be accepted, or the position where the returned character was set may be emptied. May be good. As described above, among the registered deck formations, all characters must be set for the deck formation with registration number 1. Therefore, when an operation for reflecting the deck history including the returned character in the deck organization of the registration number 1 is performed, the operation may not be accepted on the screen for reflecting the deck history.

<Summary>
According to the embodiment described above, it is possible to lend and borrow characters between players, for example, a beginner who has just started this game can take on a quest by borrowing a powerful character from a familiar veteran layer. It will be possible. Also, for the veteran layer, it is possible to lend a character that is not normally used to a beginner player. This activates communication between players and increases the possibility of clearing even difficult quests, so it is possible for players to continue their motivation to continue playing the game. become.

On the other hand, if a novice player can always borrow a strong character from the veteran layer, it will be the same as a novice player owning a strong character from the beginning, and the game balance may be lost. There is. Therefore, in the present embodiment, the players who can lend and borrow the character are limited to the players registered as friends and the players who are physically close to each other. As a result, the borrowing of the character is allowed only in a limited situation, and it is possible to prevent the game balance from being lost.

The embodiments described above are for facilitating the understanding of the present invention, and are not for limiting and interpreting the present invention. The flowchart, sequence, each element included in the embodiment, its arrangement, material, condition, shape, size, and the like described in the embodiment are not limited to those exemplified, and can be appropriately changed. In addition, the configurations shown in different embodiments can be partially replaced 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 (8)

From the first terminal used by the first player, the first control unit that accepts the designation of the character to be rented from the characters possessed by the first player, and
A second control unit that receives a request from the second terminal used by the second player to borrow the character to be rented from the first player.
While the second player borrows the character to be rented, the game control unit sets the character to be rented so that the first player cannot use the character to be rented in the game.
Game device with. 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.
The game device according to claim 1. The second control unit is used when the first terminal and the second terminal are within a predetermined distance.
Control so that the screen for accepting the request is displayed on the second terminal.
The game device according to claim 1 or 2. The first control unit receives from the first terminal the designation of a lending candidate player who permits the lending of 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 designates the second player as the lending candidate player.
The game device according to any one of claims 1 to 3. The second control unit controls the second player so as not to accept an operation of changing the attribute of the character to be rented from the second player when playing a game using the character to be rented. ,
The game device according to any one of claims 1 to 4. The game control unit performs a process of returning the character to be rented to the first player when a predetermined period has elapsed since the second player started borrowing the character to be rented.
The game device according to any one of claims 1 to 5. A game processing method executed by a game device,
A step in which the game device accepts the designation of the character to be rented from the characters possessed by the first player from the first terminal used by the first player.
A step in which the game device receives a request from the second terminal used by the second player to borrow the character to be rented from the first player.
While the game device borrows the character to be rented by the second player,
A step of setting the character to be rented so that the first player cannot use it in the game, and
A game processing method having. On the computer
A step of accepting the designation of a character to be rented from the characters possessed by the first player from the first terminal used by the first player, and
A step of receiving a request from the second terminal used by the second player to borrow the character to be rented from the first player, and
While the second player is borrowing the character to be rented, the first player is set to a state in which the character to be rented cannot be used in the game.
A program to execute.