Information processor and program

Abstract

To ease geographical restrictions set to an object game under predetermined conditions.SOLUTION: "A game information processor" (for example, a user management server 10) includes: registration means (for example, a registration part 310) for storing a player's residence site in storage means according to or without according to the player's request as a residence record (for example, a flag); and first designation means (for example, a first designation part 351) for designating a first player (for example, a player who does not satisfy a play position condition at the moment) having the residence record for showing past satisfaction of the play position condition as a challenger (for example, a solo play player or a multi-play host) who challenges an object game (for example, Quest) permitting a single play (for example, a solo play) only if the play position condition is satisfied.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present invention relates to an information processing device and a program. [Background technology]

[0002] 2. Description of the Related Art There is known an electronic game that employs a mechanism in which a plurality of mobile terminals jointly process an event that is specified according to the location of the mobile terminal (see, for example, Patent Document 1). Specifically, a monster corresponding to a specific geographical range is displayed on the screens of multiple mobile devices within that geographical range, and parameters that change the display of the monster are synchronized between nearby mobile devices via short-range wireless communication, creating the appearance that the monster is being attacked by multiple players. [Prior art documents] [Patent documents]

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

[0004] In the game described in Patent Document 1, the mobile terminals of multiple players who attack a monster must each be located within a geographical area corresponding to that monster, which means that some players find it difficult to enjoy events related to that monster due to geographical restrictions.

[0005] The problem to be solved by the present invention is to relax the geographical restrictions imposed on a target game under predetermined conditions. [Means for solving the problem]

[0006] [A] In order to solve the above problems, a "game information processing device" according to one embodiment of the present invention comprises: a registration means for storing a player's location as a location record in a storage means, with or without a request from the player; and a first designation means for designating a first player, whose location record indicates that the first player has previously satisfied a play location condition, as a challenger who will challenge a target game that can be played alone only if the play location condition is satisfied. [B] In order to solve the above problem, a "control method" of an information processing device, which is one embodiment of the present invention, includes a registration step of storing a player's location as a location record in a storage means, either at the request of the player or not, and a first designation step of designating a first player, whose location record indicates that the first player has previously satisfied a play location condition, as a challenger who will challenge a target game that can be played alone only if the play location condition is satisfied. [C] In order to solve the above problems, the "control program" of one aspect of the present invention causes a computer of an information processing device to realize a registration function for storing a player's location as a location record in a storage means, with or without the request of the player, and a first designation function for designating a first player, whose location record indicates that the first player has previously satisfied a play location condition, as a challenger who will challenge a target game that can be played alone only if the play location condition is satisfied. [D] In order to solve the above problem, a control program recorded in a "computer-readable recording medium" which is one embodiment of the present invention causes a computer of an information processing device to realize a registration function for storing a player's location as a location record in a storage means, with or without the request of the player, and a first designation function for designating a first player, whose location record indicates that the first player has previously satisfied a play location condition, as a challenger who will challenge a target game which can be played alone only if the play location condition is satisfied.

[0007] The following technical limitations may be added to the "game information processing device" in [A] above. Similar technical limitations may also be added to the "control method" in [B] above, the "control program" in [C] above, and the control program recorded on the "recording medium" in [D] above. The first designation means designates the first player who does not currently satisfy the play position condition. The first designation means designates the first player as a challenger who will host a cooperative play of the target game, and further includes a second designation means for designating a second player who has applied to the recruitment of the first player as a challenger who will participate in the cooperative play of the target game hosted by the first player. The second designation means designates the second player who does not currently satisfy the play position condition. The second designation means designates the second player who is currently located in the vicinity of the current location of the first player. The second designation means designates the second player who is currently located in the vicinity of a past location of the first player. The second designation means designates the second player whose location record indicates that the second player was previously located near a past location of the first player. The play position condition is to be located in the vicinity of a predetermined position, and the game device further includes a setting means for setting a participation parameter used when the second player participates in cooperative play of the target game in accordance with a current positional relationship between the predetermined position and the second player. The setting means sets the participation parameters so that the second player who does not satisfy the play position condition is at a relatively disadvantage compared to a player who satisfies the play position condition. The setting means sets the participation parameters by further taking into consideration the current positional relationship between the first player and the predetermined position. The setting means sets the participation parameter so that the second player is at a relatively disadvantage when the first player does not currently satisfy the play position condition compared to when the first player currently satisfies the play position condition.

[0008] In this specification, the following terms are used: "Game" refers to an electronic game provided at least in part in an online game service. In a broad sense, it refers to the game service itself, and in a narrow sense, it refers to each individual stage that constitutes a game service. "Player" refers to a user of the game service. "Play" means that a player plays a particular game. "Solo play" means play by a single player. "Cooperative play" refers to synchronous play by multiple players in a cooperative relationship. In cooperative play, a cooperative relationship is formed between a player (host) who hosts a cooperative play of a specific game and recruits players (guests) who respond to the recruitment and participate in the cooperative play of the specific game, and the progress of play is synchronized between the players. "Challenger" means a player who challenges another to play a particular game. "Via" refers to, for example, a range of a first predetermined distance from the location of a player. "Around" refers to, for example, a range of a second predetermined distance from the location of a player. In these examples, the relationship between the first distance and the second distance can be set arbitrarily. "Specified position" refers to, for example, when a virtual space is formed in correspondence with a real space and a spot position is defined within the virtual space, the position in the real space corresponding to the spot position. "Play location conditions" refers to conditions required of a challenger who challenges to play a specific game, and relate to the location at which the challenger plays. For example, the challenger must be located near a specified location. Note that there may be differences between the conditions required of a challenger playing alone and the conditions required of each challenger in cooperative play. There may also be differences between the conditions required of a challenger who hosts cooperative play and the conditions required of each challenger who participates in the cooperative play. "Event" refers to the cause of the addition of a new location record or the deletion of an existing location record. Causes of addition include a player's instruction. Causes of deletion include a player's instruction, execution of a periodic process, expiration of the validity period, and passage of the expiration date. "Parameters" refers to at least a portion of the setting data used to play a specific game. Parameters are a concept that includes in-game parameters that mainly affect the progress of the game and out-game parameters that mainly affect reward calculations after the game ends. Even if the target of play is the same, there may be differences between the parameters for a challenger in a solo play and the parameters for each challenger in a cooperative play. There may also be differences between the hosting parameters for a challenger who hosts a cooperative play and the participation parameters for each challenger who participates in the cooperative play. Furthermore, when there are multiple challengers participating in a specific cooperative play, there may be differences in the participation parameters between the challengers. "Applicable conditions" refers to the conditions related to the location of the player among the conditions for receiving a special benefit that is applicable to playing a specific game. For example, the player's location must be within a specific location. "Location benefits" refers to geographic benefits granted to players who currently meet the applicable conditions. The concept of location benefits includes in-game benefits that mainly affect the progress of the game and out-game benefits that mainly affect the calculation of rewards after the game ends. "Fictitious location privilege" refers to a geographical privilege given to a player who does not currently meet the applicable conditions but met them in the past. The fictitious location privilege is a concept that includes in-game privileges that mainly affect the progress of the game and out-game privileges that mainly affect the calculation of rewards after the game ends. The contents of the privilege can be set to be inferior to the location privilege. "Fake location benefit" refers to a geographic benefit that may be granted to a player who has not satisfied the applicable conditions from the past to the present when playing cooperatively with other players. For example, if a location benefit or fictitious location benefit is applied to a cooperative play by a player, the corresponding benefit by other players may not be granted to that player. A pseudo-location benefit is applied to the cooperative play. The pseudo-location benefit is a concept including an in-game benefit that mainly affects the progress of the game and an out-game benefit that mainly affects the calculation of the reward after the game ends. The content of the benefit can be set to be inferior to the location benefit and the fictitious location benefit. Effect of the Invention

[0009] The present invention permits a first player, who has a location record of having previously satisfied a play location condition, to play a target game that can be played alone only when the play location condition is satisfied, regardless of whether the play location condition is currently satisfied. In this respect, the present invention relaxes the geographical restrictions imposed on the target game. [Brief description of the drawings]

[0010] [Figure 1] The network configuration is illustrated in the following example. [Figure 2-1] 1 illustrates an example of a hardware functional configuration of a server device (embodiment). [Figure 2-2] 1 illustrates an example of a hardware functional configuration of a user device (embodiment). [Diagram 3] The following shows an example of a software functional configuration. (Example) [Figure 4] The database configuration is illustrated below. (Example) [Diagram 5] The screen display update procedure is illustrated below (Example). [Figure 6] The flag setting procedure is illustrated below (Example). [Figure 7] The flag clearing procedure is illustrated below. [Figure 8] The spot effect acquisition procedure is illustrated. (Example) [Figure 9] The procedure for performing solo play will be illustrated. (Example) [Figure 10] FIG. 1 is an explanatory diagram of positional relationships in solo play (embodiment); [Figure 11] The following is an example of how to start playing a normal quest. (Example) [Figure 12] The procedure for starting a spot-limited quest is illustrated below. (Example) [Figure 13] FIG. 1 is an explanatory diagram of positional relationships in solo play (embodiment); [Figure 14] The procedure for starting a spot-limited quest is illustrated below. (Example) [Figure 15] The procedure for executing multiplay is illustrated below. (Example) [Figure 16] The recruitment procedure for short-distance multiplayer is illustrated below. (Example) [Figure 17] The application procedure for short-distance multi-events is illustrated below. (Example) [Figure 18] FIG. 1 is an explanatory diagram of the positional relationship in a short-distance multi-angle camera (Example). [Figure 19] FIG. 1 is an explanatory diagram of the positional relationship in a short-distance multi-angle camera (Example). [Figure 20] FIG. 1 is an explanatory diagram of the positional relationship in a short-distance multi-angle camera (Example). [Figure 21] FIG. 1 is an explanatory diagram of the positional relationship in a short-distance multi-angle camera (Example). [Figure 22] FIG. 1 is an explanatory diagram of the positional relationship in a short-distance multi-angle camera (Example). [Figure 23] The following is an example of the recruitment procedure for SNS multimedia. [Figure 24] The application procedure for SNS multi-entry is illustrated below. (Example) [Diagram 25] FIG. 1 is an explanatory diagram of positional relationships in SNS Multi (Example). [Figure 26] FIG. 1 is an explanatory diagram of positional relationships in SNS Multi (Example). DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] [1. Embodiment] [1-1. Embodiment 1] [1-1-1. Overview] The first embodiment relates to electronic games that use the geographic location of a terminal device or player determined using a GPS. The game information processing device according to the first embodiment is configured to relax the geographical restrictions set for the target game under predetermined conditions.

[0012] [1-1-2. Game information processing device] The game information processing device (e.g., the user management server 10) of embodiment 1 includes a first designation means (e.g., a first designation unit 351) for designating a first player who satisfies a play position condition as a challenger (e.g., a host) who hosts cooperative play (e.g., multiplayer) of a target game (e.g., a quest) in which single play (e.g., solo play) is possible only if the play position condition is satisfied, and a second designation means (e.g., a second designation unit 352) for designating a second player who has applied to be recruited by the first player as a challenger (e.g., a guest) who will participate in the cooperative play of the target game hosted by the first player (e.g., a player who does not currently satisfy the play position condition).

[0013] [1-2. Embodiment 2] [1-2-1. Overview] A second embodiment relates to electronic games that use the geographic location of a terminal device or player determined using a GPS. The game information processing device according to the second embodiment is configured to relax the geographical restrictions set for the target game under predetermined conditions.

[0014] [1-2-2. Game information processing device] The game information processing device (e.g., user management server 10) of embodiment 2 includes a registration means (e.g., registration unit 310) for storing the player's location as a location record (e.g., a flag) in a storage means (e.g., storage unit 370) with or without the request of the player, and a first designation means (e.g., first designation unit 351) for designating a first player (e.g., a player who does not currently satisfy the play position condition) who has the above-mentioned location record indicating that he or she has previously satisfied the play position condition as a challenger (e.g., a solo play player, a multiplayer host) who will challenge a target game (e.g., a quest) in which single play (e.g., solo play) is possible only if the play position condition is satisfied.

[0015] The first designation means may be further configured to include a second designation means (e.g., a second designation unit 352) that designates the first player as a challenger who will host cooperative play of the target game, and designates a second player who has applied to the recruitment of the first player as a challenger who will participate in cooperative play of the target game hosted by the first player (e.g., a player who does not currently satisfy the play position condition).

[0016] [1-3.Embodiment 3] [1-3-1. Overview] A third embodiment relates to electronic games that use the geographic location of a terminal device or player determined using a GPS. The game information processing device according to the third embodiment is configured to relax the criteria for providing a geographical effect under a predetermined condition.

[0017] [1-3-2. Game information processing device] A game information processing device (e.g., a user management server 10) of embodiment 3 includes a designation means (e.g., a designation unit 350) that designates a plurality of players, including at least a first player and a second player who does not satisfy the conditions for application of a location benefit (e.g., a spot benefit), as challengers (e.g., a host or guest of the multiplayer) in cooperative play (e.g., multiplayer) of a specified game (e.g., a quest), and a setting means (e.g., a setting unit 360) that applies a pseudo-location benefit that is inferior to the location benefit to the cooperative play by the second player when the location benefit is applied to the cooperative play by the first player.

[0018] When the application condition is that the player is currently located in the vicinity of a predetermined position, the setting means sets the predetermined position to the first player who does not currently satisfy the application condition but has satisfied it in the past. A fictitious presence benefit may be applied that is inferior to the presence benefit and superior to the pseudo presence benefit. At this time, the setting means may set the pseudo-presence benefit to be applied to the cooperative play by the second player in accordance with the content of a benefit to be applied to the cooperative play by the first player. EXAMPLES

[0019] 2. Working Examples [2-1. Overview] The present embodiment relates to a gaming service (embodiment service) that is provided at least in part online. In the service of the embodiment, an electronic game (game in a broad sense) is provided to a player in which the player controls four monsters that make up a deck by performing predetermined actions in order to challenge multiple stages (game in a narrow sense) prepared in the game in order. Hereinafter, the stages are referred to as "quests."

[0020] There are two ways to play a quest: solo play, in which one player challenges the quest on their own, and multiplayer, in which two to four players challenge the quest together. In a multiplayer game, a cooperative relationship is formed between a host who organizes the game and recruits companions, and guests who respond to the recruitment and participate in the game, and the progress of the game is synchronized between players.

[0021] There are two types of recruitment forms for hosts to recruit guests: recruitment that mainly targets unspecified players in the vicinity, and recruitment that mainly targets specific players in a given location. In the following, the former type of multiplayer is called close-range multiplayer, and the latter type of multiplayer is called SNS multiplayer.

[0022] [2-2. Features] [2-2-1. Spot placement and spot benefits] A virtual space that is geographically associated with the real space is formed, and the display (map display) of the virtual space on the screen is changed in conjunction with the physical movement of the player in the real space. A large number of spots are arranged in the virtual space. When a player is located near a position (predetermined position) in real space that corresponds to a certain spot location, the player is granted a spot benefit (spot effect, eligibility to play spot-limited quests) that is associated with the spot location.

[0023] [2-2-2. Flag placement and spot rewards] A player can register his / her own location in real space as a record (location record). A flag is set at a location in virtual space that corresponds to the recorded location. When there is a location record indicating that a player was present in the vicinity of a position (predetermined position) in real space corresponding to a certain spot placement location, the player is granted a benefit (fictitious spot benefit) that is inferior to the spot benefit set in association with that spot placement location. The upper limit of the number of flags that can be set can be set arbitrarily. In the service of the embodiment, the upper limit is set to 1. A flag that has already been set is invalidated by erasing it by the player, setting a new flag, etc. Also, it is cleared periodically (for example, by daily batch processing).

[0024] [2-2-3. Types of spot benefits] Examples of spot benefits include the following: (a) Acquire a virtual currency item fragment (an object that can be exchanged for a specific virtual currency item when multiple points are collected) (b) Acquire a spot-exclusive monster (c) Become eligible to play a spot-only quest (d) The parameters that primarily affect the progress of the quest (quest progress parameters, progress parameters) change in a favorable direction. (e) The parameters that mainly affect the calculation of the clear reward (reward calculation parameters, calculation parameters) change in a favorable direction.

[0025] The above (d) is, for example, the following benefits. After being granted to a player, these benefits can be applied to the play of the player when the player plays a specific quest. (d-1) The level of the emblem you are wearing increases (d-2) Increases the hit points (HP), attack power, and speed of monsters of a certain attribute (d-3) Increases the activation rate of luck skills (e.g., shield, friendship combo critical, guide)

[0026] The above (e) is, for example, the following benefits. After being granted to a player, these benefits can be applied to the play of the player when the player plays a specific quest. (e-1) Refund a portion of your stamina when you clear a quest (e-2) Experience points increase (e-3) Increased points earned (e-4) Luck increases (i.e., the probability of obtaining a luck bonus increases) (e-5) Increases the chance of finding additional treasure chests

[0027] [2-2-4. Relaxation of play position conditions in multiplayer] There are spot-specific quests that can be played solo only if you are located near a location (predetermined location) that corresponds to a specific spot (i.e., if the play location condition is met). In the service of the embodiment, a player who has a record indicating that he / she has previously satisfied the play position condition is permitted to challenge the spot-limited quest. Therefore, a player who does not currently satisfy the play position condition may play the spot-limited quest alone or in cooperation.

[0028] In addition, if a guest is participating in a multiplayer game hosted by a host who satisfies the play position condition, the guest is permitted to challenge the multiplayer game of the spot-limited quest regardless of whether the play position condition is met. At this time, the participation parameters (progress parameters, calculation parameters) for the guest are adjusted according to the positional relationship between the guest and the spot from the past to the present. Furthermore, if a guest is participating in cooperative play hosted by a host who has a record indicating that he or she satisfied the play position condition, the host will be allowed to play the spot-limited quest in multiplayer regardless of whether or not the play position condition is satisfied. At this time, the guest's participation parameters (progress parameters, calculation parameters) are adjusted according to the positional relationship between the host and guest and the spot from the past to the present.

[0029] [2-2-5. Relaxation of conditions for bonus application through multiplayer] In the service of the embodiment, when a spot effect (location benefit or fictitious location benefit) is applied to a player who challenges a multiplayer game, the spot effect is applied to other players who challenge the multiplayer game. An inferior spot effect (pseudo location benefit) is applied to these spot effects. At this time, depending on the content of the spot effect applied to a certain player, the content of the spot effect applied to other players who do not satisfy the application conditions is adjusted. For example, when a certain spot effect is applied to a host who satisfies the application conditions of the spot effect, an inferior spot effect is applied to all guests who do not satisfy the application conditions. Also, when a certain spot effect is applied to a guest who satisfies the application conditions of the spot effect, an inferior spot effect is applied to the host and other guests who do not satisfy the application conditions.

[0030] [2-2-6. Summary] As described above, in the service of the embodiment, a large number of spots are placed in a virtual space that is geographically associated with real space, and benefits (e.g., spot effects, eligibility to play spot-limited quests) are provided on the condition that the user is located in the vicinity of a position (predetermined position) in real space that corresponds to the spot placement position. On the other hand, the conditions under which the benefit is applied (e.g., time conditions, spatial conditions) are relaxed in certain cases. In particular, when a benefit is applied to at least one player among a plurality of players, a benefit similar to the benefit is applied to other players who cooperate with the one player. Such a mechanism increases the interest of the service of the embodiment and encourages players to take on quests in multiplayer mode.

[0031] [2-3. System configuration of the embodiment] [2-3-1. Network configuration] [2-3-1-1. Overview] 1 illustrates a network configuration of a system according to an embodiment. The system according to the embodiment provides a service according to the embodiment to a user. As illustrated in FIG. 1, the system of the embodiment includes a user management server 10 that manages users of the service of the embodiment, a data management server 20 that manages data related to the service of the embodiment, and a plurality of user terminals 30 (30-1, 30-2, ... 30-n) (n: natural number) used respectively by a plurality of users.

[0032] The user management server 10 and the user terminal 30 can transmit and receive data via a communication network 40. The data management server 20 can access a built-in or externally connectable storage 21. The user management server 10 can access data stored in the storage 21 via the data management server 20. The communication network 40 may include at least one of existing networks such as the Internet, a mobile phone network, a wireless wide area network (WAN), a wireless local area network (LAN), and Ethernet (registered trademark).

[0033] [2-3-1-2. User management server] The user management server 10 is a server device (computer) in which a Web server program is installed. In response to a request, the user management server 10 causes the data management server 20 to obtain necessary data from the storage 21 and provides the data to the request source (response). In addition, in response to a request, the user management server 10 causes the data management server 20 to register necessary data in the storage 21. A server system may be configured by linking a plurality of server devices to share the functions of the user management server 10 or distribute the load on the user management server 10.

[0034] [2-3-1-3. Data management server] The data management server 20 is a server device (computer) in which a DB server program is installed, and configures a DBMS (DataBase Management System) together with the storage 21. In response to a request, the data management server 20 obtains necessary data from the storage 21 and provides the data to the request source (response). In response to a request, the data management server 20 also registers necessary data in the storage 21. The storage 21 is a storage device that stores data related to the service of the embodiment. A server system may be configured by linking a plurality of server devices to share the functions of the data management server 20 or to distribute the load on the data management server 20. Also, a plurality of storage devices may be prepared and the storage 21 may store data separately for each type, or the data stored in the storage 21 may be distributed among a plurality of storage devices.

[0035] [2-3-1-4. User terminal] The user terminal 30 is a user device (computer) on which a predetermined game program is installed. In this embodiment, the user device may be a general-purpose portable device (e.g., a mobile phone, a smartphone, a tablet terminal, a tablet PC (personal computer), a wearable device, etc.) on which a program can be installed, or a general-purpose processing device (e.g., a PC (personal computer), etc.).

[0036] [2-3-2. Hardware Functional Configuration] [2-3-2-1. Hardware functional configuration of the server device] FIG. 2-1 illustrates an example of a hardware functional configuration of a server device. The server device illustrated in FIG. 2-1 has a control processing device 211 including an MPU (Micro-Processing Unit) and a ROM (Read Only Memory), a main memory device 212 including a RAM (Random Access Memory), an auxiliary memory device 213 including an HDD (Hard Disc Drive), an input device 214 including a mouse and a keyboard, an output device 215 including a display and speakers, and a communication control device 216 including a network card (Network Interface Card).

[0037] The main memory device 212, the auxiliary memory device 213, the input device 214, the output device 215, and the communication control device 216 are each connected to the control processing device 211 via a bus line. The control processing device 211 (1) loads a program stored in the auxiliary memory device 213 onto the main memory device 212, (2) acquires data from at least one of the input device 214, the auxiliary memory device 213, and the communication control device 216 in accordance with the instructions of the program, (3) calculates and processes the acquired data in accordance with a procedure specified in the program, and (4) provides the calculated and processed data to at least one of the auxiliary memory device 213, the output device 215, and the communication control device 216.

[0038] [2-3-2-2. Hardware functional configuration of user device] FIG. 2-2 illustrates an example of a hardware functional configuration of a user device. The user device illustrated in FIG. 2-2 has at least an MPU 221 constituting a control processing unit, a RAM 231 constituting a main memory unit, a ROM 232 and an EEPROM (Electrically Erasable Programmable Read-Only Memory) 233 constituting an auxiliary memory unit, a touch panel display 241 constituting an input unit and display unit, a speaker 242 constituting an audio output unit, a NIC (Network Interface Controller) 251 and a wireless LAN (Local Area Network) chip 252 constituting a communication control unit, and a GPS (Global Positioning System) unit 261 constituting a position acquisition unit.

[0039] The RAM 231, the ROM 232, the EEPROM 233, the touch panel display 241, the speaker 242, the NIC 251, the wireless LAN chip 252, and the GPS unit 261 are connected to the MPU 221 via a bus line. MPU 221 (1) loads a program stored in ROM 232 or EEPROM 233 into RAM 231, (2) acquires data from at least one of touch panel display 241, EEPROM 233, NIC 251, wireless LAN chip 252, and GPS unit 261 in accordance with instructions from the program, (3) calculates and processes the acquired data in a procedure specified in the program, and (4) provides the calculated and processed data to at least one of EEPROM 233, touch panel display 241, speaker 242, NIC 251, and wireless LAN chip 252.

[0040] [2-3-3. Software Functionality Configuration] FIG. 3 illustrates a software functional configuration of the system according to the embodiment. 3, the user management server 10 includes a registration unit 310, a reception unit 320, a search unit 330, a provision unit 340, a designation unit 350, and a setting unit 360. The designation unit 350 includes a first designation unit 351 and a second designation unit 352. In addition, the data management server 20 includes a storage unit 370.

[0041] The software functions of the user management server 10 and the data management server 20 are realized by installing an OS (Operating System) for server devices and programs that run on the OS in the server devices, respectively. The program to be installed in the server device may be distributed in a state recorded on a recording medium such as a CD (Compact Disc), a DVD (Digital Versatile Disk), an MO disk (Magneto-Optical disk), or a flash memory and read from the recording medium into the server device, or may be supplied to the server device by being superimposed on a carrier wave via communication network 40 or other communication network.

[0042] The software functions of the user terminal 30 are realized by installing an OS (Operating System) for the user device and a game program that runs on the OS in the user device. In addition, instead of a game program, the software functions of the user terminal 30 can also be realized by installing a Web browser program that runs on the above-mentioned OS for user devices and a game program (plug-in) that runs on the Web browser program on the user device.

[0043] The OS for the user device is generally installed in the user device at the time of shipment. Other programs to be installed in the user device are generally supplied to the user device via the communication network 40 by being superimposed on a carrier wave. The above-mentioned and other programs to be installed in the user device may be distributed in a state recorded on a recording medium such as a CD (Compact Disc), a DVD (Digital Versatile Disk), an MO disk (Magneto-Optical disk), or a flash memory, and may be read from the recording medium into the user device.

[0044] In response to an individual request from a player, the registration unit 310 registers the location of the player or a location similar thereto in the storage unit 370. A flag for the player is set at a position in the virtual space corresponding to the position registered in the storage unit 370. Note that the configuration may be such that the location of the player or a location similar thereto is registered in the storage unit 370 without an individual request from the player. In addition, the registration unit 310 invalidates the flag stored in the storage unit 370 through a predetermined procedure or upon a predetermined trigger. For example, the registration unit 310 invalidates the flag through a procedure for erasing the flag by the player. For example, when a new flag is placed by a player and the number of flags placed reaches the upper limit (1 in the service of the embodiment), flags that were placed earlier are invalidated. Also, for example, the flags are invalidated in daily batch processing.

[0045] Furthermore, in response to an individual request from a player, the registration unit 310 registers a record in which a spot effect registered in association with a specific spot has been applied in association with the player in the storage unit 370. The spot effect registered in the storage unit 370 can be applied when the player plays a quest later. Furthermore, the registration unit 310 invalidates the spot effects stored in the storage unit 370 through a predetermined procedure or upon a predetermined trigger. For example, when a new spot effect is acquired by a player and the number of installed spots reaches the upper limit (1 in the service of the embodiment), the registration unit 310 invalidates the spot effects acquired earlier. Also, for example, the registration unit 310 invalidates the spot effects in daily batch processing.

[0046] The reception unit 320 receives challenges to solo play and multiplayer quests from the user terminal 30 of a player who is eligible to challenge. In particular, the reception unit 320 receives invitations for multiplayer play from the user terminal 30 of a player who is eligible to challenge, and also receives applications for the invitation from the user terminal 30 of a player who meets the participation conditions for the invitation. In response to a request from the user terminal 30, the search unit 330 searches the virtual waiting room information stored in the storage unit 370 for information in which the requesting player satisfies the participation conditions, and returns the search results to the requester.

[0047] The providing unit 340 provides display data to the user terminal 30. The providing unit 340 also provides parameters for progressing through a quest (progress parameters) and data for displaying results to the user terminal 30 of a quest challenger. The designation unit 350 includes a first designation unit 351 that designates a challenger in solo play and a challenger who hosts a multiplay, and a second designation unit 352 that designates a challenger who will participate in the multiplay.

[0048] The first designation unit 351 designates, for example, the following players as challengers who will challenge the spot-limited quest solo play. Note that the latter players do not need to currently satisfy the play position condition. Players who currently meet the play position conditions A player who has placed a flag in a position that satisfies the play position condition (i.e., a player who has previously satisfied the play position condition)

[0049] In addition, the first designation unit 351 designates, for example, the following players as challengers (hosts) who will host the multiplay of the spot-limited quest. Note that the latter players do not need to currently satisfy the play position condition. Players who currently meet the play position conditions A player who has placed a flag in a position that satisfies the play position condition (i.e., a player who has previously satisfied the play position condition)

[0050] The second designation unit 352 designates, for example, the following players as challengers (guests) who will participate in the multiplay of the spot-limited quest. Players who have applied to a host's recruitment and currently meet the play position conditions Players who applied to a host who previously met the play position conditions In this case, the guest does not need to currently satisfy the play position condition as long as the following conditions are met. Currently located near the host's current location. - The host was previously located near the current location (i.e., the flag was set) (There are.) The host is currently located near its past location (i.e., the location where the flag was set). - The host has previously been located (i.e., has set a flag) in the vicinity of its previous location (i.e., the flag setting location). The host accessed a virtual waiting room identified by a URL obtained from a social networking site or the like outside the system of the embodiment.

[0051] The setting unit 360 sets parameters related to the quest (for example, parameters for progress, parameters for calculation) as follows, for example. Set parameters for solo challengers, taking into account the spot effects applied to that challenger. Set parameters for the challenger (host) who hosts a multiplayer game, taking into account the spot effects that are applied to the challenger and the challengers (guests) who participate in the multiplayer game. In particular, if a specific spot effect is applied to the guest, apply an equal or lower effect to the host. Set parameters for challengers (guests) participating in a multiplayer game, taking into account spot effects applied to the challenger, the challenger (host) hosting the multiplayer game, and other challengers (guests) participating in the multiplayer game. In particular, if a specific spot effect is applied to the host or other guests, apply an equal or lower effect to the guest.

[0052] Furthermore, the setting unit 360 sets parameters related to the spot-limited quest (for example, parameters for progress, parameters for calculation), for example, as follows. Set the parameters for challengers who take on solo play of spot-limited quests so that they differ depending on the past and present location of the challenger and the spot. In particular, set the parameters for the challenger so that if the challenger is currently near a specified location, he or she will be at a relative advantage, and if the challenger has been near the specified location in the past but is not currently near the specified location, he or she will be at a relative disadvantage. Set parameters for the challenger (host) who hosts a multiplayer spot-limited quest so that they differ depending on the past and present location of the challenger and the spot. In particular, set parameters for the host so that the host is at a relative advantage when he or she is currently near a given location, and at a relative disadvantage when the host has been near the given location in the past but is not currently near the given location. Parameters for challengers (guests) participating in multiplayer for spot-limited quests are set so that they differ depending on the positional relationship between the host of the multiplayer and the spot from the past to the present, and the positional relationship between the guest and the spot from the past to the present. In particular, parameters for the guest are set so that the host is relatively advantageous when he is currently near the designated location, and is relatively disadvantaged when he has been near the designated location in the past but is not currently near the designated location. In addition, parameters for the guest are set so that the degree of advantage is reflected in the following order: when the guest is currently near the designated location, when the host has been near the designated location in the past but is not currently near the designated location, and when the host has never been near the designated location from the past to the present.

[0053] [2-3-4. Database configuration] FIG. 4 illustrates an example of a database configuration in the system of the embodiment. The player management information (FIG. 4(a)) is added at the time of initial setting by each player, and is updated before the start of play of a quest or after play ends. The spot definition information (FIG. 4(b)), spot type definition information (FIG. 4(c)), spot effect setting information (FIG. 4(d)), and flag state definition information (FIG. 4(f)) are added or deleted at any time by the operator of the service of the embodiment. Flag management information (Fig. 4(e)) and spot effect management information (Fig. 4(g)) are added by each player through a predetermined procedure and are periodically cleared. Virtual waiting room information (Fig. 4(h)) and virtual waiting management information (Fig. 4(i)) are generated when a multiplayer invitation is accepted.

[0054] (1) Player management information The storage unit 370 stores player management information for managing various parameters related to each player. As illustrated in FIG. 4(a), the player management information associates at least a "player ID" unique to each player with an "experience value" and a "player rank."

[0055] (2) Spot definition information The storage unit 370 stores, for each spot, spot definition information that defines various parameters related to that spot. As illustrated in FIG. 4(b), the spot definition information associates at least a "spot type ID", a "spot position", and an "effect type ID" with a "spot ID". The "spot position" indicates the location of the spot in the virtual space. In this embodiment, since the virtual space is geographically associated with the real space, the "spot position" is specified by data (e.g., latitude, longitude) representing the geographical position in the real space.

[0056] (3) Spot type definition information The storage unit 370 stores, for each spot type, spot type definition information that defines various parameters related to the spot type. As illustrated in FIG. 4(c), the spot type definition information at least associates a "spot type ID" with a "spot icon path." The "spot icon path" is information that contributes to identifying the spot icon (image) that is displayed at the spot location and indicates the type of spot.

[0057] (4) Spot effect setting information The storage unit 370 stores spot effect setting information that sets spot effects for each effect type. As illustrated in FIG. 4(d), the spot effect setting information associates "value 1," "value 2," "value 3," . . . with an "effect type ID." "Value 1", "Value 2", "Value 3", ... are respectively values ​​after a change to a specific parameter (progress parameter or calculation parameter) used in the service of the embodiment, or values ​​used in the change process of the parameter. Note that "Value 1", "Value 2", and "Value 3" may be values ​​used in parameter settings when a spot effect, a fictitious spot effect, and a pseudo spot effect are applied, respectively.

[0058] (5) Flag management information The storage unit 370 stores, for each player, flag management information for managing various parameters related to the flags placed by that player. As illustrated in FIG. 4(e), the flag management information associates at least a "flag state ID", a "flag position", and an "invalid flag" with a "player ID". The "flag position" indicates the position where the flag is set in the virtual space. In this embodiment, since the virtual space is geographically associated with the real space, the "flag position" is specified by data (e.g., latitude, longitude) that indicates the geographic position in the real space. The "invalid flag" indicates that the flag is invalid when it is significant. When a flag is set for a specific spot, the "flag position" may be set to the "spot position", or the "flag position" may be replaced with the "spot ID". In the latter configuration, the setting position of the flag is specified by the arrangement position of the spot identified by the "spot ID".

[0059] (6) Flag state definition information The storage unit 370 stores flag state definition information that defines, for each flag state, various parameters related to that flag state. As illustrated in FIG. 4(f), the flag state definition information at least associates a "flag icon path" with a "flag state ID." The "flag icon path" is information that contributes to identifying the flag icon (image) that is displayed at the flag installation position and indicates the state of the flag.

[0060] (7) Spot effect management information The storage unit 370 stores spot effect management information for managing various parameters related to the spot effect that is granted to each player through an acquisition procedure performed by that player. As illustrated in FIG. 4(g), the spot effect management information associates at least a "status" and an "invalid flag" with a "player ID" and a "spot ID." "Status" indicates the application status of the spot effect (e.g., acquired / applied). If there is a limit to the number of times it can be applied, it may also indicate the remaining number of times it can be applied. "Invalid Flag" indicates that the spot effect is invalid when it is significant. In addition, the "invalid flag" is made significant, for example, when the number of times of application reaches an upper limit (1 in the service of the embodiment) or when a new spot effect is acquired and the number of acquisitions reaches an upper limit (1 in the service of the embodiment).

[0061] (8) Virtual waiting room information The storage unit 370 stores virtual waiting room information that records various parameters related to the virtual waiting room corresponding to each multiplayer game invitation. As illustrated in FIG. 4(h), the virtual waiting room information associates at least a "recruiter" (player ID), a "multiplay category", a "conditions for participation", and a "status" with a "virtual waiting room ID". The "multiplayer category" indicates, for example, a short-distance multiplayer or an SNS multiplayer. The "participation conditions" are, for example, time conditions, spatial conditions (geographical conditions), passwords, etc. The "status" indicates the recruitment status of the multiplayer (for example, recruitment in progress / recruitment closed).

[0062] (9) Virtual standby management information The storage unit 370 stores virtual waiting management information for managing applicants for the recruitment for each virtual waiting room. As exemplified in FIG. 4(i), the virtual standby management information at least associates one or more "applicants" (player IDs) with a "virtual standby room ID."

[0063] [2-4. In-game actions before carrying out a quest] [2-4-1. Screen display update procedure] Fig. 5 illustrates a procedure for updating a screen display in the system of the embodiment. Fig. 5 shows a procedure in which a player A carries a user terminal 30a and moves through real space, and the map display on the screen of the user terminal 30a is updated as needed. [S505] The user terminal 30a accepts a map display instruction operation by Player A. The map display instruction operation is, for example, a tap operation on a “Map display” menu that is displayed by tapping a certain tab on the home screen. [S510] The user terminal 30a identifies its current location (where it is currently located). The GPS unit 261 is used to identify the current location. [S515] The user terminal 30a requests the user management server 10 to provide display data. The request includes location data indicating the current location of the user terminal 30a. [S520] The user management server 10 provides display data to the user terminal 30a. The display data includes at least one map image data or a plurality of map image data (or their URLs) representing a map of a predetermined range of the virtual space corresponding to a certain range including the current position of the user terminal 30a, and icon data (or their URLs) and other parameters of objects to be displayed in the predetermined range on the map (in the service of the embodiment, spots located in an approximately circular area with a radius of 50 m centered on the current position and the player's flag placed in the approximately circular area). [S525] The user terminal 30a updates the screen display. A map of a predetermined range is displayed on the screen of the user terminal 30a, and icons of objects (spots, flags, etc.) are arranged at the corresponding positions on the map. [S530] When the predetermined time has elapsed, the process returns to [S510]. After that, as long as "map display" is selected on the user terminal 30a, the procedures from [S510] to [S525] are repeated at predetermined time intervals.

[0064] [2-4-2. Flag installation procedure] Fig. 6 illustrates a flag setting procedure by the system of the embodiment. Fig. 6 shows a procedure in which a player A holds a user terminal 30a and moves through real space to set a flag at a position in the virtual space that corresponds to the player A's current location. [S605] The user terminal 30a accepts a flag installation instruction operation by Player A. The flag installation instruction operation is, for example, a tap operation on a flag installation command. [S610] The user terminal 30a identifies its current location (where it is currently located). The GPS unit 261 is used to identify the current location. [S615] The user terminal 30a instructs the user management server 10 to set a new flag. The instruction includes location data indicating the current location of the user terminal 30a. [S620] The user management server 10 updates the flag management information (FIG. 4(e)) stored in the storage 21. Specifically, new flag management information is added in association with the player ID of player A, and the position indicated by the position data is set as the "flag position." Additionally, if there is flag management information of a valid flag associated with player A, the "invalidated flag" is updated (made valid) to be invalid. [S625] The user management server 10 provides display data to the user terminal 30a. The display data is the same as that provided in [S520] (FIG. 5). [S630] The user terminal 30a updates the screen display. A map of a predetermined area is displayed on the screen of the user terminal 30a, and an icon of the newly installed flag is placed at the corresponding position on the map.

[0065] Note that a configuration may be adopted in which a flag is set for a spot only when the spot is displayed on the map (when the spot is located in the vicinity of a position corresponding to the spot arrangement position). In this case, the user terminal 30a may receive a flag setting instruction operation by the player A for the spot by tapping on a flag setting command displayed by tapping on the icon of the spot displayed on the map. The user management server 10 may set the "spot position" of the spot located in the vicinity of the position indicated by the position data to the "flag position".

[0066] [2-4-3. Flag deletion procedure] 7 illustrates a flag deletion procedure in the system of the embodiment. FIG 7 shows a procedure in which player A deletes an already placed flag by operating the user terminal 30a. [S705] The user terminal 30a accepts a flag deletion instruction operation by Player A. The flag deletion instruction operation is, for example, a tap operation on a flag deletion command displayed by a tap operation on the set flag menu. [S710] The user terminal 30a instructs the user management server 10 to delete a flag. The instruction includes data identifying the target flag. Note that if the upper limit on the number of flags that can be set is one, it is sufficient to delete the currently valid flag, and therefore data identifying the target flag is not essential. [S715] The user management server 10 updates the flag management information (FIG. 4(e)) stored in the storage 21. Specifically, the “invalidation flag” in the flag management information for the flag to be deleted that is associated with Player A (e.g., the target flag, the latest flag) is updated (enabled) to invalidate it. [S720] The user management server 10 notifies the user terminal 30a of the update result. [S725] The user terminal 30a displays the updated results.

[0067] [2-4-4. Spot effect acquisition procedure] Fig. 8 illustrates a procedure for acquiring spot effects by the system of the embodiment. Fig. 8 shows a procedure for player A to operate the user terminal 30a and acquire spot effects of spots located around a position in the virtual space corresponding to the current location. [S805] The user terminal 30a accepts a spot designation operation by Player A. The spot designation operation is, for example, a tap operation on a spot icon located on the map. [S810] The user terminal 30a accepts a spot effect acquisition operation by Player A. The spot effect acquisition operation is, for example, a tap operation on a spot effect acquisition command displayed in response to a spot designation operation. [S815] The user terminal 30a instructs the user management server 10 to acquire spot effects. The instruction includes data capable of identifying the target spot. [S820] The user management server 10 updates the spot effect management information (FIG. 4(g)) stored in the storage 21. Specifically, new spot effect management information is added in association with the player ID of player A. In addition, if there is valid spot effect management information associated with player A, the "invalidation flag" is updated (set to valid) to invalidate it. [S825] The user management server 10 provides display data to the user terminal 30a. The display data is the same as that provided in [S520] (FIG. 5). [S830] The user terminal 30a updates the screen display, changing the icon of the target spot located at the corresponding position on the map displayed on the screen of the user terminal 30a.

[0068] [2-5. Procedures for Quest Execution] [2-5-1. Solo play procedure] 9 illustrates an example of a procedure for performing solo play using the system of the embodiment. In FIG. 9, the procedure is performed after a quest is selected by the user terminal 30a of player A. [S905] The user terminal 30a accepts Player A's selection of solo play. [S910] The user terminal 30a creates a deck in response to Player A's operations. [S915] In response to Player A's operation, the user terminal 30a instructs the user management server 10 to challenge the quest in solo play. [S920] The user management server 10 designates a challenger for the quest. In this example, player A is designated as the challenger who will challenge solo play.

[0069] [S925] The user management server 10 sets quest progress parameters for the challenger. Here, the spot effects to be applied to the challenger are taken into account. Specifically, if spot definition information (Fig. 4(b)) corresponding to the challenger's current location is stored, the spot effect setting information (Fig. 4(d)) is identified by the "effect type ID", and the spot effect to be applied ("value 1", "value 2", "value 3", ...) is identified. In addition, if flag management information (Fig. 4(e)) is stored in association with the challenger, the spot definition information is identified by the "flag position". (Fig. 4(b)), and the spot effect setting information (Fig. 4(d)) is specified by the "effect type ID", and the spot effect to be applied ("value 1", "value 2", "value 3", ...) is specified. Also, when the spot effect management information (Fig. 4(g)) is stored in association with the challenger, the spot definition information (Fig. 4(b)) is specified by the "spot ID", the spot effect setting information (Fig. 4(d)) is specified by the "effect type ID", and the spot effect to be applied ("value 1", "value 2", "value 3", ...) is specified. Then, if there is a target parameter among the default progression parameters, it is updated using at least one of "value 1", "value 2", "value 3", .... As a result, the target progression parameter is increased. In the case of a spot-limited quest, the increase amount or increase rate of the progression parameter is adjusted by further taking into account the positional relationship between the spot and the challenger.

[0070] [S930] The user management server 10 provides the user terminal 30a with parameters for progressing through the quest. [S935] The user terminal 30a progresses the quest using quest progress parameters. [S940] After the quest is completed, the user terminal 30a notifies the user management server 10 that the quest has been completed.

[0071] [S945] The user management server 10 sets reward calculation parameters for the challenger. Here, the spot effect applied to the challenger is taken into account. Specifically, as in [S925], the spot effect to be applied ("value 1", "value 2", "value 3", ...) is specified. Then, if there is a target parameter among the default calculation parameters, it is updated using at least one of "value 1", "value 2", "value 3", .... As a result, the target calculation parameter increases. In the case of a spot-limited quest, the increase amount or increase rate of the calculation parameter is adjusted by further taking into account the positional relationship between the spot and the challenger. Note that the setting process of [S945] may be configured to be executed together with [S925] before the quest begins to progress.

[0072] [S950] The user management server 10 updates the player data stored in the storage 21. For example, the "experience points" and "player rank" of the player information (FIG. 4(a)) corresponding to the challenger are increased in accordance with the reward calculation parameters. [S955] The user management server 10 provides the result display data to the user terminal 30a. [S960] The user terminal 30a displays the results including the acquired rewards. For example, the user terminal 30a may display the pre-update data changing to the post-update data with a predetermined audiovisual effect.

[0073] [2-5-1-1. If the challenger is currently in the vicinity of the spot] FIG. 10 is an explanatory diagram of positional relationships in solo play. 10, a challenger 1020 is currently located in the vicinity of a predetermined position in real space corresponding to the location of the spot 1010 (e.g., within a substantially circular area with a radius of 50 m). In this case, the challenger is granted a spot benefit (e.g., application of a spot effect, eligibility to play a spot-limited quest) derived from the current location.

[0074] (1) Applying spot effects to normal quest play When a normal quest is played solo in the positional relationship shown in FIG. 10, a spot effect may be applied to the challenger. 11 illustrates a procedure for starting a normal quest in the system of the embodiment. After the normal quest is started according to the procedure in FIG. 11, the process proceeds to the solo play execution procedure (FIG. 9). [S1105] The user terminal 30a accepts an instruction to display a quest selection screen from the player A. The instruction to display a quest selection screen is, for example, This is a tap operation on the “Tap” button. [S1110] The user terminal 30a accepts a quest selection operation by player A. The quest selection operation is a series of operations for selecting a quest from a list of quests or a classification of quests classified from a predetermined viewpoint. Note that the list or classification of quests displays only quests that satisfy the play conditions of player A so that they can be selected. The play conditions are, for example, at least one of a time condition, a spatial condition (geographical condition), a skill level condition, etc.

[0075] The user management server 10, in [S925] (FIG. 9), sets the quest progress parameters for the challenger, taking into account at least the spot effects applied to the challenger. Furthermore, the user management server 10 sets reward calculation parameters for the challenger in [S945] (FIG. 9) by taking into account at least the spot effect applied to the challenger.

[0076] (2) Playing spot-limited quests In the location relationship shown in Figure 10, solo play of spot-specific quests is possible. Fig. 12 illustrates a procedure for starting play of a spot-limited quest in the system of the embodiment. After a spot-limited quest is selected according to the procedure in Fig. 12, the process proceeds to the solo play execution procedure (Fig. 9). [S1205] The user terminal 30a accepts a spot designation operation by the player A. The spot designation operation is, for example, a tap operation on an icon of a nearby spot arranged on a map. Note that in the service of the embodiment, only when a spot is arranged within a predetermined range centered on a position in the virtual space corresponding to the current position, the icon of the spot is arranged on the map displayed on the user terminal 30a. [S1210] The user terminal 30a accepts a quest selection operation by Player A. The quest selection operation is, for example, a tap operation on a spot-limited quest execution command displayed in response to a spot designation operation.

[0077] [2-5-1-2. If the challenger has been in the vicinity of the spot in the past] FIG. 13 is an explanatory diagram of positional relationships in solo play. In the example shown in FIG. 13, the challenger was previously located in the vicinity of a predetermined position in real space corresponding to the location of the spot 1310 (e.g., within a substantially circular area with a radius of 50 m). In other words, a challenger flag 1320 is placed around the location of the spot. In this case, the challenger is granted fictitious spot benefits (e.g., application of spot effects, eligibility to play spot-limited quests) derived from the past location.

[0078] (1) Application of fictitious spot effects to normal quest play When a normal quest is played solo in the positional relationship shown in FIG. 13, the fictitious spot effect may be applied to the challenger. After the normal quest is started according to the procedure in FIG. 11, the procedure for executing solo play (FIG. 9) is carried out.

[0079] The user management server 10, in [S925] (FIG. 9), sets the quest progress parameters for the challenger, taking into account at least the spot effect (fictitious spot effect) applied to the challenger. Furthermore, in [S945] (FIG. 9), the user management server 10 sets the reward calculation parameters for the challenger by taking into account at least the spot effect (fictitious spot effect) applied to the challenger.

[0080] (2) Playing spot-limited quests In the location relationship shown in Figure 13, solo play of spot-specific quests is possible. Fig. 14 illustrates a procedure for starting play of a spot-limited quest in the system of the embodiment. After a spot-limited quest is selected according to the procedure in Fig. 14, the process proceeds to the solo play execution procedure (Fig. 9). [S1405] The user terminal 30a accepts a flag designation operation by the player A. The flag designation operation is, for example, a tap operation on a flag menu arranged on the screen. Note that the flag menu becomes active only when a flag is set. [S1410] The user terminal 30a accepts a spot designation operation by Player A. The spot designation operation is, for example, a tap operation on a spot designation command displayed by a flag designation operation. [S1415] The user terminal 30a accepts a quest designation operation by Player A. The quest designation operation is, for example, a tap operation on a spot-limited quest execution command displayed by a spot designation operation. Note that the spot-limited quest execution command is displayed only when a spot-limited quest is prepared in association with the specified spot.

[0081] [2-5-2. Multiplayer execution procedure] Fig. 15 illustrates an example of a procedure for executing a multiplayer game using the system of the embodiment. Fig. 15 shows the procedure after player A selects a quest, player A starts a call for a multiplayer game, and player B applies for the call. [S1505] The user terminal 30a creates a deck in response to Player A's operations. [S1510] The user terminal 30a accepts a challenge instruction operation from Player A. [S1515] In response to Player A's operation, the user terminal 30a instructs the user management server 10 to challenge the quest in multiplay. [S1520] The user management server 10 designates challengers for the quest. Here, players A and B are designated as challengers (host and guest) who will challenge the multiplayer game.

[0082] [S1525] The user management server 10 sets quest progress parameters for the host and the guest, respectively. Here, the spot effects to be applied to at least some of the challengers are taken into account. Specifically, when spot definition information (FIG. 4(b)) corresponding to the current location of a certain challenger is stored, the spot effect setting information (FIG. 4(d)) is identified by the "effect type ID", and the spot effect to be applied ("value 1", "value 2", "value 3", ...) is identified. When flag management information (FIG. 4(e)) is stored in association with a certain challenger, the spot definition information (FIG. 4(b)) is identified by the "flag position", the spot effect setting information (FIG. 4(d)) is identified by the "effect type ID", and the spot effect to be applied ("value 1", "value 2", "value 3", ...) is identified. Also, when spot effect management information (FIG. 4(g)) is stored in association with a certain challenger, the spot definition information (FIG. 4(b)) is specified by the "spot ID", the spot effect setting information (FIG. 4(d)) is specified by the "effect type ID", and the spot effect to be applied ("value 1", "value 2", "value 3", ...) is specified. If there is a target parameter among the default progression parameters, it is updated using at least one of "value 1", "value 2", "value 3", .... As a result, the target progression parameter increases. This process is performed for all challengers. In the case of a spot-limited quest, the increase amount or increase rate of the progression parameter is adjusted by further taking into account the positional relationship between the spot and the host from the past to the present and the positional relationship between the spot and the guest from the past to the present.

[0083] [S1530] The user management server 10 provides quest progress parameters to the user terminal 30a and the user terminal 30b. [S1535a-c] The user terminal 30a and the user terminal 30b each progress a quest. The quest progress parameters are used to progress the quest. The server 10 is connected to each of the user terminals 30a and 30b, and relays the exchange of data including operation information to synchronize the progress of quests.

[0084] [S1540] After the quest is completed, the user management server 10 sets reward calculation parameters for the host and the guest. Here, the spot effect applied to at least some of the challengers is taken into account. Specifically, similar to [S1525], the spot effect to be applied ("value 1", "value 2", "value 3", ...) is specified, and if there is a target parameter among the default calculation parameters, it is updated using at least one of "value 1", "value 2", "value 3", ..., and the process of increasing the target calculation parameter is performed for each of all challengers. In the case of a spot-limited quest, the positional relationship between the spot and the host from the past to the present and the positional relationship between the spot and the guest from the past to the present are further taken into account, respectively, to adjust the increase amount or increase rate of the calculation parameter. Note that the setting process of [S1540] may be configured to be executed together with [S1525] before the quest begins to progress.

[0085] [S1545] The user management server 10 updates the player data stored in the storage 21. For example, the "experience points" and "player ranks" in the player information (FIG. 4(a)) corresponding to the host and guest, respectively, are increased in accordance with the reward calculation parameters. [S1550] The user management server 10 provides result display data to the user terminal 30a and the user terminal 30b. [S1555a, b] The user terminal 30a and the user terminal 30b each display the results including the acquired reward. For example, the pre-update data is shown changing to the post-update data by a predetermined audiovisual effect.

[0086] [2-5-2-1. Procedure for performing short-distance multi-threading] Fig. 16 illustrates a procedure for recruiting short-distance multiplayer using the system of the embodiment. Fig. 17 illustrates a procedure for applying for short-distance multiplayer using the system of the embodiment. Fig. 16 shows the procedure after a quest is selected by player A. Fig. 17 shows the procedure following Fig. 16. [S1605] The user terminal 30a accepts Player A's selection of multiplay. [S1610] The user terminal 30a accepts Player A's selection of short-distance multiplayer. [S1615] The user terminal 30a creates a provisional deck in response to Player A's operations. [S1620] The user terminal 30a accepts an operation by player A to request a recruitment for a close-range multiplayer game. In the service of this embodiment, player A can set a password (a three-digit number string) when recruiting for a multiplayer game. When a password is set, the setting is also accepted. [S1625] The user terminal 30a identifies its current location (where it is currently located). The GPS unit 261 is used to identify the current location. [S1630] The user terminal 30a instructs the user management server 10 to solicit short-distance multiplayer games. The instruction may include a set password and location data indicating the current location of the user terminal 30a. [S1635] The user management server 10 notifies the user terminal 30a that the short-distance multi-party invitation has been accepted. [S1640] The user management server 10 registers new virtual waiting room information (FIG. 4(h)) and virtual waiting management information (FIG. 4(i)) in the storage 21, and creates a virtual waiting room. At this time, the "multiplay category" is close-distance multiplayer, the "participation conditions" are to be located in the vicinity of the location indicated by the location data included in the recruitment instruction, and the "status" is "recruiting." Furthermore, if the recruitment instruction includes a password, the password also constitutes the "participation conditions."

[0087] [S1705] The user terminal 30b accepts a search instruction for short-distance multiplayer from Player B. If Player B specifies a password (a three-digit number string) when searching for recruitment, the user terminal 30b also accepts that specification. [S1710] The user terminal 30b identifies its current location (where it is currently located). The GPS unit 261 is used to identify the current location. [S1715] The user terminal 30b instructs the user management server 10 to search for recruitments that satisfy the participation conditions. The instruction may include a specified password and location data indicating the current location of the user terminal 30b. [S1720] The user management server 10 identifies information related to a recruitment for a short-distance multiplayer game for which the player B satisfies the participation conditions and play conditions, from among the virtual waiting room information stored in the storage 21. The play conditions are conditions set for the quest (for example, the player rank, play position, play time, etc., satisfying predetermined conditions). [S1725] The user management server 10 provides the search results to the user terminal 30b. [S1730] The user terminal 30b selects one of the short-distance multiplayer games in response to an operation by Player B and notifies the user management server 10 of the selection. [S1735] The user management server 10 permits the user terminal 30b to apply for the selected recruitment. [S1740] The user terminal 30b creates a provisional deck in response to Player B's operations. [S1745] In response to Player B's operation to instruct the user management server 10 to apply for the selected recruitment. [S1750] The user management server 10 adds the player ID of player B to the virtual standby management information (FIG. 4(i)) stored in the storage 21, and accepts an application from player B in response to the selected recruitment. [S1755] The user management server 10 notifies the user terminal 30a that the application has been accepted.

[0088] [2-5-2-1-1. If the host is currently in the vicinity of the spot] FIG. 18 is an explanatory diagram of the positional relationship in short-distance multi-camera shooting. 18, the host 1820 is currently located in the vicinity of a predetermined position in real space (e.g., within a substantially circular area with a radius of 50 m) corresponding to the location of the spot 1810. In this case, the host is granted spot benefits (e.g., application of spot effects, eligibility to play spot-limited quests) derived from the current location.

[0089] Additionally, guests 1830a and 1830b are currently located near the current location of host 1820. Guest 1830a is currently located in the vicinity of a predetermined location. Meanwhile, guest 1830b is not currently located in the vicinity of the predetermined location. In this case, guest 1830a is granted a spot benefit derived from its current location (a benefit equivalent to the spot benefit granted to host 1820). Meanwhile, guest 1830b is granted a pseudo spot benefit (a benefit inferior to the spot benefit) equivalent to the spot benefit granted to host 1820.

[0090] FIG. 19 is an explanatory diagram of the positional relationship in short-distance multi-camera shooting. 19, the host 1920 is currently located in the vicinity of a predetermined position in real space (e.g., within a substantially circular area with a radius of 50 m) corresponding to the location of the spot 1910. In this case, the host is granted spot benefits (e.g., application of spot effects, eligibility to play spot-limited quests) derived from the current location.

[0091] Also, the guest was previously located near the current location of the host 1920. That is, guest flags 1930a and 1930b are placed near the positions in the virtual space corresponding to the current location of the host 1920. A guest with flag 1930b has been in the vicinity of the specified location in the past but is not currently there. On the other hand, a guest with flag 1930b has never been in the vicinity of the specified location in the past or at the present. In this case, the former is granted a fictitious privilege (an inferior privilege to a spot privilege) derived from the guest's past location. On the other hand, the latter is granted a pseudo privilege (an inferior privilege to a spot privilege) equivalent to the spot privilege granted to the host 1920. It is preferable that the fictitious privilege granted to the former is a superior privilege to the pseudo privilege granted to the latter.

[0092] (1) Application of fictitious spot effects to normal quest play In the case of a close-range multiplayer normal quest in the positional relationship of Figures 18 and 19, the host may be applied with a spot effect. Also, the guest may be applied with any of the spot effect, fictitious spot effect, and pseudo spot effect. After a normal quest is started according to the procedure in FIG. 11, the process goes through recruitment and application for close-range multiplayer according to the procedures in FIGS. 16 and 17, and then to the procedure for executing multiplayer (FIG. 15).

[0093] The user management server 10, in [S1525] (FIG. 15), sets the quest progress parameters for the challengers, taking into account at least the spot effects applied to at least some of the challengers. Furthermore, the user management server 10 sets reward calculation parameters for the host and the guest in [S1540] (FIG. 15) by taking into account at least the spot effect applied to at least some of the challengers.

[0094] (2) Playing spot-limited quests Short-distance multiplayer for spot-limited quests is possible in the positional relationship of Figures 18 and 19. After a spot-limited quest is selected according to the procedure of Figure 12, the short-distance multiplayer is solicited and applied for according to the procedures of Figures 16 and 17, and the process proceeds to the multiplayer execution procedure (Figure 15).

[0095] [2-5-2-1-2. If the host has been in the vicinity of the spot in the past] FIG. 20 is an explanatory diagram of the positional relationship in short-distance multi-camera shooting. In the example shown in FIG. 20, the host 2030 was previously located in the vicinity of a predetermined position in real space corresponding to the location of the spot 2010 (for example, within an approximately circular area with a radius of 50 m). That is, a flag 2020 of the host 2030 is installed in the vicinity of the location of the spot. In this case, the host 2030 is granted a fictitious spot benefit (for example, application of a spot effect, eligibility to play a spot-limited quest) derived from the past location.

[0096] Also, the guest 2040 is currently located near the current location of the host 2030. The guest 2040 is not currently located in the vicinity of a predetermined location. In this case, the guest 2040 is granted a pseudo spot award (an award that is inferior to the fictitious spot award) that is equivalent to the fictitious spot award granted to the host 2030.

[0097] FIG. 21 is an explanatory diagram of the positional relationship in short-distance multi-camera shooting. In the example shown in FIG. 21, the host was previously located in the vicinity of a predetermined position in real space corresponding to the location of the spot 2110 (for example, within an approximately circular area with a radius of 50 m). In other words, the host's flag 2120 is placed in the vicinity of the location of the spot. In this case, the host is granted a fictitious spot benefit (for example, application of spot effects, eligibility to play spot-limited quests) derived from the host's past location.

[0098] Also, guests 2130a and 2130b are currently located near the host's past location. The guest 2130a is currently located in the vicinity of a predetermined location. On the other hand, the guest 2130b is not currently located in the vicinity of the predetermined location. In this case, the former is not located in the current location. The guest 2130b is granted a spot award derived from the host (a superior award to the fictitious spot award granted to the host). On the other hand, the guest 2130b is granted a pseudo spot award (an inferior award to the fictitious spot award) equivalent to the fictitious spot award granted to the host.

[0099] FIG. 22 is an explanatory diagram of the positional relationship in short-distance multi-camera shooting. In the example shown in FIG. 22, the host was previously located in the vicinity of a predetermined position in real space corresponding to the location of the spot 2210 (for example, within an approximately circular area with a radius of 50 m). In other words, the host's flag 2220 is installed in the vicinity of the location of the spot. In this case, the host is granted a fictitious spot benefit (for example, application of a spot effect, eligibility to play a spot-limited quest) derived from the host's past location.

[0100] Also, the guests were each located near the past location of the host. That is, the guest flags 2230a and 2230b are each installed near the installation location of the host's flag 2220. The guest who has set the flag 2230a was previously located near the predetermined location, but is not currently located there. On the other hand, the guest who has set the flag 2230b has not been located near the predetermined location from the past to the present. In this case, the former is granted a fictitious spot privilege (a privilege equivalent to the fictitious spot privilege granted to the host) derived from the past location. On the other hand, the latter is granted a pseudo spot privilege (a privilege inferior to the fictitious spot privilege) equivalent to the fictitious spot privilege granted to the host.

[0101] (1) Applying spot effects to regular quests When a short-distance multiplayer normal quest is performed in the positional relationship of Figures 20 to 22, a fictitious spot effect may be applied to the host. Also, any one of a spot effect, a fictitious spot effect, and a pseudo spot effect may be applied to the guest. After a normal quest is started according to the procedure in FIG. 11, the process goes through recruitment and application for close-range multiplayer according to the procedures in FIGS. 16 and 17, and then to the procedure for executing multiplayer (FIG. 15).

[0102] (2) Playing spot-limited quests 20 to 22, short-distance multiplayer for spot-limited quests is possible. After a spot-limited quest is selected according to the procedure in Fig. 14, the short-distance multiplayer is solicited and applied for according to the procedures in Fig. 16 and Fig. 17, and then the procedure for executing multiplayer (Fig. 15) begins.

[0103] [2-5-2-2. SNS Multi Execution Procedure] Fig. 23 illustrates an example of a procedure for recruiting SNS multiplayer using the system of the embodiment. Fig. 24 illustrates an example of a procedure for applying to SNS multiplayer using the system of the embodiment. Fig. 23 illustrates the procedure after a quest is selected. Fig. 24 illustrates the procedure following Fig. 23. [S2305] The user terminal 30a accepts Player A's selection of multiplay. [S2310] The user terminal 30a accepts Player A's selection of SNS multi-play. [S2315] The user terminal 30a creates a provisional deck in response to Player A's operations. [S2320] The user terminal 30a instructs the user management server 10 to solicit users for the SNS multiplayer. [S2325] The user management server 10 notifies the user terminal 30a of the acceptance of the SNS multi-user recruitment. The notification may include a URL to which a command to start the SNS program and data capable of identifying the recruitment are added. [S2330] The user terminal 30a sends a message including the above URL to the user terminal 30b directly or indirectly outside the system of the embodiment. [S2335] The user terminal 30a notifies the user management server 10 of the address specifying the above URL. By accessing the above, we will instruct the start of recruitment for the above SNS multi. [S2340] The user management server 10 notifies the user terminal 30a that recruitment for the SNS multi-user account has begun. [S2345] The user management server 10 registers new virtual waiting room information (FIG. 4(h)) and virtual waiting management information (FIG. 4(i)) in the storage 21, and creates a virtual waiting room. At this time, the "multiplay category" is SNS multiplayer, the "participation conditions" are application by accessing the above URL, and the "status" is "open."

[0104] [S2405] The user terminal 30b instructs the user management server 10 to search for virtual waiting rooms that satisfy the participation conditions by accessing the specified URL. [S2410] The user management server 10 identifies information about a recruitment for SNS multiplayer for which player B satisfies the participation conditions and play conditions from among the virtual waiting room information stored in the storage 21. The play conditions are conditions set for the quest (for example, player rank, play position, play time, etc., satisfying predetermined conditions). Here, the recruitment specified by the above URL is identified. [S2415] The user management server 10 provides the search results to the user terminal 30b. [S2420] The user terminal 30b selects the specified SNS multi-player invitation in response to Player B's operation and notifies the user management server 10 of the invitation. [S2425] The user management server 10 permits the user terminal 30b to apply for the selected recruitment. [S2430] The user terminal 30b creates a provisional deck in response to Player B's operations. [S2435] In response to Player B's operation to instruct the user management server 10 to apply for the selected recruitment. [S2440] The user management server 10 adds the player ID of player B to the virtual standby management information (FIG. 4(i)) stored in the storage 21, and accepts an application from player B for the selected SNS multi. [S2445] The user management server 10 notifies the user terminal 30a that the application has been accepted.

[0105] [2-5-2-2-1. If the host is currently in the vicinity of the spot] FIG. 25 is an explanatory diagram of positional relationships in the SNS multi. 25, the host 2520 is currently located in the vicinity of a predetermined position in real space (e.g., within a substantially circular area with a radius of 50 m) corresponding to the arrangement position of the spot 2510. In this case, the host is granted a spot benefit (e.g., application of a spot effect, eligibility to play a spot-limited quest) derived from the current location.

[0106] On the other hand, the guest 2530 is not currently located near the current location of the host 2520. Also, the guest 2530 is not currently located in the vicinity of a predetermined location. In this case, the guest 2530 is granted a pseudo spot benefit (a benefit that is inferior to the spot benefit) equivalent to the spot benefit granted to the host 2520.

[0107] (1) Applying spot effects to regular quests When a normal quest SNS multiplayer is performed in the positional relationship of Figure 25, a spot effect may be applied to the host, and a pseudo spot effect may be applied to the guest. After a normal quest is started according to the procedure in FIG. 11, the process goes through the recruitment and application for SNS multiplayer according to the procedures in FIGS. 23 and 24, and then the process moves to the multiplayer execution procedure (FIG. 15).

[0108] The user management server 10, in [S1525] (FIG. 15), sets the quest progress parameters for the challengers, taking into account at least the spot effects applied to at least some of the challengers. In addition, the user management server 10 performs the host-oriented and Reward calculation parameters for guests are set taking into account at least a spot effect applied to at least some of the challengers.

[0109] (2) Playing spot-limited quests SNS multiplayer for spot-limited quests is possible in the positional relationship of Figure 25. After a spot-limited quest is selected according to the procedure of Figure 12, the process goes through the recruitment and application for SNS multiplayer according to the procedures of Figures 23 and 24, and then the multiplayer execution procedure (Figure 15) begins.

[0110] [2-5-2-2-2. If the host has been in the vicinity of the spot in the past] FIG. 26 is an explanatory diagram of positional relationships in the SNS multi. In the example shown in FIG. 26, the host was previously located in the vicinity of a predetermined position in real space corresponding to the location of the spot 2610 (for example, within a substantially circular area with a radius of 50 m). That is, the host's flag 2620 is placed in the vicinity of the location of the spot. In this case, the host is granted a fictitious spot benefit (for example, application of spot effects, eligibility to play spot-limited quests) derived from the host's past location.

[0111] On the other hand, the guest 2630 has never been near the past location of the host, from the past to the present. Also, the guest 2630 has never been near a specific location, from the past to the present. In this case, the guest 2630 is granted a pseudo spot award (an award inferior to the fictitious spot award) equivalent to the fictitious spot award granted to the host.

[0112] (1) Applying spot effects to regular quests When a normal quest SNS multiplayer is performed in the positional relationship of Figure 26, a fictitious spot effect may be applied to the host, and a pseudo spot effect may be applied to the guest. After a normal quest is started according to the procedure in FIG. 11, the process goes through the recruitment and application for SNS multiplayer according to the procedures in FIGS. 23 and 24, and then the process moves to the multiplayer execution procedure (FIG. 15).

[0113] The user management server 10, in [S1525] (FIG. 15), sets the quest progress parameters for the challengers, taking into account at least the spot effects applied to at least some of the challengers. Furthermore, the user management server 10 sets reward calculation parameters for the host and the guest in [S1540] (FIG. 15) by taking into account at least the spot effect applied to at least some of the challengers.

[0114] (2) Playing spot-limited quests SNS multiplayer for spot-limited quests is possible in the positional relationship of Figure 26. After a spot-limited quest is selected according to the procedure of Figure 14, the process goes through the recruitment and application for SNS multiplayer according to the procedures of Figures 23 and 24, and then the multiplayer execution procedure (Figure 15) begins. [Explanation of symbols]

[0115] 10 User management server (an example of a game information processing device) 20 Data Management Server 21 Storage 30 User terminals 40 Communication Network 310 Registration Department 320 Reception 330 Search Department 340 Provision Department 350 Specified section 351 1st designated part 352 Second designated part 360 Settings 370 Storage section

Claims

1. a registration means for storing the location of a player as a location record in a storage means, with or without the request of the player; a first designation means for designating a first player having a location record indicating that the first player has previously satisfied a play position condition as a challenger who will challenge a target game that can be played alone only when the play position condition is satisfied; A game information processing device comprising:

2. the first designation means designates the first player who does not currently satisfy the play position condition; The game information processing device according to claim 1 .

3. the first designation means designates the first player as a challenger who will host a cooperative play of the target game; The game device further includes a second designation means for designating a second player who has applied to the recruitment of the first player as a challenger who will participate in the cooperative play of the target game hosted by the first player. The game information processing device according to claim 2.

4. the second designation means designates the second player who does not currently satisfy the play position condition; The game information processing device according to claim 3.

5. the second designation means designates the second player currently located in the vicinity of a current location of the first player; The game information processing device according to claim 4.

6. the second designation means designates the second player currently located in the vicinity of a past location of the first player; The game information processing device according to claim 4.

7. the second designation means designates the second player whose location record indicates that the second player was previously located near a previous location of the first player; The game information processing device according to claim 4.

8. The play position condition is to be located in the vicinity of a predetermined position, a setting means for setting a participation parameter used when the second player participates in a cooperative play of the target game in accordance with a current positional relationship between the predetermined position and the second player; 8. The game information processing device according to claim 4.

9. the setting means sets the participation parameter so that the second player who does not satisfy the play position condition is at a relatively disadvantage compared to a player who satisfies the play position condition. The game information processing device according to claim 8.

10. the setting means sets the participation parameter by further taking into consideration a current positional relationship between the first player and the predetermined position.

10. The game information processing device according to claim 8 or 9.

11. the setting means sets the participation parameter such that the second player is at a relatively disadvantage when the first player does not currently satisfy the play position condition compared to when the first player currently satisfies the play position condition. The game information processing device according to claim 10.

12. a registration step of storing the location of a player as a location record in a storage means, with or without the request of the player; a first designation step of designating a first player having a location record indicating that the first player has previously satisfied a play position condition as a challenger who will challenge a target game that can be played alone only when the play position condition is satisfied; A method for controlling an information processing device.

13. a registration function for storing the location of a player as a location record in a storage means, with or without the request of the player; a first designation function for designating a first player having a location record indicating that the first player has previously satisfied a play position condition as a challenger who will challenge a target game that can be played alone only when the play position condition is satisfied; A control program that causes the computer of an information processing device to realize the above.

Images