JP2015198857A - Game server, game control method, game program, game program recording medium, and game system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a game server, game control method for controlling progress of a game provided by the game server, game program, recording medium in which the game program is recorded, and game system capable of enhancing a real user's interest in a run game by putting thought to a method for recovering a virtual user whose progress of the run game is stopped.SOLUTION: A rescue requirement acceptance unit 43 accepts operation data showing that a rescue requirement is performed, from a terminal operating one virtual user. A rescue requirement notification unit 45, when the rescue requirement acceptance unit has accepted the rescue requirement, notifies a terminal operating another virtual user that the rescue requirement has been performed by the one virtual user. A restoration setting unit 46, when having received operation data for rescuing the one virtual user from the terminal operating the other virtual user, restores the one virtual user to a state capable of its progress.

Description

  The present invention relates to a game server that manages the operation of a virtual user existing in a virtual space by operation data from each terminal connected via a communication network, a game control method that controls the progress of a game provided by the game server, The present invention relates to a game program, a game program recording medium, and a game system.

  Conventionally, there is a run game in which a real user operates a virtual user existing in a virtual space, runs the virtual user displayed on the screen in the virtual space, and records the distance traveled. For example, in Patent Document 1, during a game, a virtual user automatically moves in a virtual space toward the back of the screen without an actual user operation. Obstacles such as trees and stumps are arranged in the virtual space, and the real user moves the virtual user left and right on the screen or jumps the virtual user so that the virtual user does not hit the obstacle. Can be performed.

JP 2008-209142 A

  However, in the conventional run game, if the progress of the virtual user is stopped under a predetermined condition such as when the virtual user hits an obstacle, the game is over, and the real user restarts the game from the beginning or within the game. There was no choice but to revive virtual users with available items. Thus, in the form where a real user plays a game alone, there is a problem that a boring impression such as a feeling of work and feeling of feeling is given.

  The present invention has been made in view of the above-described problems, and a game server capable of enhancing the interest of a real user game by devising a method for reviving a virtual user whose progress has stopped in a run game. An object of the present invention is to provide a game control method for controlling the progress of a game provided by a game server, a game program, a game program recording medium recording the game program, and a game system.

  In order to solve the conventional problems described above, the present invention has the following means.

(1) A game server according to the present invention is a game server that provides a game in which a virtual user formed on a game provided to a terminal connected via a communication network advances a predetermined course, An operation data receiving unit that receives operation data for operating the virtual user from the terminal, a progress management unit that advances or stops the progress of the virtual user in the predetermined course based on the operation data; When the progress of the virtual user is stopped, a rescue request reception for receiving a rescue request for allowing the one virtual user to proceed again based on operation data of a terminal that operates the one virtual user And when the rescue request accepting unit accepts the rescue request, the virtual user operates the other virtual user that the rescue request is received from the one virtual user. When the operation data for relieving the one virtual user is received from the rescue request notifying unit for notifying the terminal and the terminal for operating the other virtual user, the one virtual user is restored to a state capable of proceeding. And a resurrection setting section for enabling.

  In the above aspect, when the progress of one virtual user stops, the real user who operates the one virtual user can make a rescue request so that the one virtual user can proceed again. When a real user makes a rescue request and another real user who operates another virtual user responds to the rescue request, one virtual user can proceed. Even if the progress of one virtual user stops, the real user has a chance to allow the one virtual user to proceed again, so that it is not necessary to restart the game from the beginning, and the work feeling can be wiped out. In addition, unlike the case where a virtual user is revived using an in-game item, even if the real user makes a rescue request, it is uncertain whether there is another real user who responds to the rescue request. It is not always possible to restore a single virtual user. Therefore, the real user who made the rescue request can have a sense of expectation as to whether there is another real user who responds to the rescue request.

(2) In a preferred aspect of the game server according to the present invention, when the other virtual user reaches a position where the progress of the one virtual user has stopped in the predetermined course, Operation data for relieving the one virtual user is received.

  In the above aspect, in order for another real user who operates another virtual user to respond to the rescue request, it is necessary to cause the other virtual user to reach a stop position where the progress of one virtual user is stopped. . Even if another real user intends to respond to the rescue request, the progress of the other virtual user may stop before the other virtual user reaches the stop position. Even if a real user makes a rescue request, it is uncertain whether other real users can bring other virtual users to the stop position, and one virtual user can always be revived. Not exclusively. It is possible to give a sense of expectation to a real user who has made a rescue request whether or not a virtual user who can respond to the rescue request will reach the stop position. Also, the difficulty level of the game is improved compared to the case where other real users can respond to the rescue request by simply pressing one button on the screen without causing other virtual users to reach the stop position. And the work feeling can be wiped out more.

  Moreover, in this aspect, when there are a plurality of other real users who have received the notification of the rescue request, the virtual user that has reached the stop position where the progress of one virtual user is stopped among the plurality of real users is the earliest The real user who operates can respond to the rescue request. However, even if another real user intends to respond to the rescue request, the progress of the other virtual user may stop before the other virtual user reaches the stop position. Therefore, the real user who operates the virtual user who is traveling the position closest to the stop position among the plurality of real users cannot always respond to the rescue request. Therefore, it is possible to give a sense of expectation to a plurality of real users who have received the notification of the rescue request whether or not they can respond to the rescue request.

(3) In a preferred aspect of the game server according to the present invention, the game server further includes a user extraction unit that extracts a virtual user that satisfies a predetermined condition as the other virtual user based on the information about the one virtual user, The rescue request notifying unit notifies the terminal operating the extracted virtual user that a rescue request has been received from the one virtual user.

  In the above aspect, a user extraction part extracts the virtual user which satisfy | fills predetermined conditions as another virtual user based on the information regarding one virtual user. For example, the user extraction unit extracts a virtual user having an evaluation value within a predetermined range from the evaluation value of one virtual user based on the evaluation value information of the one virtual user. That is, a virtual user having an evaluation value comparable to the evaluation value of one virtual user is extracted. The evaluation value is a parameter for evaluating a virtual user in the game, and is, for example, a level or a ranking. Further, for example, based on friend information of one virtual user, a virtual user who has a friend relationship with one virtual user is extracted. The friend relationship is a relationship that is established when one person applies for a friend in the game and the other approves it. By extracting a virtual user that satisfies a predetermined condition in relation to information related to one virtual user, it is possible to increase the probability that the real user who has received the notification of the rescue request responds to the rescue request. When the probability of responding to a rescue request increases, the frequency of exchange between virtual users in the game increases, and the game can be activated.

(4) In a preferred aspect of the game server according to the present invention, a user notification unit that notifies the extracted information about the virtual user to a terminal that operates the one virtual user, and a terminal that operates the one virtual user. A user selection receiving unit that receives a selection request for selecting any one of the extracted virtual users based on operation data, and the rescue request notification unit operates the selected virtual user The terminal is notified that a rescue request has been received from the one virtual user.

  In the above aspect, the real user who made the rescue request can know the information about the virtual user extracted by the user extraction unit, and can select one virtual user from the virtual users extracted by the user extraction unit. it can. By causing the real user who has made a rescue request to select a virtual user who wants to respond to the rescue request, the willingness to respond to the rescue request of the real user who has received the rescue request notification can be enhanced.

(5) In a preferred aspect of the game server according to the present invention, the user extraction unit determines and determines the number of virtual users to be extracted according to the number of virtual users rescued by the one virtual user in the past. It is characterized by extracting a number of virtual users.

  In the above aspect, for example, as the number of virtual users rescued in the past increases, the user extraction unit extracts more virtual users. And a relief request notification part notifies that there were relief requests to many virtual users which the user extraction part extracted. If the number of real users who have received the notification of the rescue request is large, the number of real users who respond to the rescue request also increases. In order to have another real user respond when he / she makes a rescue request, the real user can be prompted to respond positively to a rescue request from another real user.

(6) In a preferred aspect of the game server according to the present invention, the time when the rescue request notifying unit notifies the terminal operating the other virtual user that there is a rescue request from the one virtual user, and the other And a reward setting unit for setting a reward for the other virtual user according to a difference in time when the operation data for rescue of the one virtual user is received from a terminal that operates the virtual user.

  In the above aspect, for example, the smaller the difference between the time at which the virtual user has been informed of the rescue request and the time at which the virtual user has responded to the rescue request, the higher reward is given to the virtual user. Is granted. The reward is, for example, an item that can be used in the game. Items that are advantageous for progressing the game have a high value, and real users have a high desire for acquisition. The real user can be prompted to respond more quickly to the notification of the rescue request. The frequency of exchange between virtual users in the game increases, and the game can be activated.

  On the other hand, a reward with higher value may be given to the virtual user as the difference between the time when the virtual user is notified that the rescue request is made and the time when the virtual user responds to the rescue request is larger. In this case, for a real user, in order to obtain a reward with higher value, it is desirable to respond after a while after receiving a notification of a rescue request. However, if time passes after receiving the notification of a rescue request, there is a high possibility that other real users will respond to the rescue request and cannot receive a reward. It is possible to give pleasure to think about the timing of responding to the rescue request to the actual user as to when to respond to the rescue request.

(7) In a preferred aspect of the game server according to the present invention, the rescue request notification unit receives the rescue request from the one virtual user during a predetermined period and a response that the one virtual user responds to the rescue request. According to the ratio of the number of times, a probability of notifying that there is a rescue request from the one virtual user is set, and notification is made based on the set probability.

  In the above aspect, for example, in the case where the number of receptions received from the virtual user during the predetermined period is much larger than the number of responses that the virtual user responded to the relief request during the predetermined period, the rescue request is received from the virtual user. The probability of notifying that there has been set is set low. Thereby, a real user can be urged to respond positively to a rescue request from another real user.

  In any aspect, the present invention as described above relates to a game control method for controlling the progress of a game provided by the game server, a game program, a game program recording medium on which the game program is recorded, and a game program recording medium. It can also be understood as a game system.

  ADVANTAGE OF THE INVENTION According to this invention, the progress of the game provided with the game server which can heighten the interest with respect to a game of a real user, and a game server can be improved by devising the method to revive the virtual user who progressed in the run game. A game control method for controlling, a game program, a game program recording medium recording the game program, and a game system can be provided.

It is a figure which shows the system configuration | structure of the game system to which this invention was applied. It is a figure which shows the hardware constitutions of the game server to which this invention was applied. It is a figure which shows the structure of each process part which the game server to which this invention was applied performs. It is a figure for demonstrating the specific example of a progress management data table. It is a figure for demonstrating the specific example of a relief request reception log | history data table. It is a figure for demonstrating the specific example of a relief request notification log | history data table. It is a figure for demonstrating the specific example of a relief response log | history data table. It is a figure for demonstrating the specific example of an evaluation value data table. It is a figure for demonstrating the specific example of an operation history data table. It is a figure for demonstrating the whole flow of the process performed in a game data processing part. It is a figure for demonstrating the specific procedure of a relief request notification process. It is a figure for demonstrating the specific procedure of a user extraction process. It is a figure for demonstrating the specific procedure of a user extraction process. It is a figure for demonstrating the specific procedure of a revival setting process. It is a figure for demonstrating the specific procedure of an item setting process. It is a figure for demonstrating the specific procedure of an item setting process. It is a figure for demonstrating the specific procedure of an item setting process. It is a figure for demonstrating the specific procedure of the modification of a relief request notification process. (A) It is an example of a screen which shows a relief request confirmation image. (B) It is an example of a screen which shows a relief request notification image. (C) It is an example of a screen which shows a relief response confirmation image. (A) It is an example of a screen which shows a revival notification image. (B) It is an example of a screen which shows a relief candidate user selection reception image.

  A mode for carrying out the present invention (hereinafter referred to as the present embodiment) will be described with a specific example. The present embodiment relates to a game system that provides a game to a terminal connected to a game server via a communication network. Specifically, as shown in FIG. 1, a game system G according to the present embodiment includes a game server 1 that provides a game to a user, and a terminal 3a that is connected to the game server 1 via the Internet 2 that is a communication network. 3b, 3c,..., 3n (hereinafter collectively referred to as terminal 3).

  In the following, first, prior to the description of the embodiment, the definitions of terms used in the present embodiment are clarified, and further, an outline of the social game handled in the present embodiment is described, and then the configuration and processing contents of the game system G are specifically described. I will explain it.

(1) Definition of terms Definitions of terms used in the present embodiment are as follows.

  The “virtual space” indicates a virtual world formed during the game based on the content of the game, and indicates a space different from the physical space. The “virtual space” displayed on the display (display unit) of the terminal 3 is two-dimensional, but the ideal space formed by adding connections with other terminals 3 is not limited to the two-dimensional space.

  “Real user” refers to an entity operating a terminal, that is, a person hitting a person. On the other hand, a virtual entity impersonating the user or formed in accordance with the user's taste or preference in the virtual space by a button or touch operation on the terminal of the “real user” that is the entity is referred to as a “virtual user”. For this “virtual user”, the virtual entity cannot be visually recognized in the game, for example, as in the player of the traditional shogi game or mahjong game, but is operated in the virtual space as an impersonation of the “real user” Also includes pieces and traps. The “virtual user” also includes a specific visible character that is displayed on the game in a role playing game or a battle game and causes movement or action. Furthermore, the “virtual user” includes a virtual entity displayed as an avatar in the SNS. As described above, the “virtual user” in the present embodiment is used as a term that broadly represents a virtual entity in the virtual space, and is a virtual entity that is embodied in the game or a virtual entity that functions as a shadow that is not embodied. It doesn't matter if it is.

(2) Outline of Social Game Next, an outline of the social game provided from the game server 1 to the terminal 3 connected via the Internet 2 will be described.

  The social game of the present embodiment is a game in which a virtual user who operates in accordance with an operation of the terminal 3 by a real user runs in the virtual space. A predetermined course for the virtual user to travel is provided in the virtual space. When the game is started by operating the terminal 3, the virtual user automatically moves along a predetermined course. The direction in which the virtual user automatically moves on the screen is not particularly limited, and may be a mode in which the virtual user moves from the front of the screen toward the back of the screen, or a mode in which the virtual user moves from the left side of the screen toward the right side of the screen. In the present embodiment, a case will be described in which a virtual user automatically moves from the front of the screen toward the back of the screen.

  There are obstacles in the course in advance. For example, walls are provided at the left and right ends or the upper end of the course, or a pit is provided on the course. The real user can move the position of the virtual user left and right, bend the virtual user, or cause the virtual user to jump by operating the terminal 3. If there is a wall at the left end of the course, move the virtual user to the right, and if there is a wall at the top end of the course, bend the virtual user and create a pitfall on the course If so, the virtual user may be jumped. If the virtual user cannot avoid the obstacle, that is, if it hits a wall or falls into a hole, the virtual user's progress stops. In the present embodiment, the expression that the progress of the virtual user is stopped means a state in which the virtual user stops moving automatically. When the process of setting the virtual user to be able to proceed again is performed after selecting the return to the starting point by the operation of the terminal 3 or making a rescue request by the operation of the terminal 3 as described later, The virtual user can be advanced again. In the latter case, it is possible to continue the process from the position where the progress of the virtual user is stopped.

(3) Basic Hardware Configuration (3-1) Terminal Configuration Hereinafter, a hardware configuration for realizing the game system G of the present embodiment will be described.

  As illustrated in FIG. 1, the terminal 3 includes a portable wireless communication terminal including a wireless communication unit 31, a display unit 32, and an operation unit 33, for example. The wireless communication unit 31 connects to the Internet 2 using a mobile phone line or a wireless LAN line, and performs data communication with the game server 1 on a web browser. The display unit 32 displays the web browser screen received from the game server 1. For example, the operation unit 33 includes a touch panel that receives an operation input from an actual user according to the display on the screen of the display unit 32. The operation input received from the real user in this way is transmitted to the game server 1 by the wireless communication unit 31.

  In the terminal 3 having such a hardware configuration, for example, individual authentication processing of the terminal is performed by a combination of a user ID registered in advance and a predetermined password. When the authentication with the game server 1 is completed, the terminal 3 receives data necessary for progressing the game from the game server 1 and transmits operation data in the operation unit 33 to the game server 1. .

  The terminal 3 may be a mobile phone, a PDA, a personal computer, or the like as long as it is a communication device that can communicate with the game server 1 via the Internet 2 that is a communication network. In addition, although a touch panel has been described as an example of the operation unit 33, it is needless to say that a configuration in which a cursor or the like is moved by a physical key operation to perform selection operation and input information may be employed.

(3-2) Schematic Configuration of Game Server The game server 1 connected to be communicable with the terminal 3 is realized by a computer having a general-purpose hardware configuration as shown in FIG. That is, as shown in FIG. 2, the game server 1 includes a communication interface unit 11 that communicates with the terminal 3 via the Internet 2 and an operation input unit 12 that receives an operation input from a user such as a keyboard and a mouse. . In addition, the game server 1 includes an arithmetic processing unit 13 such as a CPU that performs various arithmetic processes, a main memory 14 such as an SRAM or DRAM that temporarily stores arithmetic processing data, and a hard disk that stores application programs and various data. And the like, and a display 16 for displaying the calculation processing result.

  The game server 1 installs a program for providing the user with a social game 20 composed of a plurality of game parts in the storage device 15, thereby realizing a functional block as shown in FIG.

  That is, in the game server 1, for example, a function including an operation data receiving unit 11a, a game data processing unit 100, and a game data storage unit 200 that manages game data is realized as shown in FIG.

  The operation data receiving unit 11 a is means for receiving operation data transmitted from the terminal 3 through the communication network 2.

(3-3) Specific Configuration of Game Server Hereinafter, a game data processing unit 100 having a configuration specific to the present embodiment, and game data storage serving as a storage area for realizing processing in the game data processing unit 100 A specific configuration of the unit 200 will be described with reference to FIG. First, the configuration of the game data storage unit 200 will be described.

(3-3-1) Configuration of Game Data Storage Unit First, as data used in the game data processing unit 100, the game data storage unit 200 includes a progress management data table 211, a relief request reception history, as shown in FIG. A data table 212, a relief request notification history data table 213, a relief response history data table 214, an evaluation value data table 215, and an operation history data table 216 are provided.

(Progress management data table 211: FIG. 4)
As illustrated in FIG. 4, the progress management data table 211 stores the degree of progress of a virtual user who travels a predetermined course for each virtual user. The progress management data table 211 is updated at a predetermined timing based on operation data from each terminal.

  The degree of progress of the virtual user is represented as “arrival position”. The arrival position is indicated by the distance from the start point in a predetermined course when the start point is 0 m.

(Relief request acceptance history data table 212: FIG. 5)
As shown in FIG. 5, the relief request reception history data table 212 stores data related to the relief request. Data is newly added to the relief request acceptance history data table 212 every time a later-described relief request accepting unit accepts a request to make a relief request from the terminal.

  Relief request means that when the progress management unit described later stops one virtual user traveling through a predetermined course, the one virtual user can proceed to another virtual user in order to be able to proceed again. It means to request. When another virtual user responds to a rescue request from one virtual user, the one virtual user can proceed a predetermined course again.

  Specifically, the relief request reception history data table 212 includes a relief request NO. And the data regarding the position where the relief request reception time, the relief requesting user, and the virtual user who made the relief request are stopped are stored.

  Relief request No. Is an identification number given in the order in which the relief request accepting unit accepts the relief request. The relief request acceptance time is the time when the relief request acceptance unit accepts a request to make a relief request from a terminal that operates one virtual user, and is represented by a date and time. The rescue requesting user is a virtual user who has made a rescue request, and is represented by a user ID that identifies the virtual user. The position where the virtual user who made the rescue request is stopped is indicated by the distance from the start point in a predetermined course when the start point is 0 m.

(Relief request notification history data table 213: FIG. 6)
As shown in FIG. 6, the relief request notification history data table 213 stores data related to the notification of the relief request. In the relief request notification history data table 213, after receiving a request for a relief request from a terminal where the relief request receiving unit operates one virtual user, a later-described relief request notifying unit operates another virtual user. Each time the terminal is notified that a rescue request has been made, new data is added.

  In the relief request notification history data table 213, specifically, the relief request NO. And the relief request notification time, the rescue candidate user, and data related to the reaching position of the rescue candidate user are stored.

  As described above, the rescue request notifying unit notifies the terminal operating another virtual user that there is a rescue request. The rescue candidate user is the other virtual user. The rescue request notification time is a time when the rescue request notification unit notifies the terminal that operates the rescue candidate user that there is a rescue request, and is represented by a date and time. The reaching position of the rescue candidate user is a position where the rescue candidate user has reached the rescue request notification time. Relief request No. Is the identification number of the rescue request notified to the terminal that operates the rescue candidate user.

(Relief Response History Data Table 214: FIG. 7)
As shown in FIG. 7, the rescue response history data table 214 stores data related to the response of the rescue request. Data is newly added to the rescue response history data table 214 when a later-described revival setting unit receives a request to respond to a rescue request from a terminal that operates one virtual user among the rescue candidate users. In addition, when there is one rescue candidate user, when a request for responding to the rescue request is received from a terminal that operates the rescue candidate user, data is newly added.

  In the rescue response history data table 214, specifically, the rescue request No. And the data regarding the relief response reception time, the relief response user, the relief request user, and the number of times of the combo are stored.

  As described above, the revival setting unit accepts a request to respond to a rescue request from a terminal that operates one virtual user among the rescue candidate users. The rescue response user is the one virtual user. Relief request No. These are the identification numbers of the relief request which received the request to respond from the terminal which operates a relief response user. The rescue response reception time is the time when the request for requesting response from the terminal that operates the rescue response user is received by the revival setting unit, and is represented by a date and time.

  The number of times of combo means the number of times of mutual relief between virtual users. For example, after a virtual user with user ID 30002 makes a rescue request, a virtual user with user ID 30001 responds to the rescue request, and after a virtual user with user ID 30001 makes a new rescue request, a virtual user with user ID 30002 When responding to the new request for relief, the number of combos is 1. Next, after the virtual user with the user ID 30002 makes a rescue request, when the virtual user with the user ID 30001 responds to the rescue request, the number of combos is 2.

(Evaluation value data table 215: FIG. 8)
As shown in FIG. 8, the evaluation value data table 215 stores data regarding the evaluation value of the virtual user for each virtual user. Specifically, the evaluation value data table 215 stores data relating to level and ranking as evaluation values.

  The level is a numerical value representing the degree of progress of the virtual user in the game. When the game is started from level 1, level 2 and level 3, and numerical values indicating the level increase as the game progresses. Issues to be achieved are determined for each level, and by clearing those issues, the level rises.

  The ranking is created based on predetermined parameters regarding the virtual user. For example, it may be created in descending order of level.

(Operation history data table 216: FIG. 9)
As illustrated in FIG. 9, the operation history data table 216 stores data regarding the operation rate of each time slot in one day for each virtual user. Specifically, the operation history data table 215 stores data in which an operation rate for each hour is expressed in% by dividing a day into 24.

(3-3-2) Configuration of Game Data Processing Unit As shown in FIG. 3, the game data processing unit 100 includes a progress management unit 41, a rescue request confirmation unit 42, a rescue request reception unit 43, and a user extraction unit. 44, a relief request notification unit 45, a resurrection setting unit 46, an item setting unit 47, a user notification unit 48, a user selection reception unit 49, and a data table update unit 50.

  The progress management unit 41 is a means for causing the virtual user to progress in a predetermined course or stopping the progress based on operation data from the terminal. If an obstacle is set on the course and the virtual user cannot avoid the obstacle, the progress management unit 41 stops the progress of the virtual user.

  The relief request confirmation unit 42 is a means for confirming whether or not the virtual user makes a relief request. Specifically, the rescue request confirmation unit 42 outputs an image (a rescue request confirmation image) for confirming whether or not to perform a rescue request to a terminal that operates the virtual user.

  The relief request receiving unit 43 is means for receiving operation data indicating that a relief request is made from a terminal that operates one virtual user.

  The user extraction unit 44 is a means for extracting a virtual user that satisfies a predetermined condition as the other virtual user based on information on one virtual user. Specifically, the user extraction unit 44 extracts a virtual user having an evaluation value within a predetermined range from the evaluation value of one virtual user based on information about the evaluation value of one virtual user. Furthermore, the user extraction unit 44 is a virtual user whose operation frequency in a predetermined operation time zone including the time is greater than or equal to a predetermined threshold based on information related to the time when the rescue request is received from the terminal that operates one virtual user. May be extracted.

  The rescue request notifying unit 45 is a means for notifying a terminal that operates another virtual user that there is a rescue request from one virtual user when the rescue request receiving unit receives the rescue request. The rescue request notifying unit 45 may notify a terminal that operates any other virtual user, but when the user extracting unit 44 extracts a virtual user that satisfies a predetermined condition, the rescue request notifying unit 45 operates the extracted virtual user. Notification to the terminal to be performed. Moreover, the relief request notification part 45 notifies to the terminal which operates the selected virtual user, when the user selection reception part mentioned later receives the selection request | requirement which selects a virtual user.

  The recovery setting unit 46 is a means for recovering one virtual user to a state in which the virtual user can proceed when receiving operation data for rescue of the one virtual user from a terminal that operates another virtual user. The revival setting unit 46 receives operation data that rescues one virtual user when another virtual user reaches a position where the progress of the one virtual user has stopped. Here, “arrival” is not limited to the completely coincident position of one virtual user and the position of another virtual user. A state in which another virtual user has approached the vicinity of a position where the progress of one virtual user has stopped is also included.

  The item setting unit 47 is a means for setting a virtual item as a reward for a virtual user related to a terminal that has transmitted operation data to respond to a rescue request. Specifically, the item setting unit 47 extracts a virtual item based on the distance between the arrival position of another virtual user and the position where one virtual user has stopped when the rescue request notification unit 45 notifies. Further, the item setting unit 47 may extract a virtual item based on the number of combos between one virtual user and another virtual user. Moreover, the item setting part 47 may extract a virtual item based on the difference between the relief request notification time and the relief response reception time.

  The user notification unit 48 is a means for notifying information regarding the virtual user extracted by the user extraction unit 44 to the terminal that operates the rescue requesting user. Specifically, the user notification unit 48 outputs an image indicating the virtual user identification information extracted by the user extraction unit 44 and information regarding the current arrival position.

  The user selection receiving unit 49 is a unit that receives a selection request for selecting any one of the virtual users extracted by the user extracting unit 44.

  The data table update unit 50 is means for updating data stored in each data table. For example, when the rescue request receiving unit 43 receives operation data indicating that a rescue request is made from a terminal that operates one virtual user, the data table updating unit 50 newly adds data to the rescue request receiving data table. . In addition, when the rescue request notification unit 45 notifies the terminal that operates another virtual user that there is a rescue request from one virtual user, the data table update unit 50 newly adds data to the rescue request notification data table. Add Moreover, if the revival setting part 46 receives the operation data which rescues one virtual user from the terminal which operates another virtual user, the data table update part 50 will newly add data to a relief response data table.

(4) Process in Game Server As an example of the process in the game server of this embodiment, the process of the game data processing unit 100 having the above configuration will be described.

(4-1) Overview First, an overview of the present embodiment will be described with reference to FIG. Below, it demonstrates as a process performed with respect to arbitrary one virtual users (henceforth a target virtual user).

  As illustrated in FIG. 10, in step S1001, the progress management unit 41 moves the position of the target virtual user. The movement of the virtual user is started, for example, when the real user selects a start button displayed on the screen. The data table update unit 50 stores data related to the position of the target virtual user in the progress management data table 211 of FIG. Note that the movement of the virtual user from the start point toward the traveling direction in a predetermined course is automatically performed. The real user can jump or bend the virtual user or change the position of the course in the left-right direction by performing a preset operation. Obstacles are installed on the course, and if a real user performs an appropriate operation, it is possible to avoid the virtual user from hitting the obstacle.

  In step S1002, the progress management unit 41 determines whether the target virtual user has avoided an obstacle placed on the course. If the obstacle is not avoided (step S1002: NO), the process proceeds to step S1003. On the other hand, when an obstacle is avoided (step S1002: YES), the process returns to step S1001, and the processes after step S1001 are repeated.

  In step S1003, the progress management unit 41 stops the position of the target virtual user. In the progress management data table 211 of FIG. 4, the update of data regarding the target virtual user is stopped.

  In step S1004, the rescue request confirmation unit 42 outputs an image (a rescue request confirmation image) for confirming whether or not a rescue request is to be made to a terminal that operates the target virtual user. An example screen 100 for displaying a relief request confirmation image is shown in FIG.

  As shown in FIG. 19A, a notification image 101 for notifying the position where the target virtual user has stopped is displayed at the top of the screen. Data relating to the position where the target virtual user has been stopped is obtained from the progress management data table 211 of FIG. For example, in the case of a virtual user with a user ID 30001, it can be seen that the stopped position is 1113m. As the notification image 101, an image described as “arrival position 1113m” is displayed.

  Below that, a selection image 102 that allows the terminal operating the target virtual user to select whether or not to make a rescue request is displayed. For example, as the selection image 102, a button icon 102a described as “YES” and a button icon 102b described as “NO” are displayed together with an image indicating “Do you want to request relief?”. The real user can determine whether or not to make a rescue request by operating the button icon 102a or the button icon 102b.

  In the lower part of the screen, a display image 103 indicating a course and a display image 104 indicating a target virtual user who has fallen on the course are displayed.

  In step S1005, the relief request accepting unit 43 determines whether or not operation data indicating that a relief request is made is accepted from a terminal that operates the target virtual user. If operation data for requesting relief is received (step S1005: YES), the process proceeds to step S1006. On the other hand, if operation data indicating that no rescue request is made is received (step S1005: NO), the process proceeds to step S1009. Hereinafter, the target virtual user related to the terminal that has transmitted the operation data for requesting relief is referred to as “relief request user”.

  In step S1006, the data table update unit 50 sets the relief request No. in the relief request reception history data table 212 of FIG. A new number is added to the data, and the data related to the rescue request reception time, the rescue request user, and the location where the rescue request user is stopped are stored.

  In step S1007, a process (rescue request notification process) for notifying that a rescue request user has made a rescue request to a terminal that operates a virtual user other than the rescue request user is executed. Details of the relief request notification process will be described later. The other virtual user may be a virtual user arbitrarily selected from virtual users registered in the game, or may be a virtual user extracted based on a predetermined condition as will be described later. Also good. Hereinafter, another virtual user who receives a notification of a rescue request is referred to as a “relief candidate user”.

  In step S1008, when operation data indicating that a rescue request is accepted is received from a terminal that operates one of the virtual users among the rescue candidate users, a process (resurrection setting process) for causing the rescue request user to proceed again is executed. This process is terminated. Details of the restoration setting process will be described later.

  In step S1009, the progress management unit 41 returns the position of the target virtual user to the start point, and ends this process.

(4-2) Relief Request Notification Process Details of the rescue request notification process in step S1007 will be described with reference to FIG. As shown in FIG. 11, in step S1101, the user extraction unit 44 executes a process (user extraction process) for extracting a virtual user that satisfies a predetermined condition based on information on a rescue requesting user. Details of the user extraction process will be described later.

  In step S1102, the relief request notification unit 45 outputs a notification image (relief request notification image) for notifying that the relief request user has requested a relief to the terminal that operates the virtual user extracted in step S1101. That is, the virtual user extracted in step S1101 is a rescue candidate user. An example screen 200 for displaying a relief request notification image is shown in FIG.

  As shown in FIG. 19B, a notification image 201 for notifying the current position where the rescue candidate user is traveling is displayed at the top of the screen. Data on the current position where the rescue candidate user is traveling is obtained from the progress management data table 211 of FIG. For example, an image described as “arrival position 888 m” is displayed as the notification image 201.

  Below that, a notification image 202 is displayed to notify that the rescue requesting user has made a rescue request. Specifically, the rescue request notification unit 45 refers to the rescue request reception history data table 212 in FIG. 5 and notifies the rescue request user identification information and information indicating the position where the rescue request user has stopped. For example, as the notification image 202, an image stating “Are there a request for relief! AAA has fallen at the arrival position 1113m!” Is displayed.

  In the lower part of the screen, a display image 203 indicating the course and a display image 204 indicating a rescue candidate user traveling on the course are displayed.

  In step S1103, the data table update unit 50 sets the relief request No. in the relief request notification history data table 213 in FIG. A new number is added to the data, and the data regarding the rescue request notification time, the rescue candidate user, and the reaching position of the rescue candidate user are stored.

(4-3) User Extraction Processing Specific example 1 and specific example 2 of the user extraction processing in step S1101 will be described with reference to FIGS. In the specific example 1, the user extraction unit 44 extracts a specific virtual user based on the evaluation value of the rescue requesting user. In the second specific example, the user extraction unit 44 further extracts a specific user based on the time when the rescue request is received from the terminal that operates the rescue request user.

(Specific example 1)
As shown in FIG. 12, in step S1201, the user extraction unit 44 reads data related to the evaluation value of the rescue requesting user with reference to the evaluation value data table 215 of FIG. The data to be read may be level or ranking. For example, if the rescue requesting user is a virtual user with the user ID 30001, data indicating that the level is 55 is read.

  In step S1202, the user extraction unit 44 refers to the evaluation value data table 215 of FIG. 8 and extracts a virtual user having an evaluation value within a predetermined range from the evaluation value of the rescue requesting user. For example, if the level of the rescue requesting user is 55, a virtual user whose level is 50 to 60 is extracted.

  In step S1203, the user extraction unit 44 refers to the progress management data table 211 in FIG. 4 and the virtual user before reaching the position where the rescue requesting user is stopped from the virtual users extracted in step S1202. Is extracted, and this processing is terminated.

(Specific example 2)
As illustrated in FIG. 13, the processes in steps S1301 and S1302 are the same as the processes in steps S1201 and S1202, and thus the description thereof is omitted.

  In step S1303, the user extracting unit 44 refers to the rescue request reception history data table 212 of FIG. 5 and reads the time when the rescue request is received from the terminal that operates the rescue request user. For example, the data that the time when the rescue request is received from the terminal that operates the virtual user with the user ID 30001 is 21:28 is read.

  In step S1304, the user extraction unit 44 refers to the operation history data table 216 in FIG. 9, and the operation frequency in a predetermined operation time period including the time read out in step S1303 from the virtual users extracted in step S1302. A virtual user whose is greater than or equal to a predetermined threshold is extracted. For example, if the time read in step S1303 is 21:28, a virtual user whose operation frequency in the operation time zone from 21:00 to 22:00 is greater than or equal to a predetermined threshold is extracted.

  In step S1305, the user extraction unit 44 refers to the progress management data table 211 in FIG. 4 and extracts the virtual user before reaching the position where the rescue requesting user has stopped from the virtual users extracted in step S1304. Then, this process ends. Note that the order of processing for extracting virtual users, such as the processing of steps S1301 and S1302, can be changed after the processing of steps S1303 and S1304.

(4-4) Recovery Setting Process Details of the recovery setting process in step S1008 will be described with reference to FIG. As illustrated in FIG. 14, in step S1401, the revival setting unit 46 refers to the progress management data table 211 in FIG. 4, and there is a virtual user that has reached the position where the rescue requesting user has stopped among the rescue candidate users. Determine whether or not. If the virtual user exists (step S1401: YES), the process proceeds to step S1402. On the other hand, if the virtual user does not exist (step S1401: NO), the process returns to step S1401, and the process of step S1401 is repeated.

  In step S1402, the revival setting unit 46 confirms whether or not to respond to the rescue request to the terminal that operates the virtual user that has reached the position where the rescue request user has stopped among the rescue candidate users (rescue response confirmation). Image). FIG. 19C shows an example screen 300 for displaying a relief confirmation image.

  As shown in FIG. 19C, a notification image 301 for notifying the position where the rescue requesting user has stopped is displayed at the top of the screen. Below that, a selection image 302 for selecting whether or not to respond to the rescue request is displayed on the terminal that operates the virtual user that has reached the position where the rescue request user has stopped among the rescue candidate users. For example, as the selection image 302, a button icon 302a described as “YES” and a button icon 302b described as “NO” are displayed together with an image indicating “Do you want to rescue Mr. AAA?”. The actual user can determine whether or not to rescue the rescue requesting user by operating the button icon 302a or the button icon 302b. At the bottom of the screen, there are a display image 303 showing the course, a display image 304 showing the virtual user who has reached the position of the rescue requesting user who has fallen on the course, and a display image 305 showing the rescue requesting user who has fallen on the course. Is displayed.

  In step S1403, the revival setting unit 46 determines whether or not operation data indicating that the rescue request has been received has been received from a terminal that operates a virtual user that has reached the position where the rescue request user has stopped among the rescue candidate users. If operation data indicating that the request for relief has been accepted is received (step S1403: YES), the process proceeds to step S1406. On the other hand, when the operation data not responding to the rescue request is received (step S1403: NO), the process proceeds to step S1404.

  In step S <b> 1404, the revival setting unit 46 excludes the rescue candidate user related to the terminal that has transmitted the operation data not responding to the rescue request in step S <b> 1403.

  In step S1405, the revival setting unit 46 determines whether there are other rescue candidate users. If there is another candidate user (step S1405: YES), the process returns to step S1401, and the processes after step S1401 are repeated. On the other hand, if there is no other candidate user (step S1405: NO), the process proceeds to step S1409.

  In step S1406, based on the data obtained in step S1403, the data table update unit 50 adds the rescue response user and the rescue request NO. And the data about a relief response reception time, a relief request user, and the frequency | count of a combo are added. Note that the number of times of combo is calculated by referring to the past data in the rescue response history data table 214 in FIG. 7 and the number of times the rescue response user and the rescue request user have rescued each other.

  In step S1407, the process (item setting process) which sets a virtual item as a reward is performed with respect to the rescue candidate user who concerns the terminal which transmitted the operation data to respond to a relief request in step S1403. Details of the item setting process will be described later. Hereinafter, the rescue candidate user according to the terminal that has transmitted the operation data indicating the response to the rescue request is referred to as a “rescue response user”.

  In step S1408, the revival setting unit 46 outputs a notification image (revival notification image) for notifying that the rescue requesting user can proceed to the terminal that operates the rescue requesting user, and ends this process. FIG. 20A shows an example screen 400 for displaying the restoration notification image.

  As shown in FIG. 20A, a notification image 401 for notifying the position where the rescue requesting user has stopped is displayed at the top of the screen. Below that, information related to the rescue responding user and a notification image 402 for notifying that the rescue requesting user can proceed are displayed. As the notification image 402, for example, an image stating “GGG rescued me. I will be resurrected.” Is displayed. A display image 403 indicating a course, a display image 404 indicating a rescue responding user, and a display image 405 indicating the recovery of a rescue requesting user who has fallen on the course are displayed at the bottom of the screen.

  In step S1409, the revival setting unit 46 returns the position of the rescue requesting user to the start point, and ends this process.

(4-5) Item Setting Process Specific example 1 and specific example 2 of the item setting process in step S1407 will be described with reference to FIGS. 15 and 16. In the first specific example, the item setting unit 47 extracts a virtual item based on the distance between the arrival position of the rescue response user and the position where the rescue request user has stopped when the rescue request notification image is output. In the specific example 2, a virtual item is extracted based on the number of combos with the rescue requesting user of the rescue responding user. In the specific example 3, a virtual item is extracted based on the difference between the rescue request notification time and the rescue response reception time.

(Specific example 1)
As shown in FIG. 15, in step S1501, the item setting unit 47 refers to the rescue request notification history data table 213 in FIG. 6 and the rescue response history data table 214 in FIG. 7, to the terminal that operates the rescue response user. The arrival position of the rescue response user at the time when the rescue request notification image is output is read out.

  In step S1502, the item setting unit 47 refers to the rescue request reception history data table 212 in FIG. 5 and calculates the distance between the arrival position read in step S1501 and the position where the rescue request user has stopped.

  For example, relief request No. 8, it can be seen from the rescue response history data table 214 of FIG. 7 that the rescue response user is a virtual user with a user ID 30002. From the relief request notification history data table 213 of FIG. 6, it can be seen that the virtual user with the user ID 30002 has an arrival position of 888 m when the relief request notification image is output. Moreover, it can be seen from the rescue request reception history data table 212 of FIG. 5 that the position where the rescue request user has stopped is 1113 m. Therefore, the distance separating the two is 225 m.

  In step S1503, the item setting unit 47 extracts virtual items that can be used in the game based on the distance calculated in step S1502. Specifically, the item setting unit 47 extracts a virtual item that is more advantageous for the progress of the game as the distance calculated in step S1502 is longer.

  In step S1504, the item setting unit 47 sets the virtual item extracted in step S1503 as the possession item of the rescue response user.

(Specific example 2)
As shown in FIG. 16, in step S1601, the item setting unit 47 refers to the rescue response history data table 214 of FIG. 7, and reads the number of combos with the rescue requesting user of the rescue response user.

  For example, relief request No. 8 shows that the number of combos with the rescue requesting user of the rescue response user is one.

  In step S1602, the item setting unit 47 extracts virtual items that can be used in the game based on the combo count read in step S1601. Specifically, the item setting unit 47 extracts virtual items that are more advantageous for the progress of the game as the number of combos read in step S1601 increases.

  In step S1603, the item setting unit 47 sets the virtual item extracted in step S1602 as the possession item of the rescue response user.

(Specific example 3)
As shown in FIG. 17, in step S1701, the item setting unit 47 reads the relief request notification time with reference to the relief request notification history data table 213 of FIG.

  For example, relief request No. In FIG. 8, it can be seen that the relief request notification time is 20:21, January 11, 21:28.

  In step S1702, the item setting unit 47 refers to the relief response history data table 214 of FIG.

  For example, relief request No. In FIG. 8, it can be seen that the relief response reception time is 21:30 on January 11th, 20xx.

  In step S1703, the item setting unit 47 extracts virtual items that can be used in the game based on the difference between the relief request notification time read in step S1701 and the relief response reception time read in step S1702. Specifically, the item setting unit 47 extracts a virtual item that is more advantageous for the progress of the game as the difference is smaller.

  In step S1704, the item setting unit 47 sets the virtual item extracted in step S1703 as the possession item of the rescue response user.

(4-6) Modification Example of Relief Request Notification Process In the above-described rescue request notification process, the specific virtual user extracted by the user extraction unit 44 is a rescue candidate user, and the relief request notification unit 45 operates the specific virtual user. The rescue request notification image was output to the terminal. However, after the user extraction unit 44 extracts a specific virtual user, the terminal that operates the rescue requesting user is notified of information regarding the specific virtual user, and any one of the specific virtual users is selected. A selection request may be accepted. That is, it is good also considering the virtual user who received the selection request among the said specific virtual users as a relief candidate user. A specific description will be given with reference to FIG.

  As shown in FIG. 18, after the user extraction unit 44 executes the user extraction process in step S1801, in step S1802, the user notification unit 48 sends the virtual user extracted in step S1801 to the terminal that operates the rescue requesting user. Information about the user is notified, and an image (user selection acceptance image) for selecting one virtual user among the virtual users extracted in step S1801 is output. FIG. 20B shows an example screen 500 for displaying a rescue candidate user selection reception image. Note that the processing in step S1801 is the same as the processing in step S1101, and thus the description thereof is omitted.

  As shown in FIG. 20B, a notification image 501 for notifying the position where the rescue requesting user has stopped is displayed at the top of the screen.

  Below that, a notification image 502 for notifying information related to the rescue candidate user is displayed. Specifically, as the notification image 502, button icons 502a to 502d indicating the identification information of the virtual user extracted in step S1801, and a position image 502e indicating the current arrival position of the virtual user extracted in step S1801 are displayed. The real user can select one virtual user by operating one of the button icons 502a to 502d. A display image 503 showing the course and a display image 504 showing a relief requesting user who has fallen on the course are displayed at the bottom of the screen.

  In step S1803, the user selection receiving unit 49 determines whether a selection request for selecting any virtual user among the virtual users extracted in step S1801 has been received. If a selection request is received (step S1803: YES), the process proceeds to step S1804, and the rescue request notification unit 45 outputs a rescue request notification image to a terminal that operates the selected one virtual user. On the other hand, when the selection request is not received (step S1803: NO), the process of step S1803 is repeated.

  In step S1804, the relief request notification unit 45 outputs a notification image (relief request notification image) for notifying that there is a relief request from the rescue requesting user to the terminal that operates the one virtual user selected in step S1803. To do. That is, the one virtual user selected in step S1803 becomes a rescue candidate user.

  In step S1805, the data table update unit 50 sets the relief request No. in the relief request notification history data table 213 in FIG. A new number is added to the data, and the data regarding the rescue request notification time, the rescue candidate user, and the reaching position of the rescue candidate user are stored.

(5) Effect In this embodiment, when the progress management unit stops the progress of the target virtual user, the rescue request confirmation unit confirms whether or not to make a rescue request to the terminal that operates the target virtual user. Image (rescue request confirmation image) is output. Thereby, the real user can select whether to make a rescue request.

  In the present embodiment, the rescue request notification unit notifies the terminal that operates a virtual user other than the rescue request user that the rescue request user has made a rescue request. The resurrection setting unit advances the rescue requesting user again when receiving operation data indicating that the rescue request is accepted from a terminal that operates another virtual user. Since the real user who operates the rescue requesting user has a chance to make the rescue requesting user proceed again, there is no need to start the game from the beginning, and the work feeling can be wiped out. In addition, unlike the case where a virtual user is revived using an in-game item, even if the real user makes a rescue request, it is uncertain whether there is another real user who responds to the rescue request. It is not always possible to revive a rescue requesting user. Therefore, the real user who operates the rescue requesting user can have a sense of expectation such as whether there is another real user who responds to the rescue request.

  In this embodiment, a user extraction part extracts the virtual user which satisfy | fills predetermined conditions as another virtual user based on the information regarding a relief request user. By extracting virtual users that satisfy such a predetermined condition, it is possible to increase the probability that a real user who has received a notification of a rescue request responds to the rescue request. When the probability of responding to a rescue request increases, the frequency of exchange between virtual users in the game increases, and the game can be activated.

  In Specific Example 1 of the user extraction process, the user extraction unit extracts a virtual user having an evaluation value within a predetermined range from the evaluation value of the rescue requesting user. That is, a virtual user having an evaluation value comparable to the evaluation value of the rescue requesting user is extracted. And a relief request notification part notifies that there was a relief request to the terminal which operates the virtual user which has an evaluation value comparable as the evaluation value of such a relief request user. The evaluation value is a parameter for evaluating a virtual user in the game, and the real user may have a rivalry to the real user who operates the virtual user having the same evaluation value. In response to a real user who has received a notification of a rescue request, it is better to respond to the rescue from a rival real user or whether to proceed without responding to the game play. Can give fun.

  Moreover, in the specific example 2 of the user extraction process, the user extraction unit further determines the operation frequency in a predetermined operation time zone including the time based on information on the time when the rescue request is received from the terminal that operates the rescue request. A virtual user that is equal to or greater than a predetermined threshold is extracted. And a relief request notification part notifies that there was a relief request to the terminal which operates a virtual user with high operation frequency in such a predetermined operation time zone. Thereby, the probability that the real user who received the notification of a relief request will respond to a relief request can be raised. When the probability of responding to a rescue request increases, the contact frequency between virtual users in the game increases, and the game can be activated.

  In this embodiment, a revival setting part outputs a relief response confirmation image to the terminal which operates the virtual user which reached | attained the stop position where the relief request user stopped among relief candidate users. When there are a plurality of rescue candidate users, a real user who operates the rescue candidate user that has reached the stop position earliest can respond to the rescue request. However, even if the real user intends to respond to the rescue request, the virtual user who operates the mobile phone may stop before reaching the stop position. Therefore, the real user who operates the virtual user traveling in the position closest to the stop position cannot always respond to the rescue request. Therefore, it is possible to give a sense of expectation to a plurality of real users who have received the notification of the rescue request whether or not they can respond to the rescue request. Also, the difficulty level of the game is improved compared to the case where other real users can respond to the rescue request by simply pressing one button on the screen without causing other virtual users to reach the stop position. And the work feeling can be wiped out more.

  In the specific example 1 of the item setting process, the item setting unit is based on the distance between the arrival position of the rescue response user at the time when the rescue request notification image is output and the position where the rescue request user has stopped. Extract virtual items that are more advantageous as the game progresses. The actual user may stop the virtual user who operates by himself before reaching the position where the rescue requesting user stops, but if the user can reach safely, the longer the distance, the more sense of achievement Is big. By extracting the virtual item based on the distance, it is possible to further enhance the sense of achievement obtained by the real user. Moreover, the motivation which responds to a real user's relief request can be raised.

  In the specific example 2 of the item setting process, the item setting unit extracts a virtual item that is more advantageous for the progress of the game as the number of combos increases based on the number of combos with the rescue requesting user of the rescue response user. Depending on the actual user who operates the rescue requesting user, a feeling of giving back to the actual user who has responded to the rescue request is born. When there is a rescue request from a virtual user operated by a real user who has responded to the rescue request, the willingness to respond to the rescue request increases, and a combo is established. It can be said that the greater the number of combos, the higher the familiarity between real users. By extracting virtual items based on such intimacy, motivation to respond to a real user's rescue request can be further increased.

  In specific example 3 of the item setting process, the item setting unit extracts a virtual item that is more advantageous for the progress of the game as the difference is smaller, based on the difference between the relief request notification time and the relief response reception time. Thereby, the real user can be prompted to respond to the notification of the rescue request more quickly. The frequency of exchange between virtual users in the game increases, and the game can be activated.

  In a modification of the rescue request notification process, the real user who operates the rescue request user can know information about the virtual user extracted by the user extraction unit, and one virtual user from the virtual users extracted by the user extraction unit Can be selected. By causing the real user who operates the rescue request user to select a virtual user who wants to respond to the rescue request, the willingness to respond to the rescue request of the real user who has received the rescue request notification can be enhanced.

(6) Others In the user extraction process of the present embodiment, an example of extracting all virtual users that satisfy a predetermined condition has been shown, but the number of virtual users to be extracted may be limited. Specifically, the user extraction unit may determine the number of virtual users to be extracted according to the number of virtual users rescued by the rescue requesting user in the past, and extract the determined number of virtual users. For example, the greater the number of virtual users that the rescue requesting user has rescued in the past, the more the user extraction unit extracts more virtual users. And a relief request notification part notifies that there were relief requests to many virtual users which the user extraction part extracted. If the number of real users who have received the notification of the rescue request is large, the number of real users who respond to the rescue request also increases. In order to have another real user respond when he / she makes a rescue request, the real user can be prompted to respond positively to a rescue request from another real user.

  Further, in the rescue notification process of the present embodiment, when operation data indicating that a rescue request is made is received, an example of notifying other virtual users that there is a rescue request is shown, but the probability of notification is changed. May be. Specifically, the rescue request notification unit receives a rescue request from the rescue request user according to the ratio of the number of times the rescue request is received from the rescue request user during the predetermined period and the response frequency of the rescue request user responding to the rescue request. The probability of notifying that may be set, and notification may be made based on the set probability. For example, if the number of receptions received from the virtual user during the predetermined period is much larger than the number of responses that the virtual user responded to the relief request during the predetermined period, the virtual user is notified that the rescue request has been received. Is set to a low probability. Thereby, a real user can be urged to respond positively to a rescue request from another real user.

  The present invention provides a non-temporary recording medium in which a software program for realizing the functions of the above-described embodiments is recorded to a system or apparatus, and the non-temporary recording medium is provided to a computer of the system or apparatus, that is, a CPU or MPU. It may be realized by reading and executing a program recorded on a typical recording medium.

  In this case, the program read from the non-temporary recording medium realizes the functions of the above-described embodiment. Therefore, the program and a non-transitory recording medium on which the program is recorded are also one embodiment of the present invention.

  Non-temporary recording media that provide the program include flexible disks, hard disks, magneto-optical disks, CD-ROMs, CD-Rs, CD-RWs, DVD-ROMs, DVD-RAMs, DVD-RWs, DVD + RWs, and the like. Includes optical disks, magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, the program may be downloadable via a communication network.

  Furthermore, the functions of the above-described embodiment are not only for the computer to read and execute the program, but also to an OS (operating system) operating on the computer or the like, based on the instructions of the program, part or all of the actual operation. You may implement | achieve by performing.

  Furthermore, the functions of the above-described embodiment are provided in a memory provided on an expansion board inserted into a computer or an expansion device connected to the computer by reading a program read from a non-temporary recording medium. You may implement | achieve by writing to memory and making CPU etc. provided in the expansion board or the expansion apparatus perform all or one part of actual processing based on the instruction | indication of a program.

  Although the invention has been described with reference to exemplary embodiments, it is to be understood that the invention is not limited to the exemplary aspects disclosed herein. The claims can be broadly construed to include all such modifications and equivalent structures and functions.

G game server 11a Operation data receiving part 41 Progress management part 42 Relief request confirmation part 43 Relief request accepting part 44 User extracting part 45 Relief request notifying part 46 Resurrection setting part 47 Item setting part 48 User notifying part 49 User selection accepting part 50 Data Table update unit 211 Progress management data table 212 Relief request reception history data table 213 Relief request notification history data table 214 Relief response history data table 215 Evaluation value data table 216 Operation history data table

(1) A game server according to the present invention is a game server that provides a game in which a virtual user formed on a game provided to a terminal connected via a communication network advances a predetermined course, the terminal An operation data receiving unit that receives operation data for operating the virtual user, a progress management unit that advances or stops the progress of the virtual user in the predetermined course based on the operation data, When the progress of the virtual user is stopped, based on the operation data of the terminal that operates the one virtual user, the rescue request receiving unit that receives a rescue request for allowing the one virtual user to proceed again If, Yu based on said information about the evaluation value of the first virtual user, extracts the virtual user having an evaluation value comparable to the evaluation value of the one of the virtual user And The extractor, wherein when the support request accepting unit accepts the support request, said there is support request from a virtual user, support request notification unit that notifies to a terminal for operating a virtual user that the extracted And a restoration setting unit that restores the one virtual user to a state in which the one virtual user can be advanced when operation data for rescue of the one virtual user is received from a terminal that operates the extracted virtual user. It is characterized by.

In the above aspect, when the progress of one virtual user stops, the real user who operates the one virtual user can make a rescue request so that the one virtual user can proceed again. When a real user makes a rescue request and another real user who operates another virtual user responds to the rescue request, one virtual user can proceed. Even if the progress of one virtual user stops, the real user has a chance to allow the one virtual user to proceed again, so that it is not necessary to restart the game from the beginning, and the work feeling can be wiped out. In addition, unlike the case where a virtual user is revived using an in-game item, even if the real user makes a rescue request, it is uncertain whether there is another real user who responds to the rescue request. It is not always possible to restore a single virtual user. Therefore, the real user who made the rescue request can have a sense of expectation as to whether there is another real user who responds to the rescue request.
Moreover, in this aspect, a relief request notification part notifies the terminal which operates the virtual user which has an evaluation value comparable as the evaluation value of one virtual user that there was a relief request. The evaluation value is a parameter for evaluating a virtual user in the game, and the real user may have a rivalry to the real user who operates the virtual user having the same evaluation value. In response to a real user who has received a notification of a rescue request, it is better to respond to the rescue from a rival real user or whether to proceed without responding to the game play. Can give fun.

(2) The game server of the present invention is a game server that provides a game in which a virtual user formed on a game provided to a terminal connected via a communication network advances a predetermined course, An operation data receiving unit that receives operation data for operating the virtual user from the terminal, a progress management unit that advances or stops the progress of the virtual user in the predetermined course based on the operation data, When the progress of one virtual user is stopped, based on the operation data of the terminal that operates the one virtual user, a rescue request for receiving a rescue request for allowing the one virtual user to proceed again Based on the information about the time when the rescue request is received from the reception unit and the terminal that operates the one virtual user, the operation data is displayed in the same time zone as the time. When a user extraction unit that extracts a virtual user whose frequency of receiving operation data is relatively higher than a frequency of receiving operation data in another time zone and the rescue request receiving unit receives the rescue request, the one virtual From the rescue request notifying unit for notifying the terminal that operates the extracted virtual user that there is a rescue request from the user, and the operation data that rescues the one virtual user from the terminal that operates the extracted virtual user. A resurrection setting unit that, when received, restores the one virtual user to an advanceable state.

In the above aspect, when the progress of one virtual user stops, the real user who operates the one virtual user can make a rescue request so that the one virtual user can proceed again. When a real user makes a rescue request and another real user who operates another virtual user responds to the rescue request, one virtual user can proceed. Even if the progress of one virtual user stops, the real user has a chance to allow the one virtual user to proceed again, so that it is not necessary to restart the game from the beginning, and the work feeling can be wiped out. In addition, unlike the case where a virtual user is revived using an in-game item, even if the real user makes a rescue request, it is uncertain whether there is another real user who responds to the rescue request. It is not always possible to restore a single virtual user. Therefore, the real user who made the rescue request can have a sense of expectation as to whether there is another real user who responds to the rescue request.
Further, in this aspect, the rescue request notifying unit determines whether the frequency of receiving the operation data in the time zone equivalent to the time based on the information related to the time when the rescue request is received from the terminal that operates one virtual user. The terminal that operates the virtual user that is relatively higher than the frequency of receiving the operation data in the time zone is notified that the rescue request has been made. Thereby, the probability that the real user who received the notification of a relief request will respond to a relief request can be raised. When the probability of responding to a rescue request increases, the contact frequency between virtual users in the game increases, and the game can be activated.

(3) The game server of the present invention is a game server that provides a game in which a virtual user formed on a game provided to a terminal connected via a communication network advances a predetermined course, An operation data receiving unit that receives operation data for operating the virtual user from the terminal, a progress management unit that advances or stops the progress of the virtual user in the predetermined course based on the operation data, When the progress of one virtual user is stopped, based on the operation data of the terminal that operates the one virtual user, a rescue request for receiving a rescue request for allowing the one virtual user to proceed again When the accepting unit and the rescue request accepting unit accept the rescue request, the other virtual user is manipulated to confirm that there is a rescue request from the one virtual user. When the operation data for relieving the one virtual user is received from the rescue request notifying unit for notifying the terminal and the terminal for operating the other virtual user, the one virtual user is restored to a state in which the virtual user can proceed. Based on the number of times that the resurrection setting unit and the one virtual user and the other virtual user have rescued each other, a virtual item that is more advantageous to the progress of the game is given to the other virtual user as the number of times increases. And a reward setting unit that is set as a reward.

In the above aspect, when the progress of one virtual user stops, the real user who operates the one virtual user can make a rescue request so that the one virtual user can proceed again. When a real user makes a rescue request and another real user who operates another virtual user responds to the rescue request, one virtual user can proceed. Even if the progress of one virtual user stops, the real user has a chance to allow the one virtual user to proceed again, so that it is not necessary to restart the game from the beginning, and the work feeling can be wiped out. In addition, unlike the case where a virtual user is revived using an in-game item, even if the real user makes a rescue request, it is uncertain whether there is another real user who responds to the rescue request. It is not always possible to restore a single virtual user. Therefore, the real user who made the rescue request can have a sense of expectation as to whether there is another real user who responds to the rescue request.
Further, in the present embodiment, based on the number of times that the mutually relief with one virtual user and other virtual users, the more the number is large, extracts a favorable virtual item with the progress of the game. Depending on the actual user who operates the rescue requesting user, a feeling of giving back to the actual user who has responded to the rescue request is born. When there is a rescue request from a virtual user operated by a real user who has responded to the rescue request, the willingness to respond to the rescue request increases, and a combo is established. It can be said that the greater the number of combos, the higher the familiarity between real users. By extracting virtual items based on such intimacy, motivation to respond to a real user's rescue request can be further increased.

(4) Further, the game server of the present invention is a game server that provides a game in which a virtual user formed on a game provided to a terminal connected via a communication network advances a predetermined course, An operation data receiving unit that receives operation data for operating the virtual user from the terminal, a progress management unit that advances or stops the progress of the virtual user in the predetermined course based on the operation data, When the progress of one virtual user is stopped, based on the operation data of the terminal that operates the one virtual user, a rescue request for receiving a rescue request for allowing the one virtual user to proceed again When the accepting unit and the rescue request accepting unit accept the rescue request, the other virtual user is manipulated to confirm that there is a rescue request from the one virtual user. The rescue request notifying unit that notifies the terminal that performs the operation, and the other virtual user arrives at a position where the progress of the one virtual user has stopped, and the terminal that operates the other virtual user When the operation data for rescue of the virtual user is received, the resurrection setting unit that restores the one virtual user to an advanceable state, and the arrival of the other virtual user at the time of notifying that the rescue request has been made A reward setting unit that sets a virtual item that is more advantageous to the progress of the game as a reward to the other virtual user based on the distance between the position and the position where the one virtual user has stopped. It is characterized by.

In the above aspect, when the progress of one virtual user stops, the real user who operates the one virtual user can make a rescue request so that the one virtual user can proceed again. When a real user makes a rescue request and another real user who operates another virtual user responds to the rescue request, one virtual user can proceed. Even if the progress of one virtual user stops, the real user has a chance to allow the one virtual user to proceed again, so that it is not necessary to restart the game from the beginning, and the work feeling can be wiped out. In addition, unlike the case where a virtual user is revived using an in-game item, even if the real user makes a rescue request, it is uncertain whether there is another real user who responds to the rescue request. It is not always possible to restore a single virtual user. Therefore, the real user who made the rescue request can have a sense of expectation as to whether there is another real user who responds to the rescue request.
Further, in this aspect, the reward setting unit, based on the distance between the arrival position of another user at the time when the rescue request notification image is output and the position where one virtual user has stopped, the longer the distance, Extract virtual items that are more advantageous as they progress. In order for another real user who operates another virtual user to respond to the rescue request, it is necessary to cause the other virtual user to reach a stop position where the progress of one virtual user is stopped. Even if another real user intends to respond to the rescue request, the progress of the other virtual user may stop before the other virtual user reaches the stop position. Even if a real user makes a rescue request, it is uncertain whether other real users can bring other virtual users to the stop position, and one virtual user can always be revived. Not exclusively. Therefore, the real user may stop the virtual user who operates by himself before reaching the position where the rescue requesting user stops, but if the user can reach safely, the longer the distance is, Great sense of achievement. By extracting the virtual item based on the distance, it is possible to further enhance the sense of achievement obtained by the real user. Moreover, the motivation which responds to a real user's relief request can be raised.

(5) In a preferred aspect of the game server according to the present invention, the time when the rescue request notifying unit notifies the terminal operating the other virtual user that there is a rescue request from the one virtual user, and the other And a reward setting unit for setting a reward for the other virtual user according to a difference in time when the operation data for rescue of the one virtual user is received from a terminal that operates the virtual user.

In the above aspect, for example, the smaller the difference between the time at which the virtual user has been informed of the rescue request and the time at which the virtual user has responded to the rescue request, the higher reward is given to the virtual user. Is granted. The reward is, for example, an item that can be used in the game. Items that are advantageous for progressing the game have a high value, and real users have a high desire for acquisition. The real user can be prompted to respond more quickly to the notification of the rescue request. The frequency of exchange between virtual users in the game increases, and the game can be activated.

(6) In a preferred aspect of the game server according to the present invention, the resurrection setting unit is configured such that when the other virtual user reaches a position where the progress of the one virtual user is stopped in the predetermined course. , Receiving operation data for rescue of the one virtual user.

In the above aspect, in order for another real user who operates another virtual user to respond to the rescue request, it is necessary to cause the other virtual user to reach a stop position where the progress of one virtual user is stopped. . Even if another real user intends to respond to the rescue request, the progress of the other virtual user may stop before the other virtual user reaches the stop position. Even if a real user makes a rescue request, it is uncertain whether other real users can bring other virtual users to the stop position, and one virtual user can always be revived. Not exclusively. It is possible to give a sense of expectation to a real user who has made a rescue request whether or not a virtual user who can respond to the rescue request will reach the stop position. Also, the difficulty level of the game is improved compared to the case where other real users can respond to the rescue request by simply pressing one button on the screen without causing other virtual users to reach the stop position. And the work feeling can be wiped out more.

(7) In a preferable aspect of the game server according to the present invention, the game server further includes a user extraction unit that extracts a virtual user that satisfies a predetermined condition as the other virtual user based on the information about the one virtual user, The rescue request notifying unit notifies the terminal operating the extracted virtual user that a rescue request has been received from the one virtual user.
In the above aspect, a user extraction part extracts the virtual user which satisfy | fills predetermined conditions as another virtual user based on the information regarding one virtual user. For example, the user extraction unit extracts a virtual user having an evaluation value within a predetermined range from the evaluation value of one virtual user based on the evaluation value information of the one virtual user. That is, a virtual user having an evaluation value comparable to the evaluation value of one virtual user is extracted. The evaluation value is a parameter for evaluating a virtual user in the game, and is, for example, a level or a ranking. Further, for example, based on friend information of one virtual user, a virtual user who has a friend relationship with one virtual user is extracted. The friend relationship is a relationship that is established when one person applies for a friend in the game and the other approves it. By extracting a virtual user that satisfies a predetermined condition in relation to information related to one virtual user, it is possible to increase the probability that the real user who has received the notification of the rescue request responds to the rescue request. When the probability of responding to a rescue request increases, the frequency of exchange between virtual users in the game increases, and the game can be activated.

(8) In a preferred aspect of the game server according to the present invention, a user notification unit that notifies the extracted information about the virtual user to a terminal that operates the one virtual user, and a terminal that operates the one virtual user. A user selection receiving unit that receives a selection request for selecting any one of the extracted virtual users based on operation data, and the rescue request notification unit operates the selected virtual user The terminal is notified that a rescue request has been received from the one virtual user.
In the above aspect, the real user who made the rescue request can know the information about the virtual user extracted by the user extraction unit, and can select one virtual user from the virtual users extracted by the user extraction unit. it can. By causing the real user who has made a rescue request to select a virtual user who wants to respond to the rescue request, the willingness to respond to the rescue request of the real user who has received the rescue request notification can be enhanced.

(9) In a preferred aspect of the game server according to the present invention, the user extraction unit determines and determines the number of virtual users to be extracted according to the number of virtual users rescued by the one virtual user in the past. It is characterized by extracting a number of virtual users.
In the above aspect, for example, as the number of virtual users rescued in the past increases, the user extraction unit extracts more virtual users. And a relief request notification part notifies that there were relief requests to many virtual users which the user extraction part extracted. If the number of real users who have received the notification of the rescue request is large, the number of real users who respond to the rescue request also increases. In order to have another real user respond when he / she makes a rescue request, the real user can be prompted to respond positively to a rescue request from another real user.

(10) In a preferred aspect of the game server according to the present invention, the rescue request notifying unit receives the rescue request from the one virtual user during a predetermined period and a response when the one virtual user responds to the rescue request. According to the ratio of the number of times, a probability of notifying that there is a rescue request from the one virtual user is set, and notification is made based on the set probability.
In the above aspect, for example, in the case where the number of receptions received from the virtual user during the predetermined period is much larger than the number of responses that the virtual user responded to the relief request during the predetermined period, the rescue request is received from the virtual user. The probability of notifying that there has been set is set low. Thereby, a real user can be urged to respond positively to a rescue request from another real user.

(1) A game server according to the present invention is a game server that provides a game in which a virtual user formed on a game provided to a terminal connected via a communication network advances a predetermined course, the terminal An operation data receiving unit that receives operation data for operating the virtual user, a progress management unit that advances or stops the progress of the virtual user in the predetermined course based on the operation data, When the progress of the virtual user is stopped, based on the operation data of the terminal that operates the one virtual user, the rescue request receiving unit that receives a rescue request for allowing the one virtual user to proceed again with the, on the basis of the information on the evaluation value of the first virtual user, as other virtual users, the evaluation value comparable to the evaluation value of the one of the virtual user When the user extraction unit that extracts a virtual user and the rescue request reception unit receive the rescue request, the terminal that operates the extracted virtual user is notified that the rescue request has been received from the one virtual user. A rescue request notifying unit, and a resurrection setting unit that restores the one virtual user to a state in which the virtual user can be advanced when operation data for rescue of the one virtual user is received from a terminal that operates the extracted virtual user. And.

(2) The game server of the present invention is a game server that provides a game in which a virtual user formed on a game provided to a terminal connected via a communication network advances a predetermined course, An operation data receiving unit that receives operation data for operating the virtual user from the terminal, a progress management unit that advances or stops the progress of the virtual user in the predetermined course based on the operation data, When the progress of one virtual user is stopped, based on the operation data of the terminal that operates the one virtual user, a rescue request for receiving a rescue request for allowing the one virtual user to proceed again a receiving unit, on the basis of the information about the time of receiving the support request from the terminal operated one of the virtual user, as another virtual users, and the time A user extraction unit that extracts a virtual user whose operation data is received in a time zone such as a frequency relatively higher than a frequency in which operation data is received in another time zone, and the rescue request reception unit receives the rescue request. In this case, from the rescue request notifying unit that notifies the terminal operating the extracted virtual user that there has been a rescue request from the one virtual user, and the terminal operating the extracted virtual user, the one virtual And a revival setting unit that revives the one virtual user to a state in which the user can proceed when operation data for helping the user is received.

Claims (11)

A game server that provides a game in which a virtual user formed on a game provided to a terminal connected via a communication network advances a predetermined course,
An operation data receiving unit for receiving operation data for operating the virtual user from the terminal;
Based on the operation data, a progress management unit that advances the virtual user in the predetermined course or stops the progress;
When the progress of one virtual user is stopped, based on the operation data of the terminal that operates the one virtual user, a rescue request for receiving a rescue request for allowing the one virtual user to proceed again A reception department;
When the rescue request accepting unit accepts the rescue request, a rescue request notifying unit for notifying a terminal operating another virtual user that there is a rescue request from the one virtual user;
When receiving operation data for rescue of the one virtual user from a terminal that operates the other virtual user, a restoration setting unit that restores the one virtual user to a state in which the virtual user can proceed,
A game server comprising:   The resurrection setting unit receives operation data for relieving the one virtual user when the other virtual user reaches a position where the progress of the one virtual user is stopped in the predetermined course. The game server according to claim 1, wherein: A user extracting unit that extracts a virtual user that satisfies a predetermined condition as the other virtual user based on information on the one virtual user, further includes:
The game server according to claim 1, wherein the rescue request notification unit notifies the terminal that operates the extracted virtual user that a rescue request has been received from the one virtual user. A user notification unit for notifying information regarding the extracted virtual user to a terminal that operates the one virtual user;
A user selection receiving unit that receives a selection request for selecting any one of the extracted virtual users based on operation data of a terminal that operates the one virtual user;
The game server according to claim 3, wherein the rescue request notification unit notifies the terminal that operates the selected virtual user that a rescue request has been received from the one virtual user.   The user extraction unit determines the number of virtual users to be extracted according to the number of virtual users rescued by the one virtual user in the past, and extracts the determined number of virtual users. Item 5. The game server according to item 3 or 4.   The time when the rescue request notifying unit notifies the terminal operating the other virtual user that there was a rescue request from the one virtual user, and the one virtual user from the terminal operating the other virtual user. 6. The game according to claim 1, further comprising a reward setting unit configured to set a reward for the other virtual user according to a difference in time when the operation data to be rescued is received. server.   The rescue request notifying unit rescues from the one virtual user according to a ratio between the number of times the rescue request has been received from the one virtual user in a predetermined period and the number of times the one virtual user has responded to the rescue request. The game server according to claim 1, wherein a probability of notifying that there is a request is set, and notification is made based on the set probability. A game control method executed by a computer that provides a game in which a virtual user formed on a game provided to a terminal connected via a communication network advances a predetermined course,
Receiving operation data for operating the virtual user from the terminal;
Advancing the virtual user in the predetermined course based on the operation data, or stopping the progress;
A step of accepting a rescue request for allowing the one virtual user to proceed again based on operation data of a terminal that operates the one virtual user when the progress of the one virtual user is stopped; and ,
Notifying a terminal that operates another virtual user that there has been a rescue request from the one virtual user;
When receiving operation data for rescue of the one virtual user from a terminal that operates the other virtual user, the step of restoring the one virtual user to a state in which the one virtual user can proceed;
The game control method characterized in that the computer executes. A game program realized by a computer that provides a game in which a virtual user formed on a game provided to a terminal connected via a communication network progresses a predetermined course,
A function of receiving operation data for operating the virtual user from the terminal;
Based on the operation data, the function to advance the virtual user in the predetermined course, or stop the progress,
A function of accepting a rescue request for allowing the one virtual user to proceed again based on operation data of a terminal that operates the one virtual user when the progress of the one virtual user is stopped; ,
A function of notifying a terminal operating another virtual user that there has been a rescue request from the one virtual user;
When the operation data for rescue of the one virtual user is received from a terminal that operates the other virtual user, the computer is realized with a recovery function that restores the one virtual user to a state in which the virtual user can proceed. Game program. A game program recording medium for recording a game program to be realized by a computer that provides a game in which a virtual user formed on a game provided to a terminal connected via a communication network progresses a predetermined course,
A function of receiving operation data for operating the virtual user from the terminal;
Based on the operation data, the function to advance the virtual user in the predetermined course, or stop the progress,
A function of accepting a rescue request for allowing the one virtual user to proceed again based on operation data of a terminal that operates the one virtual user when the progress of the one virtual user is stopped; ,
A function of notifying a terminal operating another virtual user that there has been a rescue request from the one virtual user;
A game that causes the computer to realize a function of restoring the virtual user to a state in which the virtual user can proceed when receiving operation data for rescue of the virtual user from a terminal that operates the other virtual user. A game program recording medium in which a program is recorded. A game server,
The game server and one or more terminals connected via a communication network;
The game server
A game server that provides a game in which a virtual user formed on a game provided to a terminal connected via a communication network advances a predetermined course,
An operation data receiving unit for receiving operation data for operating the virtual user from the terminal;
Based on the operation data, a progress management unit that advances the virtual user in the predetermined course or stops the progress;
When the progress of one virtual user is stopped, based on the operation data of the terminal that operates the one virtual user, a rescue request for receiving a rescue request for allowing the one virtual user to proceed again A reception department;
A rescue request notifying unit for notifying a terminal operating another virtual user that there is a rescue request from the one virtual user;
A resurrection setting unit that revives the one virtual user to a state in which the one virtual user can proceed when receiving operation data to rescue the one virtual user from a terminal that operates the other virtual user;
The game system, wherein the terminal includes an operation input unit that receives the operation data.