JP7348566B2 - Information processing device and program - Google Patents

Description

The present invention relates to an information processing device and a program.

An electronic game is known that introduces a mechanism in which a plurality of mobile terminals jointly process an event specified according to the position of the mobile terminal (for example, see Patent Document 1).
Specifically, monsters corresponding to the geographical range are displayed on the screens of multiple mobile terminals existing within a specific geographical range, and mobile terminals located nearby can communicate with each other using short-range wireless communication to identify the monsters. By synchronizing the parameters that change the display, the monster is presented as being attacked by multiple players.

Japanese Patent Application Publication No. 2013-220246

In the game described in Patent Document 1, the mobile terminals of a plurality of players who attack a monster must each exist within a geographical range corresponding to the monster. Therefore, many players have difficulty enjoying events related to the monster due to geographical restrictions.

The problem to be solved by the present invention is to relax geographical restrictions set on a target game under predetermined conditions.

[A] In order to solve the above problems, the "game information processing device" which is one aspect of the present invention includes a registration means for storing the location of a player as a location record in a storage means with or without a request from the player. , a first specifying means for specifying the first player whose location record indicates that the play position condition has been satisfied in the past as a challenger who challenges the target game that can be played alone only when the play position condition is satisfied; and.
[B] In order to solve the above problem, a "control method" for an information processing apparatus, which is one aspect of the present invention, includes a registration method in which a player's location is stored in a storage means as a location record with or without a request from the player. and a first player who has the location record indicating that he or she has satisfied the play position condition in the past as a challenger who challenges the target game that can be played alone only when the play position condition is satisfied. A designated process.
[C] In order to solve the above problem, the "control program" which is one aspect of the present invention has a registration function that stores the player's location as a location record in a storage means, with or without a request from the player, and a player's location record. a first designation function that designates a first player whose location record indicates that he or she has satisfied the play position condition in the past as a challenger who challenges the target game that can be played alone only when the position condition is satisfied; is realized by the computer of the information processing device.
[D] In order to solve the above problem, a control program recorded on a "computer-readable recording medium", which is one aspect of the present invention, records the location of a player and records the location of the player, with or without a request from the player. A first device having a registration function to be stored in a storage means, and a location record indicating that the player has satisfied the play position condition in the past as a challenger who challenges the target game that can be played alone only when the play position condition is satisfied. A first designation function for designating a player is realized in a computer of an information processing device.

The following technical limitations may be added to the "game information processing device" in [A] above. Further, similar technical limitations may be added to the "control method" in [B] above, the "control program" in [C] above, and the control program recorded by 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 designates the first player as a challenger who participates in the cooperative play of the target game hosted by the first player. The game player further includes second designating means for designating a second player who has applied for player recruitment.
- 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 near the current location of the first player.
- The second designation means designates the second player who is currently located near the past location of the first player.
- The second designation means designates the second player whose location record indicates that the player was in the vicinity of the past location of the first player.
- The play position condition is to be located in the vicinity of a predetermined position, and the participation parameter used when the second player participates in cooperative play of the target game is set to the predetermined position and the second player's current position. The apparatus further includes a setting means for setting according to the positional relationship.
- The setting means sets the participation parameter so that the second player who does not satisfy the play position condition is at a relative disadvantage compared to the player who satisfies the play position condition.
- The setting means sets the participation parameter by further taking into consideration the current positional relationship between the first player and the predetermined position.
- The setting means sets the second player at a relative 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 participation parameters are set so that

In this specification, the following terms are used.
・“Game” refers to an electronic game provided at least in part through an online game service. In a broad sense, it refers to the game service itself, and in a narrow sense, it refers to the individual stages that make up the game service.
- “Player” refers to a user of a game service.
- "Play" refers to a player playing a specific game.
・“Solo play” refers to play by a single player.
- "Cooperative play" refers to synchronized play by multiple players in a cooperative relationship. In cooperative play, a cooperative relationship is formed between a player (host) who hosts cooperative play for a specific game and recruits friends, and a player (guest) who applies for the recruitment and participates in cooperative play for the specific game. progress is synchronized between players.
- "Challenger" refers to a player who challenges to play a specific game.
- "Nearby" refers to a range of a predetermined first distance from a certain player's location, for example. Moreover, the "periphery" refers to a range of a predetermined second distance from a predetermined position, for example. In these exemplary cases, the magnitude relationship between the first distance and the second distance can be set arbitrarily.
・"Predetermined position" is, for example, a position in the real space that corresponds to the spot position when a virtual space is formed in association with the real space and a spot position is defined in the virtual space. refers to
- "Playing position conditions" refers to conditions regarding the location when playing among the conditions required of a challenger who challenges to play a specific game. For example, it means that the challenger's location is around a predetermined location. Note that there may be a difference between the conditions required of a challenger in solo play and the conditions required of each challenger in cooperative play. Further, there may be a difference between the conditions required of the challenger who hosts the cooperative play and the conditions required of each challenger participating in the cooperative play.
・“Event” refers to the factors that cause a new location record to be added or an existing location record to be deleted. Additional factors include player instructions. Factors for deletion include player instructions, execution of periodic processing, expiration of the validity period, and passage of the validity period.
- "Parameter" refers to at least some setting data used for playing 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 calculation after the game ends. Note that even if the object of play is the same, there may be a difference between the parameters for a challenger in solo play and the parameters for each challenger in cooperative play. Further, there may be a difference between the host parameters for the challenger who hosts the 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 participation parameters among the challengers.
- "Applicable conditions" refers to conditions related to location among the conditions for granting benefits applicable to playing a predetermined game. For example, it means that the player's location is around a predetermined location.
・“Location benefit” refers to a geographical benefit granted to players who currently meet the applicable conditions. The location benefit is a concept that includes in-game benefits that mainly affect the progress of the game and out-game benefits that mainly affect reward calculation after the game ends.
- "False location benefit" refers to a geographical benefit granted to a player who does not currently meet the applicable conditions but did in the past. The fictitious location benefit is a concept that includes an in-game benefit that primarily affects the progress of the game, and an out-game benefit that primarily affects reward calculation after the game ends. The content of the benefit can be set to be inferior to the location benefit.
- "Pseudo location benefit" refers to a geographical benefit that may be granted to players who have not satisfied the applicable conditions from the past to the present when they play cooperatively with other players. For example, when a location benefit or a pseudo location benefit is applied to cooperative play by a certain player, a pseudo location benefit is applied to the cooperative play by another player. The pseudo-location benefit is a concept that includes an in-game benefit that mainly affects the progress of the game, and an out-game benefit that mainly affects reward calculation after the game ends. The content of the benefit can be set to be inferior to the location benefit and the fictitious location benefit.

The present invention enables play of a target game in which solo play is possible only when the play position condition is met, to a first player whose location record satisfies the play position condition in the past, and who currently satisfies the play position condition. Allowed regardless of whether or not
In this respect, according to the present invention, geographical restrictions set on the target game are relaxed.

The network configuration is illustrated. (Example) The hardware functional configuration of the server device is illustrated. (Example) The hardware functional configuration of a user device is illustrated. (Example) The software functional configuration is illustrated. (Example) An example of a database configuration is given below. (Example) The screen display update procedure will be illustrated. (Example) An example of the flag setting procedure is given below. (Example) The flag deletion procedure is illustrated. (Example) The spot effect acquisition procedure will be illustrated. (Example) An example of a solo play execution procedure is given below. (Example) FIG. 3 is an explanatory diagram of positional relationships in solo play. (Example) An example of the procedure for starting play of a normal quest is given below. (Example) The procedure for starting play of a spot-limited quest is illustrated. (Example) FIG. 3 is an explanatory diagram of positional relationships in solo play. (Example) The procedure for starting play of a spot-limited quest is illustrated. (Example) An example of the multiplayer execution procedure is given below. (Example) An example of the short-distance multi-recruitment procedure is given below. (Example) An example of the short-distance multi application procedure is given below. (Example) FIG. 2 is an explanatory diagram of positional relationships in short-distance multiplayer. (Example) FIG. 2 is an explanatory diagram of positional relationships in short-distance multiplayer. (Example) FIG. 2 is an explanatory diagram of positional relationships in short-distance multiplayer. (Example) FIG. 2 is an explanatory diagram of positional relationships in short-distance multiplayer. (Example) FIG. 2 is an explanatory diagram of positional relationships in short-distance multiplayer. (Example) An example of the SNS multi-recruitment procedure is given below. (Example) The following is an example of the application procedure for SNS Multi. (Example) It is an explanatory diagram of positional relationship in SNS multi. (Example) It is an explanatory diagram of positional relationship in SNS multi. (Example)

[1. Embodiment]
[1-1. Embodiment 1]
[1-1-1. overview]
Embodiment 1 relates to an electronic game that uses a terminal device or a player's geographical location measured using GPS.
The game information processing device according to the first embodiment is configured to relax geographical restrictions set on the target game under predetermined conditions.

[1-1-2. Game information processing device]
The game information processing device (e.g., user management server 10) according to the first embodiment allows cooperative play (e.g., a first designation unit (e.g., first designation section 351) for designating a first player who satisfies play position conditions as a challenger (e.g., host) hosting a multiplayer game; and a cooperative play of a target game hosted by the first player. A second designation means (for example, a second designation part) for designating a second player (for example, a player who does not currently satisfy the play position conditions) who has applied for recruitment of the first player as a challenger (for example, a guest) to participate in the game. 352).

[1-2. Embodiment 2]
[1-2-1. overview]
Embodiment 2 relates to an electronic game that uses a terminal device or a player's geographical location measured using GPS.
The game information processing device according to the second embodiment is configured to relax geographical restrictions set on the target game under predetermined conditions.

[1-2-2. Game information processing device]
The game information processing device (for example, the user management server 10) according to the second embodiment stores the player's location as a location record (for example, as a flag) in a storage means (for example, the storage unit 370) with or without a request from the player. A registration means (e.g., the registration unit 310) to be stored in the player, and a challenger (e.g., a solo player) who challenges a target game (e.g., a quest) that can be played alone (e.g., a solo play) only if the play position condition is satisfied. , a multiplayer host) for specifying a first player (e.g., a player who does not currently satisfy the play position condition) for which there is a location record indicating that the play position condition was satisfied in the past. A first designation section 351) is provided.

Further, the first designating means may designate the first player as a challenger who will host a cooperative play of the target game, and the first designation means will designate the first player as a challenger who will participate in the cooperative play of the target game hosted by the first player. It may be configured to further include a second designation means (for example, second designation unit 352) for designating a second player who has applied for player recruitment (for example, a player who does not currently satisfy the above play position conditions). .

[1-3. Embodiment 3]
[1-3-1. overview]
Embodiment 3 relates to an electronic game that uses a terminal device or a player's geographical location measured using GPS.
The game information processing device according to the third embodiment is configured to relax the criteria for imparting geographic effects under predetermined conditions.

[1-3-2. Game information processing device]
The game information processing device (e.g., user management server 10) according to the third embodiment allows a plurality of players, including at least a first player and a second player who does not satisfy the conditions for application of location benefits (e.g., spot benefits), to play a predetermined game. a designation unit (for example, a designation unit 350) for respectively designating a challenger (for example, a host or a guest of a multiplayer) in a cooperative play (for example, a multiplayer) (for example, a quest); A setting means (for example, a setting unit 360) is provided for applying a pseudo-location benefit inferior to the location benefit to the cooperative play by the second player when the location benefit is applied.

If the applicable condition is to be present in the vicinity of a predetermined location, the setting means may provide an inferior location benefit to the first player who does not currently satisfy the applicable condition but has satisfied it in the past. In addition, a superior fake location benefit may be applied to the above pseudo location benefit.
At this time, the setting means may set the pseudo-location benefit to be applied to the cooperative play by the second player depending on the content of the benefit to be applied to the cooperative play by the first player.

[2. Example]
[2-1. overview]
The present embodiment relates to a game service (service of the embodiment) that is provided at least in part online.
In the service of the example, the player sequentially operates the four monsters that make up the deck using predetermined actions, and sequentially challenges multiple stages (game in a narrow sense) prepared within the game. Electronic games (games in a broad sense) are provided. Hereinafter, this stage will be referred to as a "quest."

There are two ways to play a quest: solo play (solo play) where one player takes on the challenge alone, and multiplay (cooperative play) where 2 to 4 players work together to take on the challenge. .
In a multiplayer, a cooperative relationship is formed between a host who hosts the multiplayer and recruits friends and a guest who applies for the recruitment and participates in the multiplayer, and the progress of the play is synchronized between the players.

There are two types of guest recruitment by the host: recruitment that primarily targets unspecified players located nearby, and recruitment that primarily targets specific players located at an arbitrary location.
Hereinafter, multiplayer that takes the former recruitment form will be referred to as short-distance multiplayer. Also, multiplayer that takes the latter form of recruitment is called SNS multiplayer.

[2-2. Features]
[2-2-1. Spot placement and spot benefits]
A virtual space is formed that is geographically associated with the real space, and the display of the virtual space (map display) 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. Then, when a player is located around a position (predetermined position) in real space that corresponds to a certain spot placement position, spot benefits (spot effects, spot-limited quest play qualifications) will be granted to the player.

[2-2-2. Flag installation and spot benefits]
The player can register his/her own location in real space as a record (location record). A flag is placed at a position in the virtual space that corresponds to the recorded location.
If there is a location record indicating that the player was located around a position in real space (predetermined position) corresponding to a certain spot placement position, the spot benefit set in association with the spot placement position is An inferior benefit (a fictitious spot benefit) is granted to the player.
Note that the upper limit of the number of flags installed can be set arbitrarily. In the service of the embodiment, the upper limit number is set to 1. A flag that has already been set is invalidated by erasing it by the player, setting a new flag, or the like. It is also cleared periodically (eg, by daily batch processing).

[2-2-3. Types of spot benefits]
Examples of spot benefits include the following benefits.
(a) Obtain virtual currency item fragments (objects that can be exchanged for specified virtual currency items when multiple points are collected) (b) Obtain spot-limited monsters (c) Obtain qualifications to play spot-limited quests ( d) The parameters that mainly affect the progress of the quest (quest progress parameters, progress parameters) change in an advantageous direction (e) The parameters that mainly affect the calculation of clear rewards (reward calculation parameters, calculation parameters) change change in an advantageous direction

The above (d) is, for example, the following benefit. These benefits can be applied to the play by the player when the player plays a predetermined quest after being given to the player.
(d-1) The stage of the attached emblem increases (d-2) The hit points (HP), attack power, and speed of monsters with specified attributes increase (d-3) Luck skills (for example, shield, friendship) Combo critical, guide) activation rate increases.

The above (e) is, for example, the following benefit. These benefits can be applied to the play by the player when the player plays a predetermined quest after being given to the player.
(e-1) If you clear a quest, a part of your stamina will be returned (e-2) Experience points will increase (e-3) Earned points will increase (e-4) Luck will increase (i.e. (Increases chance of getting luck bonus)
(e-5) Increased probability of adding treasure chests

[2-2-4. Relaxation of play position conditions through multiplayer]
There are spot-limited quests that allow solo play only when the player is located around a position (predetermined position) corresponding to a specific spot (that is, when the play position conditions are met).
In the service of the embodiment, a player who has a record showing that the play position condition was satisfied in the past is allowed to play the spot-limited quest. Therefore, players who do not currently meet the play position conditions may play the spot-limited quest alone or in collaboration.

Furthermore, if you are a guest participating in a multiplayer hosted by a host that satisfies the play position conditions, you are allowed to challenge the multiplayer of the spot-limited quest regardless of whether or not the play position conditions are met. At this time, participation parameters (progress parameters, calculation parameters) for the guest are adjusted according to the past to present positional relationship between the guest and the spot.
Furthermore, if you are a guest participating in a cooperative play hosted by a host that has a record of meeting the play position conditions, you can play the spot-limited quest multiplayer regardless of whether or not the play position conditions are met. Allow. At this time, participation parameters (progress parameters, calculation parameters) for the guest are adjusted according to the past to present positional relationship between the host, the guest, and the spot.

[2-2-5. Relaxation of benefits application conditions for multiplayer]
In the service of the example, when a spot effect (location benefit or fictitious location benefit) is applied to a certain player who challenges a multiplayer, other players who challenge the multiplayer are given a spot effect that is inferior to these spot effects. (Pseudo location benefit) will be applied. 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 spot effect is applied to a host that satisfies the application conditions of a certain spot effect, a spot effect inferior to the spot effect is applied to all guests who do not satisfy the application condition. Further, when a spot effect is applied to a guest who satisfies the application conditions of a certain spot effect, a spot effect inferior to the spot effect is applied to the host and other guests who do not satisfy the application condition.

[2-2-6. summary]
As described above, in the service of the example, a large number of spots are placed in a virtual space that is geographically mapped to the real space, and the spots are located around the position (predetermined position) in the real space that corresponds to the spot placement position. Prepare benefits (for example, spot effects, eligibility to play spot-limited quests) that are granted based on certain conditions.
On the other hand, the conditions under which the benefit is applied (eg, temporal conditions, spatial conditions) are relaxed in predetermined 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 that one player.
Such a mechanism improves the interest of the service of the embodiment and encourages the challenge of quests through multiplayer.

[2-3. Example system configuration]
[2-3-1. Network configuration]
[2-3-1-1. overview]
FIG. 1 illustrates the network configuration of the system of the embodiment. An example system provides an example service 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 users. includes a plurality of user terminals 30 (30-1, 30-2, . . . 30-n) (n: natural number) used by each of the users.

The user management server 10 and the user terminal 30 can exchange data through the 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 is at least one of existing networks such as the Internet, a mobile phone network, a wireless WAN (Wireless Wide Area Network), a wireless LAN (Wireless Local Area Network), and Ethernet (registered trademark). may contain.

[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 acquire necessary data from the storage 21 and provides it to the request source (response). Further, the user management server 10 causes the data management server 20 to register necessary data in the storage 21 in response to a request.
Note that a server system may be configured by linking a plurality of server devices, and the functions of the user management server 10 may be shared or the load placed on the user management server 10 may be distributed.

[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 together with the storage 21 constitutes a DBMS (DataBase Management System).
In response to a request, the data management server 20 acquires necessary data from the storage 21 and provides it to the request source (response). The data management server 20 also registers necessary data in the storage 21 in response to a request. The storage 21 is a storage device that stores data related to the services of the embodiment.
Note that a server system may be configured by linking a plurality of server devices, and the functions of the data management server 20 may be shared or the load placed on the data management server 20 may be distributed. Further, a plurality of storage devices may be prepared and each type of data stored in the storage 21 may be stored separately, or the data stored in the storage 21 may be distributed among the plurality of storage devices.

[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 is a general-purpose mobile device on which a program can be installed (e.g., a mobile phone, a smartphone, a tablet terminal, a personal computer, a wearable device, etc.). A general-purpose processing device (for example, a PC (personal computer), etc.) can be used.

[2-3-2. Hardware functional configuration]
[2-3-2-1. Hardware functional configuration of server device]
FIG. 2-1 illustrates the hardware functional configuration of the server device.
The server device illustrated in FIG. 2-1 includes a control processing device 211 including an MPU (Micro-Processing Unit) and a ROM (Read Only Memory), a main storage device 212 including a RAM (Random Access Memory), and an HDD ( The computer has an auxiliary storage device 213 including a hard disk 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 interface card.

The main storage device 212, the auxiliary storage 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 storage device 213 onto the main storage device 212, and (2) controls at least the input device 214, the auxiliary storage device 213, and the communication control device 216 according to instructions from the program. Acquire data from either, (3) calculate and process the acquired data according to the procedure specified in the program, and (4) communicate the calculated and processed data with the auxiliary storage device 213 and the output device 215. and at least one of the control device 216.

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

RAM 231, ROM 232, EEPROM 233, touch panel display 241, speaker 242, NIC 251, wireless LAN chip 252, and GPS unit 261 are connected to MPU 221 via a bus line.
The MPU 221 (1) reads a program stored in the ROM 232 or EEPROM 233 onto the RAM 231, and (2) reads data from at least one of the touch panel display 241, the EEPROM 233, the NIC 251, the wireless LAN chip 252, and the GPS unit 261 according to the instructions of the program. (3) calculate and process the acquired data according to the procedure specified in the program, and (4) transfer the calculated and processed data to the EEPROM 233, touch panel display 241, speaker 242, NIC 251, and wireless LAN chip. 252.

[2-3-3. Software functional configuration]
FIG. 3 illustrates the software functional configuration of the system of the embodiment.
As illustrated in FIG. 3, the user management server 10 includes a registration section 310, a reception section 320, a search section 330, a provision section 340, a designation section 350, and a setting section 360. The designation section 350 includes a first designation section 351 and a second designation section 352. The data management server 20 also includes a storage unit 370.

The software functions of the user management server 10 and the data management server 20 are realized by installing an OS (Operating System) for a server device and a program running on the OS into the server device.
Programs to be installed on server devices are distributed in a state recorded on recording media such as CDs (Compact Discs), DVDs (Digital Versatile Disks), MO disks (Magneto-Optical disks), and flash memory. It may be read into the server device from the recording medium, or it may be superimposed on a carrier wave and supplied to the server device via the communication network 40 or another communication network.

The software functions of the user terminal 30 are realized by installing an OS (Operating System) for the user device and a game program running on the OS into the user device.
Note that instead of the game program, the user terminal 30 can also be installed by installing a web browser program that runs on the OS for the user device and a game program (plug-in) that runs on the web browser program, respectively. Software functions can be implemented.

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

The registration unit 310 registers the player's location or a location similar thereto in the storage unit 370 in response to an individual request from the player. A flag of the player is set at a position in the virtual space that corresponds to the position registered in the storage unit 370. Note that the player's location or a location similar thereto may be registered in the storage unit 370 without depending on an individual request from the player.
Further, the registration unit 310 invalidates the flag stored in the storage unit 370 through a predetermined procedure or at a predetermined opportunity. For example, the flag is invalidated through a procedure of erasing the flag set by the player. For example, when a new flag is installed by a player and the number of installed flags reaches the upper limit (1 in the service of the embodiment), flags installed at older times are invalidated. Also, for example, it is invalidated in daily batch processing.

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

The accepting unit 320 accepts challenges for solo play and multiplay of quests from the user terminals 30 of players who are qualified to challenge. In particular, the reception unit 320 receives multiplayer recruitment from the user terminals 30 of players who are qualified to challenge, and also receives applications for the recruitment from the user terminals 30 of players who meet the participation conditions for the recruitment.
In response to a request from the user terminal 30, the search unit 330 searches virtual waiting room information stored in the storage unit 370 for a room in which the requesting player satisfies the participation conditions, and transmits the search results to the requesting room. return.

The providing unit 340 provides display data to the user terminal 30. Further, the providing unit 340 provides the quest challenger's user terminal 30 with parameters for progressing the quest (progress parameters) and data for displaying results.
The designation section 350 includes a first designation section 351 that designates challengers for solo play and challengers who host multiplay, and a second designation section 352 that designates challengers who will participate in multiplay.

The first designation unit 351 designates, for example, the following players as challengers who take on the solo play of the spot-limited quest. Note that regarding the latter, the play position condition does not need to be satisfied at the moment.
- Players who currently meet the play position conditions - Players who have placed flags at positions that meet the play position conditions (in other words, players who have satisfied the play position conditions in the past)

Further, the first designation unit 351 designates, for example, the following player as a challenger (host) who hosts a multiplayer of a spot-limited quest. Note that regarding the latter, the play position condition does not need to be satisfied at the moment.
- Players who currently meet the play position conditions - Players who have placed flags at positions that meet the play position conditions (in other words, players who have satisfied the play position conditions in the past)

The second designation unit 352 designates, for example, the following players as challengers (guests) who participate in the spot-limited quest multiplayer.
・Players who have applied for recruitment by hosts who currently meet the play position conditions. ・Players who have applied for recruitment by hosts who have met the play position conditions in the past. In this case, as long as the guest meets the conditions below, the guest will be able to accept the play position conditions. It doesn't have to be fulfilled at the moment.
- Currently located near the host's current location.
- The host was located in the vicinity of the host's current location in the past (that is, a flag was set).
- Currently located near the past location of the host (that is, the flag installation location).
- The host was located in the past (that is, the flag was installed) near the host's previous location (that is, the flag installation position).
- The host has accessed a virtual waiting room specified by a URL obtained from an SNS, etc. outside the system of the embodiment.

The setting unit 360 sets parameters related to the quest (for example, progress parameters, calculation parameters) as follows, for example.
- Set parameters for challengers who challenge solo play, taking into account the spot effects applied to the challenger.
- Setting parameters for the challenger (host) who hosts the multiplayer, taking into account the spot effects that are applied to the challenger and the challenger (guest) participating in the multiplayer. In particular, when a specific spot effect is applied to a guest, an equal or lesser effect is applied to the host as well.
- Parameters for challengers (guests) participating in multiplayer, spot effects that are applied to the challenger, challenger (host) hosting the multiplayer, and other challengers (guests) participating in the multiplayer. Set accordingly. In particular, when a specific spot effect is applied to the host or another guest, an effect equal to or lower than the spot effect is also applied to the guest.

Further, the setting unit 360 sets parameters (for example, progress parameters, calculation parameters) related to the spot-limited quest, for example, as follows.
- Parameters for challengers who challenge solo play of spot-limited quests will be set so that they differ depending on the positional relationship between the challenger and the spot from the past to the present. In particular, if the challenger is currently in the vicinity of the predetermined location, the challenger will have a relative advantage, and if the challenger has been in the vicinity of the predetermined location in the past but is not currently in the vicinity of the predetermined location, the challenger will have a relative advantage. Set parameters for the challenger so that the challenger is at a disadvantage.
- Set the parameters for the challenger (host) who hosts the multiplayer of the spot-limited quest so that they differ depending on the positional relationship between the challenger and the spot from the past to the present. In particular, if the host is currently around the predetermined location, it will have a relative advantage, and if the host has been around the predetermined location in the past but is not currently around the predetermined location, the host will have a relative advantage. Set parameters for the host to be disadvantageous.
・The parameters for challengers (guests) who participate in multiplayer for spot-limited quests will 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. Set it as follows. In particular, if the host is currently around the predetermined location, it will have a relative advantage, and if the host has been around the predetermined location in the past but is not currently around the predetermined location, the host will have a relative advantage. Set parameters for the guest to their disadvantage. In addition, if the guest is currently in the vicinity of the predetermined location, or if the host has been in the vicinity of the predetermined location in the past but is not currently in the vicinity of the predetermined location, the host has been in the vicinity of the predetermined location from the past to the present. If the guest has never been in the vicinity, parameters are set for the guest so that the degree of advantage is reflected in this order.

[2-3-4. Database configuration]
FIG. 4 illustrates the 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 play of the quest starts or after the 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 based on the example. may be added or deleted from time to time by the service operator. The flag management information (FIG. 4(e)) and spot effect management information (FIG. 4(g)) are added through a predetermined procedure by each player, and are cleared periodically. The virtual standby room information (FIG. 4(h)) and the virtual standby management information (FIG. 4(i)) are generated when a request for multiplayer is accepted.

(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 a "player ID" unique to the player with at least an "experience value" and a "player rank."

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

(3) Spot type definition information The storage unit 370 stores spot type definition information that defines various parameters related to each spot type.
As illustrated in FIG. 4C, the spot type definition information associates at least a "spot icon path" with a "spot type ID".
The "spot icon path" is information that contributes to specifying a spot icon (image) that is displayed at a spot arrangement position and represents the type of spot.

(4) Spot Effect Setting Information The storage unit 370 stores spot effect setting information for setting 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 "effect type ID".
“Value 1”, “Value 2”, “Value 3”, etc. are the values after changing a specific parameter (progress parameter or calculation parameter) used in the service of the example, or the process of changing the parameter. This is the value used for Note that "value 1", "value 2", and "value 3" may be values used for parameter settings when a spot effect, a pseudo spot effect, and a pseudo spot effect are respectively applied.

(5) Flag Management Information The storage unit 370 stores flag management information for managing various parameters related to flags set by each player.
As illustrated in FIG. 4E, the flag management information associates a "player ID" with at least a "flag status ID," a "flag position," and an "invalid flag."
"Flag position" indicates a flag installation position in virtual space. In this embodiment, since the virtual space is geographically associated with the real space, the "flag position" is specified using data (for example, latitude and longitude) representing the geographical position in the real space. The "invalid flag" indicates that the flag is invalid when it is significant.
In addition, when setting a flag at a specific spot, the configuration may be such that the "spot position" is set in the "flag position", or the "spot ID" is set in place of the "flag position".
It may be configured to store. In the latter configuration, the installation position of the flag is specified by the installation position of the spot identified by the "spot ID".

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

(7) Spot effect management information The storage unit 370 stores spot effect management information that is given to each player through an acquisition procedure by that player and manages various parameters related to spot effects.
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 (for example, acquired/applied). If there is an upper limit to the number of applications, the remaining number of applications may be indicated. The "invalid flag" indicates that the spot effect is invalid when it is significant.
Note that the "invalid flag" is set, for example, when the number of applications reaches the upper limit (1 in the service of the example) or when a new spot effect is acquired and the number of acquisitions reaches the upper limit (1 in the service of the example). It becomes significant when it reaches .

(8) Virtual Standby Room Information The storage unit 370 stores virtual standby room information that records various parameters related to the virtual standby room corresponding to each multiplayer recruitment.
As illustrated in FIG. 4(h), the virtual standby room information includes "virtual standby room ID", "recruiter" (player ID), "multiplayer classification", "participation conditions", and "status". at least correspond to
The "multiplayer category" indicates, for example, short distance multiplayer or SNS multiplayer. The "participation conditions" are, for example, temporal conditions, spatial conditions (geographical conditions), passwords, etc. “Status” indicates the multiplayer recruitment status (for example, recruiting/recruitment completed).

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

[2-4. In-game actions before executing the quest]
[2-4-1. Screen display update procedure]
FIG. 5 illustrates a screen display update procedure performed by the system of the embodiment. FIG. 5 shows a procedure in which player A moves in real space while holding the user terminal 30a, and the map display on the screen of the user terminal 30a is updated as needed.
[S505] The user terminal 30a accepts the map display instruction operation by player A. The map display instruction operation is, for example, a tap operation on a "map display" menu displayed by a tap operation on a certain tab arranged on the home screen.
[S510] The user terminal 30a identifies its current location (current location). A GPS unit 261 is used to specify the current position.
[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 one or more map image data (or their URL) representing a map of a predetermined range of virtual space corresponding to a predetermined range including the current position of the user terminal 30a, and display in the predetermined range on the map. Icon data (or their URLs) of objects (in the service of the example, a spot placed in a roughly circular area with a radius of 50 m centered on the current position and a flag of the player set in the roughly circular area) ) and other parameters.
[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 corresponding positions on the map.
[S530] After the predetermined time has elapsed, the process returns to [S510] above. Thereafter, as long as "map display" is selected on the user terminal 30a, the steps from [S510] to [S525] are repeated at predetermined time intervals.

[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 player A moves in real space with the user terminal 30a and sets a flag at a position in virtual space that corresponds to the current location.
[S605] The user terminal 30a accepts the flag installation instruction operation by player A. The flag installation instruction operation is, for example, a tap operation in response to a flag installation command.
[S610] The user terminal 30a identifies its current location (current location). A GPS unit 261 is used to specify the current position.
[S615] The user terminal 30a instructs the user management server 10 to install 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 the player A, the "invalidation flag" is updated (made significant) and invalidated.
[S625] The user management server 10 provides display data to the user terminal 30a. The display data is similar to that provided in [S520] (FIG. 5).
[S630] 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 an icon of a newly installed flag is placed at a corresponding position on the map.

Note that only when a spot is displayed on the map (when the spot is located around a position corresponding to the spot arrangement position), a flag may be set for the spot.
In this case, the user terminal 30a may receive a flag installation instruction operation for the spot by player A, such as a tap operation on a flag installation command displayed by a tap operation on the icon of the spot displayed on the map. The user management server 10 may set the "spot position" of a spot located around the position indicated by the position data to the "flag position".

[2-4-3. Flag deletion procedure]
FIG. 7 illustrates a flag deletion procedure by the system of the embodiment. FIG. 7 shows a procedure in which player A operates the user terminal 30a to delete an installed flag.
[S705] The user terminal 30a accepts the 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 installed flag menu.
[S710] The user terminal 30a instructs the user management server 10 to delete the flag. The instruction includes data specifying the target flag. Note that when the upper limit of the number of flags to be installed is 1, data that can identify the target flag is not essential because it is sufficient to delete the currently valid flag.
[S715] The user management server 10 updates the flag management information (FIG. 4(e)) stored in the storage 21. Specifically, the "invalidation flag" of the flag management information of the flag to be deleted (for example, the target flag, the latest flag) associated with the player A is updated (made significant) and invalidated.
[S720] The user management server 10 notifies the user terminal 30a of the update result.
[S725] The user terminal 30a displays the update results.

[2-4-4. Spot effect acquisition procedure]
FIG. 8 illustrates a spot effect acquisition procedure by the system of the embodiment. FIG. 8 shows a procedure in which player A operates the user terminal 30a to acquire the spot effects of spots placed around a position in the virtual space corresponding to the current location.
[S805] The user terminal 30a accepts the spot designation operation by player A. The spot designation operation is, for example, a tap operation on a spot icon arranged on a map.
[S810] The user terminal 30a accepts the 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 by the spot designation operation.
[S815] The user terminal 30a instructs the user management server 10 to acquire spot effects. The instruction includes data that can identify 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. Additionally, if there is valid spot effect management information associated with the player A, the "invalidation flag" is updated (made significant) and invalidated.
[S825] The user management server 10 provides display data to the user terminal 30a. The display data is similar to that provided in [S520] (FIG. 5).
[S830] The user terminal 30a updates the screen display. The icon of the target spot placed at the corresponding position on the map displayed on the screen of the user terminal 30a changes.

[2-5. Procedures related to quest execution]
[2-5-1. Solo play execution procedure]
FIG. 9 illustrates a solo play execution procedure by the system of the embodiment. FIG. 9 shows the procedure after a quest is selected by player A's user terminal 30a.
[S905] The user terminal 30a accepts player A's selection of solo play.
[S910] The user terminal 30a organizes a deck according to player A's operation.
[S915] The user terminal 30a instructs the user management server 10 to challenge the quest by solo play in response to player A's operation.
[S920] The user management server 10 specifies a quest challenger. Here, player A is designated as a challenger who challenges solo play.

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

[S930] The user management server 10 provides quest progression parameters to the user terminal 30a.
[S935] The user terminal 30a proceeds with the quest. Quest progress parameters are used to progress the quest.
[S940] After the quest ends, the user terminal 30a notifies the user management server 10 of the end of the quest.

[S945] The user management server 10 sets reward calculation parameters for challengers. Here, the spot effect applied to the challenger is taken into consideration. Specifically, similarly to [S925], the spot effect to be applied (“value 1”, “value 2”, “value 3”, . . . ) is specified. 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", etc. As a result, the target calculation parameter increases. In the case of a spot-limited quest, the amount or rate of increase in the calculation parameter is adjusted by taking into account the positional relationship between the spot and the challenger. Note that the setting process in [S945] may be configured to be executed together with [S925] before the progress of the quest starts.

[S950] The user management server 10 updates the player data stored in the storage 21. For example, the "experience value" and "player rank" of the player information (FIG. 4(a)) corresponding to the challenger are increased according to the reward calculation parameters.
[S955] The user management server 10 provides result display data to the user terminal 30a.
[S960] The user terminal 30a displays the results including the earned reward. For example, a state in which pre-update data changes to post-update data due to a predetermined audiovisual effect is shown.

[2-5-1-1. If the challenger is currently located around the spot]
FIG. 10 is an explanatory diagram of the positional relationship in solo play.
In the example shown in FIG. 10, the challenger 1020 is currently located around a predetermined position in the real space that corresponds to the placement position of the spot 1010 (for example, inside a substantially circular area with a radius of 50 m). In this case, the challenger is given a spot benefit (for example, application of a spot effect, qualification to play a spot-limited quest) derived from the current location.

(1) Application of spot effects to normal quest play When a normal quest is played solo in the positional relationship shown in FIG. 10, spot effects can be applied to the challenger.
FIG. 11 illustrates a procedure for starting play of a normal quest by the system of the embodiment. After the normal quest is started according to the procedure shown in FIG. 11, the process proceeds to the solo play execution procedure (FIG. 9).
[S1105] The user terminal 30a accepts the quest selection screen display instruction operation by player A. The quest selection screen display instruction is, for example, a tap operation on a "quest" button arranged on the home screen.
[S1110] The user terminal 30a accepts the quest selection operation by player A. The quest selection operation is a series of operations for selecting one of the quests from a list of quests or a classification of quests classified from a predetermined viewpoint. Note that, in the list and classification of quests, only quests for which player A satisfies the play conditions are displayed so as to be selectable. The play conditions are, for example, at least one of temporal conditions, spatial conditions (geographical conditions), skill level conditions, and the like.

In [S925] (FIG. 9), the user management server 10 sets quest progression parameters for the challenger, taking into account at least the spot effect applied to the challenger.
Further, in [S945] (FIG. 9), the user management server 10 sets reward calculation parameters for the challenger, taking into account at least the spot effect applied to the challenger.

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

[2-5-1-2. If the challenger was located near the spot in the past]
FIG. 13 is an explanatory diagram of the positional relationship in solo play.
In the example shown in FIG. 13, a challenger was previously located around a predetermined position in real space corresponding to the placement position of spot 1310 (for example, inside a substantially circular area with a radius of 50 m). That is, a challenger's flag 1320 is placed around the spot placement position. In this case, the challenger is given a fictitious spot benefit (for example, application of a spot effect, qualification to play a spot-limited quest) derived from the past location.

(1) Application of fictitious spot effects to the normal quest play When a normal quest is played solo in the positional relationship shown in FIG. 13, the fictitious spot effects can be applied to the challenger.
After the normal quest is started according to the procedure shown in FIG. 11, the process proceeds to the solo play execution procedure (FIG. 9).

In [S925] (FIG. 9), the user management server 10 sets quest progression parameters for the challenger, taking into account at least the spot effect (imagined spot effect) applied to the challenger.
Further, in [S945] (FIG. 9), the user management server 10 sets reward calculation parameters for the challenger, taking into account at least the spot effect (imagined spot effect) applied to the challenger.

(2) Playing spot-limited quests In the positional relationship shown in FIG. 13, solo play of spot-limited quests is possible.
FIG. 14 illustrates a procedure for starting play of a spot-limited quest by the system of the embodiment. After the spot-limited quest is selected according to the procedure shown in FIG. 14, the process proceeds to the solo play execution procedure (FIG. 9).
[S1405] The user terminal 30a accepts the flag designation operation by 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 the 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 the 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 the 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.

[2-5-2. Multiplayer execution procedure]
FIG. 15 exemplifies a multiplay execution procedure by the system of the embodiment. FIG. 15 shows the procedure after player A selects a quest, player A starts recruiting for multiplayer, and player B applies for the recruitment.
[S1505] The user terminal 30a organizes a deck according to player A's operation.
[S1510] The user terminal 30a accepts a challenge instruction operation by player A.
[S1515] The user terminal 30a instructs the user management server 10 to challenge the quest through multiplayer in response to player A's operation.
[S1520] The user management server 10 specifies a quest challenger. Here, players A and B are each designated as challengers (host, guest) who challenge the multiplayer.

[S1525] The user management server 10 sets quest progress parameters for the host and for the guest. Here, a spot effect applied to at least some of the challengers is taken into consideration. Specifically, when spot definition information (Fig. 4(b)) corresponding to a certain challenger's current position is stored, spot effect setting information (Fig. 4(d)) is stored using the "effect type ID". Specify the spot effect (“value 1”, “value 2”, “value 3”, etc.) to be applied. In addition, when flag management information (Fig. 4 (e)) is stored in association with a certain challenger, the spot definition information (Fig. 4 (b)) is specified by the "flag position", and the "effect type ID ” specifies the spot effect setting information (FIG. 4(d)), and specifies the spot effect to be applied (“value 1”, “value 2”, “value 3”, . . . ). In addition, 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", and the "effect type The spot effect setting information (FIG. 4(d)) is specified by the ID, and the applied spot effect (value 1, value 2, value 3, . . . ) is specified. If there is a target parameter among the default progress parameters, it is updated using at least one of "value 1", "value 2", "value 3", . . . As a result, the target progression parameter increases. These processes are performed for all challengers. In the case of a spot-limited quest, the amount or rate of increase in the progress parameter is adjusted by 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.

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

[S1540] After the quest ends, the user management server 10 sets remuneration calculation parameters for the host and for the guest. Here, a spot effect applied to at least some of the challengers is taken into consideration. Specifically, as in [S1525], each spot effect to be applied (“value 1”, “value 2”, “value 3”, etc.) is specified, and the target one of the default calculation parameters is specified. If there is a parameter, update it using at least one of "Value 1", "Value 2", "Value 3", etc. to increase the target calculation parameter by all challengers. Do this for each minute. In the case of a spot-limited quest, the amount or rate of increase in the calculation parameter is adjusted by 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. Note that the setting process in [S1540] may be configured to be executed together with [S1525] before the progress of the quest starts.

[S1545] The user management server 10 updates the player data stored in the storage 21. For example, the "experience value" and "player rank" of the player information (FIG. 4(a)) corresponding to the host and the guest, respectively, are increased according to the reward calculation parameters.
[S1550] The user management server 10 provides result display data to the user terminals 30a and 30b, respectively.
[S1555a,b] The user terminal 30a and the user terminal 30b each display the results including the earned reward. For example, a state in which pre-update data changes to post-update data due to a predetermined audiovisual effect is shown.

[2-5-2-1. Short distance multi execution procedure]
FIG. 16 illustrates a short-distance multi-recruitment procedure by the system of the embodiment. Further, FIG. 17 exemplifies the short-distance multi application procedure by the system of the embodiment. FIG. 16 shows the procedure after player A selects a quest. FIG. 17 shows the procedure following FIG. 16.
[S1605] The user terminal 30a accepts player A's selection of multiplayer.
[S1610] The user terminal 30a accepts player A's selection of short distance multiplayer.
[S1615] The user terminal 30a compiles a temporary deck according to player A's operation.
[S1620] The user terminal 30a accepts the short-distance multiplayer recruitment instruction operation by player A. Note that in the service of the embodiment, player A can set a password (a three-digit number string) when recruiting for multiplayer. If a password is set, that setting is also accepted.
[S1625] The user terminal 30a identifies the current location (current location). A GPS unit 261 is used to specify the current position.
[S1630] The user terminal 30a instructs the user management server 10 to recruit short-distance multiplayers. 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 of acceptance of short-distance multiplayer recruitment.
[S1640] The user management server 10 registers new virtual standby room information (FIG. 4(h)) and virtual standby management information (FIG. 4(i)) in the storage 21, and creates a virtual standby room. . At this time, the "multiplayer category" is short distance multiplayer, the "participation condition" is being located near the location indicated by the location data included in the recruitment instruction, and the "status" is recruiting. In addition, if the recruitment instructions include a secret word, the secret word also constitutes a "participation condition."

[S1705] The user terminal 30b accepts the short distance multiplayer search instruction operation by player B. When player B specifies a password (three-digit number string) when searching for recruitment, that specification is also accepted.
[S1710] The user terminal 30b identifies the current location (current location). A GPS unit 261 is used to specify the current position.
[S1715] The user terminal 30b instructs the user management server 10 to search for recruitment that meets the participation conditions. The instruction may include a designated password and location data indicating the current location of the user terminal 30b.
[S1720] The user management server 10 identifies information related to short-distance multiplayer recruitment for which Player B satisfies the participation conditions and play conditions from among the virtual standby 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. satisfy predetermined conditions).
[S1725] The user management server 10 provides the search results to the user terminal 30b.
[S1730] The user terminal 30b selects and notifies the user management server 10 of one of the short-distance multiplayer recruitments according to the operation by player B.
[S1735] The user management server 10 allows the user terminal 30b to apply for the selected recruitment.
[S1740] The user terminal 30b compiles a temporary deck according to player B's operation.
[S1745] The user terminal 30b instructs the user management server 10 to apply for the selected recruitment in response to the application instruction operation by player B.
[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 the application from player B for the selected recruitment. .
[S1755] The user management server 10 notifies the user terminal 30a that the application has been accepted.

[2-5-2-1-1. If the host is currently located near the spot]
FIG. 18 is an explanatory diagram of the positional relationship in short distance multiplayer.
In the example shown in FIG. 18, the host 1820 is currently located around a predetermined position in the real space corresponding to the placement position of the spot 1810 (for example, inside a substantially circular area with a radius of 50 m). In this case, the host is given spot benefits (for example, application of spot effects, eligibility to play spot-limited quests) derived from the current location.

Furthermore, guests 1830a and 1830b are currently located near the current location of host 1820. Guest 1830a is currently located around the predetermined location. On the other hand, the guest 1830b is not present around the predetermined location. In this case, the guest 1830a is given a spot privilege (a privilege equivalent to the spot privilege given to the host 1820) derived from the current location. On the other hand, the guest 1830b is given a pseudo spot privilege (a privilege inferior to the spot privilege) that is similar to the spot privilege given to the host 1820.

FIG. 19 is an explanatory diagram of the positional relationship in short distance multiplayer.
In the example shown in FIG. 19, a host 1920 is currently located around a predetermined position in real space that corresponds to the placement position of the spot 1910 (for example, inside a substantially circular area with a radius of 50 m). In this case, the host is given spot benefits (for example, application of spot effects, eligibility to play spot-limited quests) derived from the current location.

Further, a guest was located near the current location of the host 1920 in the past. That is, guest flags 1930a and 1930b are placed near the position in the virtual space corresponding to the current location of the host 1920, respectively. The guest with the flag 1930a installed was located near the predetermined location in the past, but is not located at the present time. On the other hand, the guest who has installed the flag 1930b has not been located around the predetermined position from the past to the present. In this case, the former is given a fictitious benefit (a privilege inferior to the spot privilege) derived from the past location. On the other hand, the latter is given a pseudo benefit (a privilege inferior to the spot privilege) that is similar to the spot privilege given to the host 1920. Note that it is preferable that the pseudo-benefits given to the former be superior to the pseudo-benefits given to the latter.

(1) Application of fictitious spot effects to play of normal quests When a short distance multiplayer of normal quests is performed in the positional relationships shown in FIGS. 18 and 19, spot effects can be applied to the host. Further, any one of a spot effect, a fake spot effect, and a pseudo spot effect may be applied to the guest.
After the normal quest is started according to the procedure shown in FIG. 11, the process proceeds to the multiplayer execution procedure (FIG. 15) after recruiting and applying for short-distance multiplayer according to the procedures shown in FIGS. 16 and 17.

In [S1525] (FIG. 15), the user management server 10 sets quest progression parameters for challengers, taking into account at least the spot effect applied to at least some of the challengers.
Further, in [S1540] (FIG. 15), the user management server 10 sets reward calculation parameters for hosts and guests, taking into account at least the spot effect applied to at least some of the challengers.

(2) Playing spot-limited quests In the positional relationships shown in FIGS. 18 and 19, short-distance multiplayer of spot-limited quests is possible. After the spot-limited quest is selected according to the procedure shown in FIG. 12, the process proceeds to the multiplayer execution procedure (FIG. 15) through recruitment and application for short-distance multiplayer according to the procedures shown in FIGS. 16 and 17.

[2-5-2-1-2. If the host was located near the spot in the past]
FIG. 20 is an explanatory diagram of the positional relationship in short distance multiplayer.
In the example shown in FIG. 20, the host 2030 was previously located around a predetermined position in the real space corresponding to the placement position of the spot 2010 (for example, inside a substantially circular area with a radius of 50 m). That is, the flag 2020 of the host 2030 is placed around the spot placement position. In this case, the host 2030 is given a fictitious spot benefit (for example, application of a spot effect, qualification to play a spot-limited quest) derived from the past location.

Furthermore, a guest 2040 is currently located near the current location of the host 2030 . Guest 2040 is not currently located around the predetermined location. In this case, the guest 2040 is given a pseudo-spot benefit (a privilege inferior to the pseudo-spot privilege) that is similar to the pseudo-spot privilege given to the host 2030.

FIG. 21 is an explanatory diagram of the positional relationship in short distance multiplayer.
In the example shown in FIG. 21, a host was previously located around a predetermined position in real space corresponding to the placement position of spot 2110 (for example, inside a substantially circular area with a radius of 50 m). That is, a host flag 2120 is placed around the spot placement position. In this case, the host is given a fictitious spot benefit (for example, application of a spot effect, qualification to play a spot-limited quest) derived from the host's past location.

Furthermore, guests 2130a and 2130b are currently located near the host's past location. The guest 2130a is currently located around the predetermined location. On the other hand, the guest 2130b is not present around the predetermined location. In this case, the former is given a spot benefit derived from the current location (a privilege that is superior to the fictitious spot privilege given to the host). On the other hand, the guest 2130b is given a pseudo-spot privilege (a privilege inferior to the pseudo-spot privilege) that is similar to the pseudo-spot privilege given to the host.

FIG. 22 is an explanatory diagram of the positional relationship in short distance multiplayer.
In the example shown in FIG. 22, a host was previously located around a predetermined position in real space corresponding to the placement position of spot 2210 (for example, inside a substantially circular area with a radius of 50 m). That is, a host flag 2220 is placed around the spot placement position. In this case, the host is given a fictitious spot benefit (for example, application of a spot effect, qualification to play a spot-limited quest) derived from the host's past location.

In addition, each guest was located near the host's past location. That is, guest flags 2230a and 2230b are installed near the installation position of host flag 2220, respectively. The guest who has set the flag 2230a was located near the predetermined location in the past, but is not located at the present time. On the other hand, the guest who has installed the flag 2230b has not been located around the predetermined position from the past to the present. In this case, the former is given a virtual spot benefit (a privilege equivalent to the virtual spot privilege given to the host) derived from the past location. On the other hand, the latter is given a pseudo-spot privilege (a privilege inferior to the pseudo-spot privilege) that is similar to the pseudo-spot privilege given to the host.

(1) Application of spot effects in normal quests When a short-distance multiplayer of normal quests is performed in the positional relationships shown in FIGS. 20 to 22, a fictitious spot effect can be applied to the host. Further, any one of a spot effect, a fake spot effect, and a pseudo spot effect may be applied to the guest.
After the normal quest is started according to the procedure shown in FIG. 11, the process proceeds to the multiplayer execution procedure (FIG. 15) after recruiting and applying for short-distance multiplayer according to the procedures shown in FIGS. 16 and 17.

(2) Playing spot-limited quests In the positional relationships shown in FIGS. 20 to 22, short-distance multiplayer of spot-limited quests is possible. After the spot-limited quest is selected according to the procedure shown in FIG. 14, the process proceeds to the multiplayer execution procedure (FIG. 15) through recruitment and application for short-distance multiplayer according to the procedures shown in FIGS. 16 and 17.

[2-5-2-2. SNS multi execution procedure]
FIG. 23 illustrates an SNS multi-recruitment procedure by the system of the embodiment. Further, FIG. 24 illustrates an SNS multi application procedure by the system of the embodiment. FIG. 23 shows the procedure after a quest is selected. FIG. 24 shows the procedure following FIG. 23.
[S2305] The user terminal 30a accepts player A's selection of multiplayer.
[S2310] The user terminal 30a accepts player A's selection of SNS multiplayer.
[S2315] The user terminal 30a compiles a temporary deck according to player A's operation.
[S2320] The user terminal 30a instructs the user management server 10 to recruit for SNS multiplayer.
[S2325] The user management server 10 notifies the user terminal 30a of the acceptance of the SNS multiplayer recruitment. The notification may include a URL to which an SNS program activation command and data that can identify the recruitment are added.
[S2330] The user terminal 30a directly or indirectly transmits a message including the above URL to the user terminal 30b outside the system of the embodiment.
[S2335] The user terminal 30a instructs the user management server 10 to start recruitment for the SNS multi by accessing the above URL.
[S2340] The user management server 10 notifies the user terminal 30a of the acceptance of the start of recruitment for SNS Multi.
[S2345] The user management server 10 registers new virtual standby room information (FIG. 4(h)) and virtual standby management information (FIG. 4(i)) in the storage 21, and creates a virtual standby room. . At this time, the "multiplayer category" is SNS multiplayer, the "participation condition" is to apply by accessing the above URL, and the "status" is recruiting.

[S2405] The user terminal 30b instructs the user management server 10 to search for a virtual waiting room that satisfies the participation conditions by accessing the above URL.
[S2410] The user management server 10 identifies information related to SNS multiplayer recruitment 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. satisfy predetermined conditions). Here, the recruitment specified by the above URL is specified.
[S2415] The user management server 10 provides the search results to the user terminal 30b.
[S2420] The user terminal 30b asks the user management server 10 to select the specified SNS multiplayer recruitment in response to the operation by player B.
[S2425] The user management server 10 allows the user terminal 30b to apply for the selected recruitment.
[S2430] The user terminal 30b compiles a temporary deck according to player B's operation.
[S2435] The user terminal 30b instructs the user management server 10 to apply for the selected recruitment in response to the application instruction operation by player B.
[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 the application from player B for the selected SNS multi. accept.
[S2445] The user management server 10 notifies the user terminal 30a that the application has been accepted.

[2-5-2-2-1. If the host is currently located near the spot]
FIG. 25 is an explanatory diagram of the positional relationship in SNS multi.
In the example shown in FIG. 25, the host 2520 is currently located around a predetermined position in the real space corresponding to the placement position of the spot 2510 (for example, inside a substantially circular area with a radius of 50 m). In this case, the host is given spot benefits (for example, application of spot effects, eligibility to play spot-limited quests) derived from the current location.

On the other hand, the guest 2530 is not currently located near the host 2520's current location. Furthermore, the guest 2530 is not present around the predetermined location. In this case, the guest 2530 is given a pseudo spot privilege (a privilege inferior to the spot privilege) that is similar to the spot privilege given to the host 2520.

(1) Application of spot effects in normal quests When SNS multiplication of normal quests is performed in the positional relationship shown in FIG. 25, spot effects can be applied to the host. Additionally, a pseudo spot effect may be applied to the guest.
After the normal quest is started according to the procedure shown in FIG. 11, the process proceeds to the multiplayer execution procedure (FIG. 15) through SNS multiplayer recruitment and application according to the procedures shown in FIGS. 23 and 24.

In [S1525] (FIG. 15), the user management server 10 sets quest progression parameters for challengers, taking into account at least the spot effect applied to at least some of the challengers.
Further, in [S1540] (FIG. 15), the user management server 10 sets reward calculation parameters for hosts and guests, taking into account at least the spot effect applied to at least some of the challengers.

(2) Playing spot-limited quests In the positional relationship shown in FIG. 25, it is possible to play spot-limited quests on SNS. After the spot-limited quest is selected according to the procedure shown in FIG. 12, the process proceeds to the multiplayer execution procedure (FIG. 15) through SNS multiplayer recruitment and application according to the procedures shown in FIGS. 23 and 24.

[2-5-2-2-2. If the host was located near the spot in the past]
FIG. 26 is an explanatory diagram of positional relationships in SNS multi.
In the example shown in FIG. 26, a host was previously located around a predetermined position in real space that corresponds to the placement position of spot 2610 (for example, inside a substantially circular area with a radius of 50 m). That is, a host flag 2620 is placed around the spot placement position. In this case, the host is given a fictitious spot benefit (for example, application of a spot effect, qualification to play a spot-limited quest) derived from the host's past location.

On the other hand, the guest 2630 has not been located near the host's past location from the past to the present. Further, the guest 2630 has not been located around the predetermined location from the past to the present. In this case, the guest 2630 is given a pseudo-spot benefit (a privilege inferior to the pseudo-spot privilege) that is similar to the pseudo-spot privilege given to the host.

(1) Application of spot effects in normal quests When SNS multiplication of normal quests is performed in the positional relationship shown in FIG. 26, a fictitious spot effect can be applied to the host. Additionally, a pseudo spot effect may be applied to the guest.
After the normal quest is started according to the procedure shown in FIG. 11, the process proceeds to the multiplayer execution procedure (FIG. 15) through SNS multiplayer recruitment and application according to the procedures shown in FIGS. 23 and 24.

In [S1525] (FIG. 15), the user management server 10 sets quest progression parameters for challengers, taking into account at least the spot effect applied to at least some of the challengers.
Further, in [S1540] (FIG. 15), the user management server 10 sets reward calculation parameters for hosts and guests, taking into account at least the spot effect applied to at least some of the challengers.

(2) Playing spot-limited quests In the positional relationship shown in FIG. 26, it is possible to play spot-limited quests on SNS. After the spot-limited quest is selected according to the procedure shown in FIG. 14, the process proceeds to the multiplayer execution procedure (FIG. 15) through SNS multiplayer recruitment and application according to the procedures shown in FIGS. 23 and 24.

10 User management server (an example of game information processing device)
20 Data management server 21 Storage 30 User terminal 40 Communication network 310 Registration section 320 Reception section 330 Search section 340 Providing section 350 Designation section 351 First designation section 352 Second designation section 360 Setting section 370 Storage section

Claims (3)

If the position of the first terminal specified on the map was in the past within a predetermined range from the position corresponding to the object placed on the map, the first terminal is requested to play a game based on the object. The information processing device allows the first terminal to receive benefits based on the play of the game, and makes the privileges granted based on the play of the game more disadvantageous to the first terminal than when the current position is within the predetermined range. the processor, if the position of the first terminal identified on the map was in a predetermined range from a position corresponding to an object placed on the map, the processor controls the first terminal to play a game based on the object; an information processing method that allows the first terminal to play the game, and makes the privilege awarded based on the play of the game more disadvantageous to the first terminal than when the current position is within the predetermined range. The processor is configured to cause the first terminal to play a game based on the object when the position of the first terminal specified on the map was in a predetermined range from a position corresponding to an object placed on the map in the past. A program that causes a processor to execute a process that allows the first terminal to play the game, and makes the first terminal more disadvantageous in benefits provided based on the play of the game than when the current position is within the predetermined range.

Images