Information processing apparatus and program

Abstract

To relax geographical restriction set in an object game under a prescribed condition.SOLUTION: A "game information processing device" (for example, the user management server 10) according to one aspect of the present invention includes registration means (for example, the registration part 310) for storing a location of a player as a location record (for example, a flag) in storage means with or without a request from the player; And a first designator (for example, the first designator 351) configured to designate a first player (for example, a player who does not satisfy a play position condition at present) having the location record indicating that the first player has satisfied the play position condition in the past, as a challenger (for example, a player of a solo play or a host of a multi-play) who challenges a target game (for example, a quest) in which a single play (for example, a solo play) is possible only when the play position condition is satisfied.SELECTED DRAWING: Figure 3

Description

[Technical Field]

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

[0002] BACKGROUND ART Electronic games are known that employ a mechanism in which events that are specified depending on the locations of mobile terminals are jointly processed by a plurality of mobile terminals (see, for example, Patent Document 1). Specifically, a monster corresponding to a specific geographical area is displayed on the screens of multiple mobile devices located within that geographical area, and parameters that change the display of the monster are synchronized between nearby mobile devices via short-range wireless communication, thereby making it appear as if the monster is being attacked by multiple players. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2013-220246 Summary of the Invention [Problem to be solved by the invention]

[0004] In the game described in Patent Document 1, the mobile devices of multiple players who attack monsters must each be located within a geographical area corresponding to the monster, which makes it difficult for many players to enjoy events related to the monster due to geographical restrictions.

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

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

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

[0008] In this specification, the following terms are used: "Game" means 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 each stage that makes up a game service. "Player" means a user of the game service. "Play" means a player playing a specific game. "Solo play" means play by a single player. "Cooperative play" refers to synchronized play between multiple players in a cooperative relationship. In cooperative play, a cooperative relationship is formed between a player (host) who hosts a cooperative play of a specific game and recruits friends, and players (guests) who respond to the recruitment and participate in the cooperative play of the specific game, and the progress of play is synchronized between the players. "Challenger" means a player who challenges another to play a particular game. "Nearby" refers to, for example, a range of a predetermined first distance from a player's location. "Around" refers to, for example, a range of a predetermined second distance from a predetermined location. In these examples, the relationship between the first distance and the second distance can be set arbitrarily. "Specified position" refers to, for example, when a virtual space is formed in correspondence with a real space and a spot position is defined within the virtual space, the position in the real space that corresponds to the spot position. "Play location conditions" refer to the conditions required of a challenger who challenges to play a specific game, and relate to the location of the challenger when playing. For example, it means that the challenger's location must be in the vicinity of a specified location. Note that there may be differences between the conditions required of a challenger playing solo and the conditions required of each challenger in cooperative play. There may also be differences between the conditions required of a challenger hosting cooperative play and the conditions required of each challenger participating in that cooperative play. "Event" refers to the cause of adding a new location record or deleting an existing location record. Causes of addition include a player instruction. Causes of deletion include a player instruction, execution of a periodic process, expiration of the validity period, or passage of the expiration date. "Parameters" refers to at least some of the setting data used in playing a specific game. The concept of parameters includes in-game parameters, which primarily affect the progress of the game, and out-game parameters, which primarily affect reward calculations after the game ends. Even if the target of play is the same, there may be differences between the parameters for a challenger in solo play and the parameters for each challenger in cooperative play. There may also be differences between the hosting parameters for a challenger hosting cooperative play and the participation parameters for each challenger participating in the cooperative play. Furthermore, when there are multiple challengers participating in a specific cooperative play, there may be differences in the participation parameters between the challengers. "Applicable Conditions" refers to the location-related conditions for receiving a special benefit when playing a specific game. For example, the player's location must be within a specific location. "Location benefits" refers to geographical benefits granted to players who currently meet the applicable conditions. Location benefits include in-game benefits that primarily affect the progress of the game and out-of-game benefits that primarily affect the calculation of rewards after the game ends. "Fictitious location perks" are geographical perks granted to players who do not currently meet the applicable conditions but have met them in the past. Fictitious location perks are a concept that encompasses in-game perks, which primarily affect the progress of the game, and out-of-game perks, which primarily affect the calculation of rewards after the game ends. The content of the perks can be set to be inferior to location perks. "Pseudo-location benefit" refers to a geographic benefit that may be granted to a player who has not met the applicable conditions from the past to the present when playing cooperatively with other players. For example, if a location benefit or fictitious location benefit is applied to a cooperative play by a player, the geographic benefit granted to another player may not be granted to that player. A pseudo-location benefit is applied to the cooperative play. The pseudo-location benefit is a concept that includes an in-game benefit that primarily affects the progress of the game and an out-of-game benefit that primarily affects the calculation of rewards after the game ends. The content of the benefit can be set to be inferior to the location benefit and the fictitious location benefit. [Effects of the Invention]

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

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

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

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

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

[0014] [1-2-2. Game Information Processing Device] The game information processing device (e.g., user management server 10) of embodiment 2 comprises a registration means (e.g., registration unit 310) that stores the location of a player as a location record (e.g., a flag) in a storage means (e.g., storage unit 370) with or without a request from the player, and a first designation means (e.g., first designation unit 351) that designates a first player (e.g., a player who does not currently satisfy the play location condition) who has the location record indicating that he or she has previously satisfied the play location condition as a challenger (e.g., a solo play player, a multiplayer host) who will challenge a target game (e.g., a quest) that allows single play (e.g., solo play) only if the play location condition is satisfied.

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

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

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

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

[0019] 2. Working Example [2-1. Overview] The present embodiment relates to a gaming service (embodiment service) that is provided at least in part online. In the service of the embodiment, an electronic game (a game in a broad sense) is provided to a player in which the player controls four monsters that make up a deck in sequence through predetermined actions, and sequentially challenges multiple stages (game in a narrow sense) prepared within the game. Hereinafter, these stages will be referred to as "quests."

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

[0021] There are two types of recruitment methods for hosts to recruit guests: recruitment that primarily targets unspecified players in the vicinity, and recruitment that primarily targets specific players in a given location. In the following, multiplayer games that use the former recruitment method will be referred to as close-range multiplayer games, and multiplayer games that use the latter recruitment method will be referred to as SNS multiplayer games.

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

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

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

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

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

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

[0028] Additionally, if a guest is participating in a multiplayer game hosted by a host who satisfies the play location conditions, they will be permitted to challenge the multiplayer game for the spot-specific quest, regardless of whether they satisfy the play location conditions. At this time, the guest's participation parameters (progression parameters, calculation parameters) are adjusted according to the positional relationship between the guest and the spot from the past to the present. Furthermore, if a guest is participating in cooperative play hosted by a host who has a record of having met the play position conditions, the guest will be permitted to play the spot-specific quest in multiplayer regardless of whether or not the play position conditions are met. In this case, the guest's participation parameters (progression parameters, calculation parameters) will be adjusted according to the positional relationships between the host and guest and the spot from the past to the present.

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

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

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

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

[0033] [2-3-1-2. User Management Server] The user management server 10 is a server device (computer) on which a Web server program is installed. In response to a request, the user management server 10 causes the data management server 20 to obtain the necessary data from the storage 21 and provides it (response) to the requestor. In addition, in response to a request, the user management server 10 causes the data management server 20 to register the necessary data in the storage 21. It should be noted that a server system may be configured by linking a plurality of server devices together, and the functions of the user management server 10 may be shared or the load on the user management server 10 may be distributed.

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

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

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

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

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

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

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

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

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

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

[0044] In response to an individual request from a player, the registration unit 310 registers the player's location or a location approximate thereto in the storage unit 370. A flag for the player is set at a position in the virtual space corresponding to the location registered in the storage unit 370. Note that the system may be configured to register the player's location or a location approximate thereto in the storage unit 370 without an individual request from the player. Furthermore, 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 registration unit 310 invalidates the flag through a procedure for erasing the flag by the player. For example, when a player places a new flag and the number of flags placed reaches the upper limit (1 in the service of the embodiment), flags that were placed earlier are invalidated. Also, for example, the flags are invalidated in daily batch processing.

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

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

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

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

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

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

[0051] The setting unit 360 sets parameters related to the quest (for example, parameters for progress, parameters for calculation) as follows, for example. -Set parameters for challengers taking on solo play, taking into account the spot effects applied to that challenger. - The parameters for the challenger (host) who hosts a multiplayer game will be set taking into account the spot effects that are applied to the challenger and the challengers (guests) participating in the multiplayer game. In particular, if a specific spot effect is applied to a guest, an equal or lower effect will also be applied to the host. Parameters for challengers (guests) participating in multiplayer games are set taking into account the spot effects that are applied to the challenger, the challenger (host) hosting the multiplayer game, and other challengers (guests) participating in the multiplayer game. In particular, if a specific spot effect is applied to the host or other guests, an effect of the same or lesser value will be applied to the guest.

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

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

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

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

[0056] (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. 4(c), the spot type definition information associates at least a "spot icon path" with a "spot type ID." The "spot icon path" is information that helps identify the spot icon (image) that is displayed at the spot location and indicates the type of spot.

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

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

[0059] (6) Flag status definition information The storage unit 370 stores flag state definition information that defines, for each flag state, various parameters related to that flag state. As shown 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 helps identify the flag icon (image) that is displayed at the flag installation position and indicates the status of the flag.

[0060] (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 the player and that manages various parameters related to the spot effect. As shown 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 a limit to the number of times it can be applied, it may also indicate the remaining number of times it can be applied. "Invalid flag" indicates that the spot effect is invalid when it is significant. The "invalid flag" is made significant, for example, when the number of applications reaches the upper limit (1 in the service of the embodiment) or when a new spot effect is acquired and the number of acquisitions reaches the upper limit (1 in the service of the embodiment).

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

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

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

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

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

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

[0067] [2-4-4. Spot effect acquisition procedure] 8 illustrates a procedure for acquiring spot effects using the system of the embodiment. FIG. 8 shows a procedure in which player A operates the user terminal 30a to acquire spot effects for spots located around a position in the virtual space that corresponds to the player's current location. [S805] The user terminal 30a accepts a spot designation operation by Player A. The spot designation operation is, for example, a tap operation on a spot icon located on the map. [S810] The user terminal 30a accepts a spot effect acquisition operation by Player A. The spot effect acquisition operation is, for example, a tap operation on a spot effect acquisition command displayed in response to a spot designation operation. [S815] The user terminal 30a instructs the user management server 10 to acquire spot effects. The instruction includes data 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 player A, the "invalidation flag" is updated (set to valid) to invalidate it. [S825] The user management server 10 provides display data to the user terminal 30a. The display data is the same as that provided in [S520] (FIG. 5). [S830] The user terminal 30a updates the screen display. The icon of the target spot located at the corresponding position on the map displayed on the screen of the user terminal 30a changes.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0084] [S1540] After the quest ends, the user management server 10 sets reward calculation parameters for the host and guest. This process takes into account the spot effect applied to at least some of the challengers. Specifically, as in [S1525], the applicable spot effect ("Value 1," "Value 2," "Value 3," ...) is identified for each challenger. If there are any target parameters among the default calculation parameters, they are updated using at least one of "Value 1," "Value 2," "Value 3," ... to increase the target calculation parameters. This process is performed for all challengers. In the case of a spot-only quest, the increase amount or rate of the calculation parameters is adjusted by further taking into account the positional relationship between the spot and the host from the past to the present and the positional relationship between the spot and the guest from the past to the present. Note that the setting process in [S1540] may be configured to be performed together with [S1525] before the quest begins.

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

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

[0087] [S1705] The user terminal 30b accepts a search instruction for short-distance multiplayer from Player B. If Player B specifies a password (a three-digit number string) when searching for recruitment, the user terminal 30b also accepts that specification. [S1710] The user terminal 30b identifies its current location (current location) using the GPS unit 261. [S1715] The user terminal 30b instructs the user management server 10 to search for recruitments that satisfy the participation conditions. The instruction may include a specified password and location data indicating the current location of the user terminal 30b. [S1720] The user management server 10 identifies information related to a short-distance multiplayer game invitation for which Player B satisfies the participation and play conditions from the virtual waiting room information stored in the storage 21. The play conditions are the conditions set for the quest (for example, that the 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 one of the short-distance multiplayer games in response to an operation by Player B and notifies the user management server 10 of the selection. [S1735] The user management server 10 permits the user terminal 30b to apply for the selected job offer. [S1740] The user terminal 30b creates a provisional deck in response to Player B's operations. [S1745] In response to Player B's operation to issue an application instruction, the user terminal 30b instructs the user management server 10 to apply for the selected recruitment. [S1750] The user management server 10 adds the player ID of player B to the virtual standby management information (FIG. 4(i)) stored in the storage 21, and accepts an application from player B for the selected recruitment. [S1755] The user management server 10 notifies the user terminal 30a that the application has been accepted.

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

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

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

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

[0092] (1) Applying the fictitious spot effect to playing regular quests When a normal quest is played in close proximity in the positional relationships shown in Figures 18 and 19, the host may be subject to the spot effect. Also, the guest may be subject to either the spot effect, the fictitious spot effect, or the pseudo spot effect. After a normal quest is started according to the procedure in FIG. 11, the process goes through the recruitment and application for close-range multiplayer according to the procedures in FIGS. 16 and 17, and then the multiplayer execution procedure (FIG. 15) begins.

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

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

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

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

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

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

[0099] FIG. 22 is an explanatory diagram of the positional relationship in short-distance multi-angle photography. In the example shown in FIG. 22, the host was previously located in the vicinity of a predetermined position in real space corresponding to the location of spot 2210 (for example, within a substantially circular area with a radius of 50 m). In other words, the host's flag 2220 is set in the vicinity of the location of the spot. In this case, the host is granted fictitious spot benefits (for example, application of spot effects, eligibility to play spot-limited quests) derived from his / her past location.

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

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

[0102] (2) Playing spot-limited quests Short-distance multiplayer for spot-limited quests is possible in the positional relationships of Figures 20 to 22. After a spot-limited quest is selected using the procedure in Figure 14, short-distance multiplayer is solicited and applied for using the procedures in Figures 16 and 17, and then the multiplayer execution procedure (Figure 15) begins.

[0103] [2-5-2-2. SNS Multi Execution Procedure] Fig. 23 illustrates the recruitment procedure for SNS multi-users using the system of the embodiment. Fig. 24 illustrates the application procedure for SNS multi-users using 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 multiplay. [S2310] The user terminal 30a accepts Player A's selection of SNS multiplayer. [S2315] The user terminal 30a creates a provisional deck in response to Player A's operations. [S2320] The user terminal 30a instructs the user management server 10 to solicit users for the SNS multiplayer. [S2325] The user management server 10 notifies the user terminal 30a that the SNS multi-user invitation has been accepted. The notification may include a URL to which a command to start the SNS program and data for identifying the invitation have been added. [S2330] The user terminal 30a sends a message including the above URL to the user terminal 30b directly or indirectly outside the system of the embodiment. [S2335] The user terminal 30a sends the address specifying the above URL to the user management server 10. By accessing the above, we will instruct the start of recruitment for the above SNS multi-user. [S2340] The user management server 10 notifies the user terminal 30a that it has started accepting applications for the SNS multi-user system. [S2345] The user management server 10 registers new virtual waiting room information (Fig. 4(h)) and virtual waiting management information (Fig. 4(i)) in the storage 21, creating a virtual waiting room. At this time, the "multiplay category" is SNS multiplayer, the "participation conditions" are that applications be made by accessing the URL specified above, and the "status" is "open."

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

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

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

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

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

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

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

[0111] On the other hand, guest 2630 has never been located near the host's past location from the past to the present. Also, guest 2630 has never been located near a predetermined location from the past to the present. In this case, guest 2630 is granted a pseudo spot benefit (a benefit inferior to the fictitious spot benefit) equivalent to the fictitious spot benefit granted to the host.

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

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

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

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

Claims

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

Images