JP7733844B2 - Program and information processing system - Google Patents

Description

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

Conventionally, games that utilize location information indicating the user's location in real space (in other words, the real world) are known (see, for example, Patent Document 1).

Japanese Patent Application Laid-Open No. 2021-069858

By the way, there is a need to promote usage of services such as games.

The present invention aims to provide technology that can promote the use of services.

According to one embodiment shown in the present disclosure,
Computer,
In a service that uses location information indicating a user's location in real space, a program is provided that functions as a replay control means that executes control to make a specific event associated with a specific location in real space playable again in response to payment by the user after the specific event has been cleared.

This invention can promote the use of services.

FIG. 1 is a diagram illustrating a schematic configuration of an information processing system. FIG. 2 is a block diagram showing a functional configuration of the information processing system. FIG. 10 is a diagram showing an example of a game screen. FIG. 10 is a diagram showing an example of a flow in which a revivable event is cleared and revived. FIG. 10 is a diagram showing an example of a screen that provides guidance regarding the revival of a revivable event. FIG. 10 is a diagram illustrating an example of a screen displaying a list of cleared events that can be revived. FIG. 10 is a diagram for explaining how a price for reviving a revivable event is determined depending on the user's current location. FIG. 10 is a diagram illustrating limitations on revival of a revivable event. FIG. 10 is a diagram illustrating the provision of benefits according to the number of times a reviveable event is revived. FIG. 10 is a diagram showing an example of a screen that is displayed when a multi-playable event is revived. 10 shows an example of a screen displaying a list of revivable events that have been cleared by other users. 10 is a flowchart illustrating an example of a process related to revival of a revivable event. 10 is a flowchart showing an example of processing related to revival of an event that allows multiplay.

Embodiments of the present invention will be described below with reference to the drawings.

<System hardware configuration>
As shown in FIG. 1, an information processing system 1 of this embodiment includes a plurality of terminal devices 10 and a server 20 .

The terminal device 10 and the server 20 are connected via a network 2. The network 2 may be configured, for example, by the Internet, a mobile communication system (e.g., 3G, 4G, 5G, LTE (Long Term Evolution), etc.), Wi-Fi (Wireless Fidelity), Bluetooth (registered trademark), other communication lines, or a combination of these. Furthermore, the connection between the terminal device 10 and the server 20 may be wired or wireless.

The server 20 (in other words, a computer, an information processing device) may be, for example, a general-purpose computer such as a workstation or a personal computer. The server 20 comprises a processor 21, memory 22, storage 23, a communication IF (interface) 24, and an input/output IF 25. These components of the server 20 are connected to each other by a communication bus.

The processor 21 controls the overall operation of the server 20. The processor 21 may include a CPU (Central Processing Unit), an MPU (Micro Processing Unit), a GPU (Graphics Processing Unit), etc. The processor 21 reads programs from the storage 23 and loads them into the memory 22. The processor 21 executes the loaded programs.

Memory 22 is the main storage device. Memory 22 is composed of storage devices such as ROM (Read Only Memory) and RAM (Random Access Memory). Memory 22 provides a working area for processor 21 by temporarily storing programs and various data that processor 21 reads from storage 23. Memory 22 also temporarily stores various data generated while processor 21 is operating according to the programs.

In this embodiment, the program may be a program that realizes a game by the terminal device 10. The program may also be a program that realizes the game through cooperation between the terminal device 10 and the server 20. The game realized through cooperation between the terminal device 10 and the server 20 may, for example, be a game executed on a browser launched on the terminal device 10. The program may also be a program that realizes the game through cooperation between multiple terminal devices 10. The various data may include, for example, game-related data such as user information and game information, as well as instructions and notifications sent and received between the terminal device 10 and the server 20.

Storage 23 is an auxiliary storage device. Storage 23 is composed of a storage device such as flash memory or an HDD (Hard Disk Drive). Various data related to the game is stored in storage 23.

The communication IF 24 controls the sending and receiving of various data between the server 20 and the terminal device 10, etc. via the network.

The input/output IF 25 is an interface through which the server 20 accepts data input, and also an interface through which the server 20 outputs data. The input/output IF 25 may include, for example, an input unit which is an information input device such as a mouse or keyboard, and a display unit which is a device that displays and outputs images.

The terminal device 10 (in other words, a computer or information processing device) may be, for example, a smartphone, feature phone, PDA (Personal Digital Assistant), tablet computer, personal computer, wearable device, or game device. The terminal device 10 may also be a mobile terminal. The terminal device 10 may also be a portable terminal that the user uses when playing a game.

The terminal device 10 includes a processor 11, memory 12, storage 13, a communication IF 14, an input/output IF 15, an input unit 17, and a display unit 18. These components of the terminal device 10 are connected to each other via a communication bus.

The processor 11 controls the overall operation of the terminal device 10. The processor 11 may include a CPU, an MPU, a GPU, etc. The processor 11 reads a program from the storage 13 and loads it into the memory 12. The processor 11 executes the loaded program.

Memory 12 is a main storage device. Memory 12 is composed of storage devices such as ROM and RAM. Memory 12 provides a working area for processor 11 by temporarily storing programs and various data that processor 11 reads from storage 13. Memory 12 also temporarily stores various data generated while processor 11 is operating according to a program.

Storage 13 is an auxiliary storage device. Storage 13 is composed of a storage device such as flash memory or an HDD. Various data related to the game is stored in storage 13.

The communication IF 14 controls the sending and receiving of various data between the terminal device 10 and the server 20, etc. via the network.

The input/output IF 15 is an interface through which the terminal device 10 accepts data input and outputs data. The input/output IF 15 may input and output data via, for example, a USB (Universal Serial Bus). The input/output IF 15 may include an input unit 17 or a display unit 18.

The input unit 17 accepts input from the user. The input unit 17 may be, for example, a pointing device such as a touchpad. The display unit 18 displays images. The display unit 18 may be, for example, a liquid crystal display or an organic EL (Electro-Luminescence) display. The terminal device 10 is equipped with, for example, a touch screen 16, which is an electronic component that combines the input unit 17 and the display unit 18.

The input unit 17 has the function of detecting a position input on the input surface by a user operation (e.g., touch operation, tap operation, slide operation, swipe operation, flick operation, etc.) and transmitting information indicating the detected position as an input signal. The touch panel used as the input unit 17 can be of a capacitive type or a resistive type, but other types are also possible.

The input unit 17 may be, for example, a keyboard, various physical buttons, various sensors (for example, an acceleration sensor, angular velocity sensor, magnetic sensor, GPS sensor, motion sensor, gaze sensor, bioelectric potential sensor, fingerprint sensor, breath sensor, pressure sensor, or image sensor), a control stick, a camera, or a microphone. The display unit 18 may be, for example, a projector.

<System functional configuration>
2 is a block diagram showing the functional configuration of the server 20 and the terminal devices 10. The server 20 in this embodiment has functions such as providing each terminal device 10 with various data and programs necessary to realize the game, collecting and managing data related to the game from each terminal device 10, and performing synchronization processing between multiple terminal devices 10.

In this embodiment, the server 20 identifies each user and terminal device 10 using a user account that is registered in advance. The method of registering an account is not particularly limited. For example, the terminal device 10 or another device such as a personal computer may transmit information required for user account registration to the server 20 based on a user operation, and the server 20 may then create and save an account for each user based on the received information.

As shown in FIG. 2, the server 20 functions as a control unit 210 and a memory unit 220 through cooperation of a processor 21, memory 22, storage 23, communication IF 24, input/output IF 25, etc. The memory unit 220 stores various data used by the control unit 210. Examples of the various data include game programs, game information, and user information.

A game program is a program for realizing a game. Game information and user information are data that the control unit 210 references when executing a game program.

In this embodiment, the game program may include a game program executed on the terminal device 10 in addition to a game program executed on the server 20. Furthermore, the storage unit 220 may store a game program executed on the server 20 and a game program executed on the terminal device 10.

Game information is information common between accounts. Game information includes, for example, information for defining various virtual spaces. A virtual space is a space in which various objects, such as objects of characters (hereinafter referred to as "player characters") used by users (in other words, characters controllable by users), are placed. Game information includes, for example, various setting information related to objects common between accounts, such as background objects such as buildings, trees, and stones placed in the virtual space, and the placement position, size, color, and shape of non-player character (NPC) objects. Game information also includes, for example, setting values for various NPC parameters. Hereinafter, character objects placed in a virtual space may be referred to simply as "characters."

User information is information managed for each game account. User information includes, for example, information about the player character, information about owned assets, and information indicating the progress of the game. Owned assets can be considered value possessed by the user within the virtual space. Examples of such value (in-game value, owned assets) include electronic currency, items, and characters. Examples of electronic currency include in-game currency that can be used within the game and crypto assets.

The control unit 210 controls various game-related processes by executing a game program stored in the memory unit 220. The control unit 210 includes, for example, a transmission/reception unit 211 and a game control unit 212.

The transmission/reception unit 211 transmits and receives various types of data. For example, the transmission/reception unit 211 receives requests to transmit various types of data and programs, requests for synchronization processing to support multiplayer functions, data to be synchronized, etc. from each terminal device 10, and passes them to the game control unit 212. The transmission/reception unit 211 also transmits various types of data and programs, including instructions for achieving synchronization, to each terminal device 10 in accordance with the control of the game control unit 212.

In this embodiment, the multiplay function is a function that allows game processing by multiple accounts to proceed in a synchronized state. The server 20 and terminal device 10 of the information processing system 1 perform various processes to support the multiplay function when multiple accounts logged in to the information processing system 1 participate in the same game.

The game control unit 212 provides a game to the terminal device 10 by executing calculations described in the game program in response to requests from the terminal device 10.

The game control unit 212 defines the virtual space based on information for defining the virtual space included in the game information. The game control unit 212 places objects in the virtual space based on object setting information included in the game information. The game control unit 212 also controls the objects in the virtual space. Specifically, the game control unit 212 changes the position, orientation, shape, color, etc. of the objects within the virtual space, and causes the objects to perform predetermined actions.

The game control unit 212 also places the player character in the virtual space based on information transmitted from the terminal device 10. The game control unit 212 also performs various determination processes related to the progress of the game based on information transmitted from the terminal device 10. In other words, the game control unit 212 controls objects and performs various determination processes based on information input by the user to the terminal device 10.

Furthermore, when the game control unit 212 receives, for example, a request for synchronization processing to support the multiplayer function or data to be subject to synchronization processing from the terminal device 10 via the transmission/reception unit 211, it executes synchronization processing to support the multiplayer function. The game control unit 212 also issues a command to the transmission/reception unit 211 to instruct the transmission of game information or user information. For example, when the server 20 sends information to multiple terminal devices 10, the game control unit 212 synchronizes the game progressing between the terminal devices 10 by simultaneously sending the information to each terminal device 10. By executing synchronization processing, it becomes possible for in-game events resulting from operations input on one terminal device 10 to be reflected simultaneously on the other terminal devices 10.

In this embodiment, the terminal device 10 has, for example, a function as an input device that accepts user input operations, and a function as an output device that outputs game images and sounds.

The terminal device 10 functions as a control unit 110 and a storage unit 120 through cooperation between the processor 11, memory 12, storage 13, communication IF 14, input/output IF 15, etc. The storage unit 120 stores various data used by the control unit 110. Examples of the various data include a game program, game information, and user information. The game program is a program for realizing a game on the terminal device 10 side. The game information and user information are data referenced by the control unit 110 when executing the game program. The game information and user information stored in the storage unit 120 may include information similar to the game information and user information stored in the storage unit 220.

The control unit 110 controls various processes related to the game executed on the terminal device 10 by executing a game program stored in the memory unit 120. The control unit 110 includes, for example, an operation reception unit 111, a transmission/reception unit 112, a game control unit 113, a display control unit 114, and a location information acquisition unit 116.

The operation reception unit 111 receives operations (hereinafter also referred to as "input operations") input by the user via the input unit 17. Specifically, when an input operation is performed on the input unit 17, the operation reception unit 111 detects the coordinates of the input position and the type of input operation. Examples of types of input operations include various operations performed with fingers, etc., such as touch operations, tap operations, slide operations, swipe operations, flick operations, pinch-in operations, and pinch-out operations. Input operations are not limited to operations that involve physical contact with the input unit 17 (e.g., the touch screen 16), but may also include non-contact operations. Note that an operation that ends a previously performed input operation, such as a touch-off operation that ends contact with the touch screen 16, can also be considered a form of input operation.

Here, the operation reception unit 111 can also accept input operations performed using an operating device connected via the input/output IF 15 in the same way as input operations performed on the input unit 17.

In this embodiment, changing the position information (described below) by the user moving in real space can also be considered a form of input operation.

The transmission/reception unit 112 transmits and receives various data. For example, the transmission/reception unit 112 transmits game information or user information, and synchronization requests to support the multi-play function to the server 20. The transmission/reception unit 112 receives various data, programs, and synchronization data to support the multi-play function from the server 20. The synchronization data includes, for example, synchronization instruction data that instructs each terminal device 10 participating in multi-play to synchronize. The synchronization instruction data includes, for example, the data to be synchronized, the type of data, and data to specify the time to synchronize.

The transmitter/receiver unit 112 also transmits to the server 20 operation information relating to input operations accepted by the operation acceptance unit 111, as well as information from the user, such as location information, which will be described later.

The game control unit 113 executes various processes related to the progress of the game. The game control unit 113 identifies the user's instructions based on the user's input operations detected by the operation reception unit 111. The game control unit 113 also executes various determination processes related to the progress of the game based on the identified instructions, etc. The game control unit 113 also progresses the game while communicating with the server 20 based on the results of the determination processes, etc.

The game control unit 113 defines a virtual camera for specifying an area of the virtual space to be presented to the user. The game control unit 113 places the virtual camera within the virtual space by defining its position and orientation within the virtual space. The game control unit 113 instructs the display control unit 114 to generate an image depicting the field of view defined by the virtual camera and the objects located in this field of view. In other words, the game control unit 113 instructs the display control unit 114 to display an image on the display unit 18 that corresponds to the progress of the game.

The position and orientation of the virtual camera can be determined appropriately for each virtual space. For example, the game control unit 113 uses the position and orientation of a specific object as a reference and positions the virtual camera so that the specific object is located in the center of the field of view in a specific orientation. In doing so, the game control unit 113 adjusts the position and orientation of the virtual camera using the direction, distance, and angle relative to the specific object. The specific object may be, for example, a dynamic object, or a static object such as a building, tree, or stone. Examples of dynamic objects include the player character and an NPC that operates based on the game program. NPCs include so-called enemy characters, etc.

The display control unit 114 displays images related to the game on the display unit 18. Specific examples are explained below.

The display control unit 114 generates an image depicting the area of the virtual space within the field of view of the virtual camera defined by the game control unit 113 and the objects present in that area, and displays this image on the display unit 18. The display control unit 114 can superimpose and draw objects related to the UI (User Interface) required for various game operations, such as icons, buttons, and menus showing various parameters, on the image displayed on the display unit 18.

The control unit 110 of the terminal device 10 may place objects in the virtual space based on object data sent from the server 20 and information indicating the positions of various objects in the virtual space, and display a predetermined area of the virtual space on the display unit 18. The control unit 210 of the server 20 may also place objects in the virtual space and control the virtual camera, generate an image to be displayed on the display unit 18, and send it to the terminal device 10, and the control unit 110 of the terminal device 10 may display the image on the display unit 18. In other words, various processes related to control of objects based on information from the user, control of the virtual camera, and generation of images to be displayed on the display unit 18 may be performed by either the server 20 or the terminal device 10.

The location information acquisition unit 116 acquires location information indicating the user's location in real space (in other words, the user's current location). The location information may indicate the user's location in real space as identified by an account or the like. Various methods for acquiring location information have been known, and any known method may be used. For example, the location information acquisition unit 116 may acquire location information using a GPS sensor provided in the terminal device 10 on which the user is logged in to their account. Furthermore, the location information acquisition unit 116 may acquire location information acquired by a device used by the user, such as various devices (e.g., smart devices) that link with the terminal device 10 (e.g., a smartphone) (e.g., link via the user's account or link via wireless communication), as location information indicating the location of the user logged in to their account from the terminal device 10. Furthermore, the location information acquisition unit 116 may acquire location information using, for example, Wi-Fi or Bluetooth (e.g., based on communication between the terminal device 10 and a Wi-Fi access point). Additionally, the location information acquisition unit 116 may be provided, for example, in the control unit 210 of the server 20.

Note that the functions of the terminal device 10 and server 20 shown in FIG. 2 are merely examples. Each device, such as the terminal device 10 and server 20, may have at least some of the functions of the other devices. Furthermore, each device, such as the terminal device 10 and server 20, does not have to be realized by a single device, but may be realized, for example, by multiple devices connected via a network. Furthermore, the information processing system 1 may be composed of, for example, only the terminal device 10 or the server 20. In other words, the information processing system 1 does not have to be realized by multiple devices connected via a network.

<Processing according to this embodiment>
Next, the processing according to this embodiment will be described. Note that in this embodiment, the processor 11 of the terminal device 10 or the processor 21 of the server 20 will be described as performing each processing according to this embodiment by executing a game program stored in the information processing system 1. However, at least a portion of the processing according to this embodiment performed by the processor 11 may be performed by a processor other than the processor 11. Furthermore, at least a portion of the processing according to this embodiment performed by the processor 21 may be performed by a processor other than the processor 21. For example, some or all of the processing performed by one of the game control unit 113 and the game control unit 212 may be performed by the other. In other words, the computer that executes the game program in this embodiment may be either the terminal device 10 or the server 20, or may be realized by a combination of multiple devices.

The configuration according to this embodiment can be applied, for example, to location-based games that link a user's position in real space with their position in virtual space. The following describes an example in which the configuration according to this embodiment is applied to such a location-based game.

As shown in FIG. 3, the game control unit 212 places the player character 30 corresponding to the user operating the terminal device 10 at a position in the virtual space that corresponds to the user's position in real space (in other words, the position indicated by the position information). The game control unit 212 then moves the player character 30 in the virtual space in conjunction with the user's movement in real space.

In other words, in this embodiment, the game control unit 212 moves the user's player character 30 in the virtual space based on the user's position information as information from the user. Note that the game control unit 212 may also move the user's player character 30 in the virtual space based on operation information from the user regarding an input operation on the input unit 17 (for example, an operation of moving a finger in any direction while touching the touch screen 16 (i.e., a swipe operation)).

The virtual space of this embodiment is a virtual space that reflects at least a portion of the real space. In other words, the virtual space of this embodiment is a virtual space that is generated using map information of the real space. For example, in the virtual space of this embodiment, objects corresponding to roads that actually exist in the real space (e.g., road object 31) are placed at positions that correspond to the positions of the roads in the real space.

In games such as location-based games, multiple objects (hereinafter referred to as "event objects 33") associated with specific events (in other words, effects or phenomena) are placed in a virtual space, and it is known that by approaching an event object 33 (for example, by approaching and then performing an operation (e.g., a touch operation) on the event object 33 displayed on the display unit 18), an event corresponding to the specific event object 33 occurs. Here, in location-based games, approaching a specific event object 33 placed in a virtual space can be interpreted as approaching the specific event object 33 in the virtual space, or as visiting a location in real space that corresponds to the location in virtual space where the specific event object 33 is placed (in other words, approaching the specific event object 33 in real space). When an event object 33 for which a specific event occurs is placed in a virtual space, the game control unit 212 generates a specific event corresponding to the event object 33 based on the user visiting a location in real space that corresponds to the location in virtual space where the event object 33 is placed. The location in the virtual space where the event object 33 is placed can also be considered the location where a specific event is set.

The event objects 33 include, for example, item spots 33a corresponding to events such as obtaining an item and recovery spots 33b corresponding to events such as recovering a predetermined parameter related to the user (e.g., the player character's 30's stamina). The event objects 33 also include enemy objects 33c corresponding to events such as fighting an enemy character and spots corresponding to events that form part of the game's story. The game control unit 212 grants the user an item corresponding to a specific item spot 33a based on the user visiting a location in real space that corresponds to the virtual space location where the specific item spot 33a is located. The game control unit 212 also restores a predetermined parameter related to the user (in other words, brings the predetermined parameter closer to a specified value) based on the user visiting a location in real space that corresponds to the virtual space location where the specific recovery spot 33b is set. The game control unit 212 also initiates a battle with a specific enemy character based on the user visiting a location in real space that corresponds to the virtual space location where the enemy object 33c related to the specific enemy character is located. The event associated with the event object 33 may be an event that can be progressed through multiplayer (in other words, played by at least two or more people). In other words, approaching an event object 33 corresponding to an event that can be progressed through multiplayer may initiate an event that is progressed through multiplayer (for example, an event in which users cooperate with other users to fight enemy characters (a so-called raid battle)). The appearance of the event object 33 is not particularly limited and may be the shape of an item, a building, a character, or a predetermined symbol. The event associated with the event object 33 may be one that progresses and ends automatically without user operation, or one that progresses through user operation (for example, one that progresses by operating the player character 30, etc.).

In this embodiment, user operations (e.g., touch operations) on event objects 33 located within a predetermined range (in other words, an operable range, hereinafter referred to as the "usable range X") from the player character 30 in virtual space are valid. The game control unit 212 enables the user to move the player character 30 so that the event object 33 for which the user wants to generate a corresponding event (in other words, the event object 33 the user wants to use) is located within the usable range X, and when the user performs an operation on the event object 33, an event corresponding to the operated event object 33 occurs. In other words, in this embodiment, an event corresponding to a specific event object 33 can occur when the user visits a location in real space that corresponds to the location of a specific event object 33 in virtual space (specifically, by visiting the location and performing a predetermined operation (e.g., a touch operation on the specific event object 33)). In other words, the user can use event objects 33 located within the usable range X. In other words, the game control unit 212 determines whether the event object 33 is located within the usable range X, and controls the event object 33 located within the usable range X so that it can be used. Note that "usable" here means that it is possible to cause the event set in the event object to occur, etc.

The usable range X may be, for example, a circular range of a predetermined size centered on the player character 30 (in other words, the user's position). Note that the shape of the usable range X is not limited to a circle, nor is it limited to a range centered on the player character 30. The usable range X can also be said to be the range available to the user in the virtual space (in other words, in the entire virtual space). The usable range X is determined according to the user's position in real space (in other words, based on the user's position information), and fluctuates according to the user's position in real space. The display control unit 114 displays a display indicating the usable range X (a circle in Figure 3) on the display unit 18, making the usable range X recognizable to the user.

In this embodiment, the player character 30 is placed in a position in virtual space corresponding to the user's position in real space and displayed on the display unit 18; however, a configuration in which the player character 30 is not placed in that position in virtual space (in other words, a configuration in which the player character 30 is not displayed on the screen, etc., illustrated in FIG. 3) may also be adopted. Even in such a configuration, a configuration in which an event corresponding to an event object 33 located within a usable range X determined according to the user's position in real space is generated based on the user's operation on the event object 33. Similarly, even in a game that can be progressed in first-person display, such as a game in which the player character 30 can be switched from third-person display, in which the player character 30 is displayed, to first-person display, in which the player character 30 is barely displayed, a usable range X in which operation is possible may be set for each person.

The game control unit 212 may be capable of switching between two game progression modes based on a user's operation: a manual mode in which a corresponding event is generated when a user approaches an event object 33 and performs an operation (e.g., a touch operation) on the event object 33; and an automatic mode in which an event corresponding to the approached event object 33 is automatically generated (in other words, without the need for a touch operation, etc.) when the user approaches the event object 33. That is, in automatic mode, the game control unit 212 may automatically generate an event corresponding to a specific event object 33 when the specific event object 33 is located within the usable range X. Regardless of whether the game is set to manual mode or automatic mode, some event objects 33 may automatically generate an event corresponding to the event object 33 when the user approaches them (in other words, when the event object 33 is located within the usable range X). Even when the game is set to automatic mode, an event may be generated based on an operation (e.g., a touch operation) on the event object 33. Switching between manual mode and automatic mode may be performed automatically based on the fulfillment of a predetermined condition (e.g., triggered by the start of a predetermined event, etc.).

In games in which real space and virtual space are associated, such as location-based games, each point in real space corresponds to each point in virtual space. In other words, the correspondence between each point in real space and each point in virtual space is stored in the storage unit 220. Therefore, making a predetermined setting for a specific point in virtual space can also be said to be making a predetermined setting for a specific point in real space. Making a predetermined setting for a specific point in real space can also be said to be making a predetermined setting for a specific point in virtual space. That is, for example, placing a specific event object 33 at a specific point in virtual space can also be said to be placing the event object 33 at the corresponding specific point in real space. Also, for example, setting a specific range in virtual space as a range related to predetermined control can also be said to be setting a specific range in the corresponding real space as a range related to predetermined control. Note that this setting may be performed by the game operator or the user.

(Event revival)
In the game of this embodiment, the game control unit 212 performs control to make a specific event associated with a specific event object 33 replayable after the user clears the specific event. Specifically, after the user clears the specific event associated with a specific event object 33, the game control unit 212 performs control to make the specific event replayable in response to the user's payment of a fee. The specific event object 33 may be an enemy object 33c associated with a specific event, such as a battle with a specific enemy character. The specific event object 33 may also be an object other than the enemy object 33c, and the specific event does not have to be an event involving a battle with an enemy character. Note that making the specific event replayable can also be considered as reviving the specific event. Hereinafter, the specific event will be referred to as a "revivable event," and the event object 33 associated with the reviveable event will be referred to as a "special object 33d."

A reviveable event can also be considered an event associated with a specific location in real space. Information indicating the real space location with which the reviveable event is associated (in other words, the location of the special object 33d) is stored in the memory unit 220, and the game control unit 212 can identify the real space location with which the reviveable event is associated based on this information. Note that the real space location with which the reviveable event is associated does not have to be the location where the event object 33 is located.

An example of the process by which a revivable event is cleared and revived is explained with reference to Figure 4.

The game control unit 212 starts a reviveable event when the user moves in real space and visits a location where the special object 33d is located within the usable range X (in other words, a location where a reviveable event is set) (see FIG. 4(a)). Specifically, the game control unit 212 starts a reviveable event when the user performs an operation on the special object 33d while the special object 33d is located within the usable range X. In other words, the game control unit 212 starts a reviveable event associated with a specific position in real space when the user approaches within a predetermined range of the specific position.

The game control unit 212 may be capable of starting a reviveable event associated with a specific special object 33d based on a predetermined operation by the user after the user visits a location where a specific special object 33d is located within the usable range X and then moves to a location outside the usable range X. Specifically, the user may be able to reserve a reviveable event associated with a specific location in real space as an event to be played later by visiting a location corresponding to the specific location and performing a predetermined operation. For example, the game control unit 212 may register the reviveable event corresponding to the special object 33d in the storage unit 220 as an event reserved by the user (in other words, an event that can be played later) based on a predetermined operation by the user (e.g., an operation on the special object 33d) while the special object 33d is located within the usable range X. The game control unit 212 then starts the event reserved by the user based on a predetermined operation by the user (e.g., an operation to select an event to start playing on a screen displaying a list of reserved events). A fee may be required for reserving an event. In this embodiment, "compensation" is not particularly limited and may include various types of compensation described below, but may be, for example, a specified item, in-game currency, specified points, or a specified parameter related to the user (for example, the stamina of the player character 30). If compensation is required, the game control unit 212 may reduce the value owned by the user by the amount of the compensation when reserving the event (in other words, registering it as an event that can be played later) (for example, it may reduce the value of a specified item owned by the user by "1").

The game control unit 212 also progresses the initiated reviveable event based on a predetermined operation by the user (see FIG. 4(b)). The method of progressing the event is not particularly limited and can be similar to that of conventional games. For example, the game control unit 212 may move the player character 30 based on an input operation by the user (e.g., a swipe operation, a tap operation, or an operation on a predetermined UI displayed on the display unit 18) while the reviveable event is in progress. Specifically, the game control unit 212 may cause the player character 30 to attack an enemy character 36 or move the player character 30 within a virtual space based on the input operation by the user. In other words, while there are various conventional games in which the player character 30 and the enemy character 36 fight each other, the reviveable event may be an event in which the player character 30 is controlled to fight the enemy character 36, as in known games. However, the reviveable event does not have to be an event that is progressed by controlling the player character 30. As an example, a reviveable event may be an event that progresses by operating an object other than the player character 30, such as in a puzzle game. Note that a reviveable event may also progress automatically without user operation.

In addition, a clearing condition is set for each revivable event. When the set clearing condition is met, the game control unit 212 determines that the revivable event has been cleared and ends the revivable event (see FIG. 4(c)). The clearing condition may be, for example, defeating a specific opponent, obtaining a specific objective, or reaching a specific destination. In other words, a revivable event may be set with an opponent to be defeated, an objective to be obtained, or a destination to be reached. Note that the "opponent" here may be an enemy character (in other words, an NPC) or another user. Note that the "destination" here may be, for example, a location in virtual space to which the player character 30 should be reached, or a location in real space to which the user should be moved in real space. Note that when the player character 30 moves in a revivable event according to the user's position information, the destination may be a location in virtual space to which the player character 30 should be reached, or a location in real space to which the user should be moved in real space.

The game control unit 212 also grants a reward to a user who clears a reviveable event. The reward is not particularly limited, but may be, for example, a specified item, in-game currency, or specified points. Note that "granting (or, allowing) the user to acquire" a reward can also be interpreted as linking the reward item to the user's account as an item owned by the user and storing it in a specified memory unit (e.g., memory unit 220).

Furthermore, when a reviveable event is cleared, the game control unit 212 instructs the terminal device 10 to display a result screen 50 that displays the results of the cleared reviveable event. Based on this instruction, the display control unit 114 of the terminal device 10 causes the display unit 18 to display the result screen 50 (see FIG. 4(d)). The result screen 50 may display an evaluation of the user's play in the cleared reviveable event, the time required to clear it, etc. The result screen 50 may also display the reward awarded to the user for clearing it.

Furthermore, after a reviveable event is cleared, the control unit 110 of the user's terminal device 10 accepts an operation (hereinafter referred to as a "revival operation") by the user to revive the reviveable event (in other words, to make it playable again). The game control unit 212 revives the reviveable event based on the revival operation.

The game control unit 212 also requests a fee from the user for reviving a revival-enabled event. In this embodiment, a revival item is provided as an item for reviving a revival-enabled event. When a revival operation is performed, the game control unit 212 has the user pay the revival fee and revives the revival-enabled event. Specifically, the game control unit 212 revives the revival-enabled event and reduces the value of the user's possession by the fee (e.g., reducing the revival item owned by the user by "1"). In other words, when a revival-enabled event is revived, the game control unit 212 may execute control to reduce a predetermined item, in-game currency, or predetermined points owned by the user, or a predetermined parameter associated with the user, etc., in order to have the user pay a fee. In other words, in this embodiment, "payment" includes consuming (or, in other words, reducing) something owned by the user (e.g., a predetermined item, in-game currency, or predetermined points, or a predetermined parameter associated with the user, etc.) in exchange for some control (e.g., revival of the revival-enabled event). Also, "compensation" can be something consumed in exchange for some control in this way.

Furthermore, when a revival operation is received, the control unit 110 of the terminal device 10 provides the user with guidance regarding the revival of a revivable event. For example, the control unit 110 causes the display unit 18 to display a guidance display 60 providing guidance regarding revival in a situation where the revival of a revivable event is possible. The guidance regarding revival can also be thought of as a notification that the revival of a revivable event is possible. The notification need only allow the user to recognize that a cleared revivable event can be revived.

In this embodiment, as shown in Figures 4 and 5, the guidance display 60 displays the text "Revive the event" or "Would you like to revive the event?" to inform the user that a reviveable event is possible. The guidance display 60 can also be considered a display that confirms whether or not to revive the reviveable event.

The guidance display 60 may also include an indication of the payment required to revive a reviveable event. The payment indication may be, for example, an indication of the content of the payment (e.g., what is required as payment or the amount of payment required), or an indication of the amount of payment the user possesses (e.g., the number of revival items possessed). In other words, the provision of information regarding the payment provides guidance regarding the payment required to revive a reviveable event.

The guidance display 60 may be displayed on the result screen 50, as shown in FIG. 4(d). In other words, the control unit 110 may display the result screen 50 when a reviveable event is cleared, and may provide the user with guidance on the result screen 50 regarding the revival of the cleared reviveable event. In other words, when a reviveable event is cleared (in other words, at the time the reviveable event is cleared), the control unit 110 may provide the user who cleared the reviveable event with guidance on making the cleared reviveable event playable again. In other words, the guidance regarding the revival of the reviveable event may be displayed when the reviveable event is cleared. Note that this guidance when a reviveable event is cleared may be displayed simultaneously with the display of the result screen 50 (in other words, within the result screen 50), or may be displayed after or before the display of the result screen 50. In other words, the guidance display 60 may be displayed after the display of the result screen 50 has finished.

Furthermore, the notification regarding the revival of a reviveable event may be provided at a predetermined time other than when the reviveable event is cleared, in addition to or instead of when the reviveable event is cleared. For example, as shown in FIG. 5, the control unit 110 may display a guidance display 60 on a predetermined play screen while the user is playing the game. For example, as shown in FIG. 5(a), the predetermined play screen may be a screen (hereinafter referred to as a "field screen 52") that displays the player character 30 moving in virtual space in accordance with the user's movement in real space (in other words, changes in position information). The control unit 110 may display the guidance display 60 in a predetermined area of the field screen 52. In other words, the control unit 110 may notify the user that the reviveable event can be revived while the user is moving the player character 30 to play the game. For example, the predetermined play screen may be a screen that displays a map 54 of the virtual space, as shown in FIG. 5(b). The map 54 can be considered a map that displays a wider area of the virtual space than the area displayed on the field screen 52. The map 54 may display the user's current location 55, the usable range X, and other information. The control unit 110 may also display a guidance display 60 in a predetermined area of the screen displaying the map 54.

When a user receives a notification about the revival of a revival-enabled event and performs a predetermined operation in response to the notification, the revival-enabled event is revived. For example, the control unit 110 may display a revival button 62 as a UI for accepting a revival operation and a reject button 63 as a UI for accepting an operation to reject the revival, along with a notification display 60, on the result screen 50 or a predetermined play screen. Note that the notification display 60 may also serve as these UIs. The control unit 110 may then accept an operation on the revival button 62 as a revival operation (in other words, a predetermined operation in response to the notification), and the game control unit 212 may revive the revival-enabled event based on the revival operation. In other words, when a revival-enabled event is cleared (in other words, at the time the revival-enabled event is cleared), the control unit 110 accepts an operation by the user who cleared the revival-enabled event to make the cleared revival-enabled event playable again. The control unit 110 may also accept an operation on the reject button 63 as an operation to reject the revival, and remove the revival display 60 from the screen based on that operation. If an operation to reject revival is performed, the game control unit 212 will not revive the revivable event.

Furthermore, as shown in FIG. 5(a), the control unit 110 may cause the display unit 18 to display a revival button 62 based on an operation on the guidance display 60 (for example, a touch operation on the guidance display 60 that reads "Would you like to revive the event?" displayed on a specific play screen). That is, the control unit 110 may accept an operation on the guidance display 60 and an operation on the revival button 62 as a revival operation. In other words, in a situation where a user is playing a game by moving the player character 30, the control unit 110 may accept an operation by a user who has cleared a revival-enabled event to make the cleared revival-enabled event playable again.

Note that the control unit 110 may be capable of displaying a list 65 of cleared resurrectable events on the display unit 18, as shown in FIG. 6. For example, the control unit 110 may display a list 65 of resurrectable events cleared by the user on the display unit 18 based on a predetermined operation by the user (e.g., an operation on a predetermined icon displayed on a predetermined play screen). When the user clears a resurrectable event, the game control unit 212 adds the cleared resurrectable event to the resurrectable events to be displayed in the list 65 (in other words, registers the cleared event in the memory unit 220 as a resurrectable event to be displayed in the list 65). The control unit 110 also accepts, as a resurrection operation, a user operation to select a specific resurrectable event from the multiple resurrectable events displayed in the list 65. The list 65 can also be considered a list of currently resurrectable events. The list 65 includes multiple resurrectable events that the user has cleared in the past (e.g., within a predetermined period of time). In this way, when it is possible to revive multiple reviveable events that have been cleared in the past, the guidance display 60 displayed on the specified play screen may provide guidance about reviving the last (in other words, most recently) cleared reviveable event.

A resurrectable event that is resurrected by a resurrection operation may be started immediately, or may be started based on a predetermined operation by the user after the resurrection. That is, for example, a resurrection operation (e.g., an operation on the resurrection button 62) may be accepted as an operation for starting a resurrectionable event, and the game control unit 212 may start the resurrectionable event based on the resurrection operation. Furthermore, for example, the game control unit 212 may erase a special object 33d whose corresponding resurrectionable event has been cleared from the virtual space and cause the erased special object 33d to reappear based on the resurrection operation. The game control unit 212 may then start the resurrectionable event based on an operation on the reappeared special object 33d. For example, the game control unit 212 may start the resurrectionable event based on the user moving in real space and visiting a location where the reappeared special object 33d is located within the usable range X (in other words, a location where the resurrectionable event is set). That is, when a reviveable event is revived and played again, the game control unit 212 may start the reviveable event on the condition that the special object 33d corresponding to the revived reviveable event is located within the usable range X. Furthermore, for example, the terminal device 10 may be capable of displaying a list of reviveable events that have been revived. The game control unit 212 may then add the revived reviveable event to the reviveable events to be displayed in the list (in other words, the game control unit 212 may register the revived reviveable event in the storage unit 220 as a reviveable event to be displayed in the list). The control unit 110 of the terminal device 10 may then accept a user operation to select a specific reviveable event from among the multiple reviveable events displayed in the list as an operation to start the selected reviveable event. The game control unit 212 may then start the selected reviveable event based on the operation. That is, in this embodiment, the game control unit 212 performs control to make the target reviveable event playable again based on the revival operation, but this control may, for example, be control to start the target reviveable event based on the revival operation, control to make a special object 33d related to the target reviveable event appear based on the revival operation, or control to add the target reviveable event to a predetermined list (for example, a list from which the user can select an event to start playing) based on the revival operation.

Note that a reviveable event associated with a specific position in real space may be an event that revives naturally after a predetermined period of time has passed if the user does not perform a revive operation. That is, when a specific reviveable event associated with a special object 33d placed at a specific position is cleared, the game control unit 212 may erase the special object 33d from the virtual space, and then, after a predetermined period of time has passed, relocate the special object 33d at the specific position (or a different position). In this case, the user can replay the specific reviveable event associated with the special object 33d by approaching the relocated special object 33d after the predetermined period of time has passed. In this configuration, the control that revives a reviveable event in response to payment of a fee can also be considered control that shortens (e.g., reduces to zero) the time until the reviveable event is revived.

The game control unit 212 may vary the conditions for making a specific reviveable event playable again depending on the relationship between the user's current location indicated by the location information indicating the user's location in real space and the real-space location associated with the specific reviveable event (for example, the location where the special object 33d related to the specific reviveable event is located; in other words, the location where the reviveable event is set).

For example, the game control unit 212 may vary the price for revival in a reviveable event depending on the relationship between the user's current location and the location where the reviveable event is set. For example, the game control unit 212 may increase the price for revival the farther the distance between the user's current location and the location where the reviveable event is set. In other words, the game control unit 212 may decrease the price for revival the closer the distance between the user's current location and the location where the reviveable event is set. Here, "high price" includes cases where the amount of price (for example, the number of revival items consumed) is large, or where a more valuable item is required as price, etc.

That is, for example, the game control unit 212 determines the price for reviving a reviveable event based on the relationship between the user's current location and the location where the reviveable event is set. Furthermore, the control unit 110 of the terminal device 10 provides the user with information about the price based on this determination. Specifically, if the price is higher than usual (in other words, higher than the standard), the control unit 110 may notify the user that the price is higher than usual. In the example shown in FIG. 7, the text "Because the event to revive is far away, you will need twice as many items as usual" notifies the user that the price has changed (specifically, that it is higher than usual) and the reason for this.

The game control unit 212 may also change whether or not a reviveable event can be revived depending on the relationship between the user's current location and the location where the reviveable event is set. For example, the game control unit 212 may restrict the revival of a reviveable event (in other words, make revival impossible) when the distance between the user's current location and the location where the revivalable event is set is greater than a predetermined distance. Furthermore, if the game control unit 212 has restricted the revival of a reviveable event because the distance between the user's current location and the location where the revivalable event is set is greater than a predetermined distance, the game control unit 212 may lift the restriction on the revival of the revivalable event (in other words, make revival possible) when the distance between the user's current location and the location where the revivalable event is set becomes less than the predetermined distance.

When revival of a reviveable event is restricted, the control unit 110 of the terminal device 10 may notify the user how to remove the revival restriction. For example, in the example shown in FIG. 8 , the user is notified of the removal method using the text "Please approach an area where revival is possible." Furthermore, when revival of a reviveable event is restricted, the control unit 110 may display a display on the display unit 18 to assist in removing the restriction. The display to assist in removing the restriction may notify the user of at least one of the location to which the user should go (in other words, the location associated with the reviveable event that is the target of revival), the direction to which the user should go, and the distance to which the user should travel in order to remove the restriction. The display to assist in removing the restriction may be a display of text or a display of a specified object. The specified object may be an object located at the location of the reviveable event for which revival is restricted (e.g., a pillar of light 70 in FIG. 8 ) or an object indicating the direction to which the user should go (e.g., an arrow 71 in FIG. 8 ). Additionally, the form of the specified object (for example, the color or shape of the arrow 71) may change depending on the distance that must be traveled before revival becomes possible, thereby informing the user of the distance.

It may also be possible to revive a reviveable event and play the revived reviveable event regardless of the distance between the user's current location and the location where the reviveable event is set.

The game control unit 212 may also limit the number of times a reviveable event can be revived. This limit may limit the number of times a reviveable event can be revived within a predetermined period of time. Specifically, an upper limit on the number of times a reviveable event can be revived within a predetermined period of time may be specified for each reviveable event. In this case, when the number of times a specific reviveable event has been revived within a predetermined period of time reaches the upper limit, the game control unit 212 controls the specific reviveable event to a state where revive is temporarily disabled, and controls the event to a state where revive is again possible after the predetermined period of time has passed. Also, an upper limit on the total number of times a reviveable event can be revived within a predetermined period of time may be specified. In this case, when the total number of times a specific reviveable event has been revived within a predetermined period of time reaches the upper limit, the game control unit 212 controls the multiple reviveable events to a state where revive is temporarily disabled, and controls the event to a state where revive is again possible after the predetermined period of time has passed. Also, an upper limit on the number of times a single reviveable event can be revived may be specified without a time limit. In this case, when the number of times a specific reviveable event has been revived reaches the upper limit, the game control unit 212 controls the specific reviveable event to a state where revival is permanently disabled.

The game control unit 212 may also limit the period during which revival is possible for a revival-enabled event. Specifically, a revival-enabled period may be specified for each revival-enabled event. For example, the game control unit 212 may control a specific revival-enabled event so that revival is impossible after a predetermined period of time has passed from a reference time. Here, the reference time may be, for example, the time when the specific revival-enabled event is cleared, the time when a special object 33d related to the specific revival-enabled event is placed in the virtual space before being cleared, or the time when the specific revival-enabled event is implemented in an application and becomes playable by each user.

That is, the game control unit 212 may manage the period during which a specific cleared resurrection-enabled event can be revived. Furthermore, the game control unit 212 may extend this period in response to payment of a fee. For example, the control unit 110 of the terminal device 10 may accept a user operation of selecting a specific resurrection-enabled event from among multiple resurrection-enabled events displayed in the list 65 of cleared resurrection-enabled events (see FIG. 6 ) as an operation to select a resurrection-enabled event for which the resurrection period is to be extended, and the game control unit 212 may extend the resurrection period of the selected resurrection-enabled event based on this operation. Furthermore, when extending the resurrection period, the game control unit 212 may reduce the value owned by the user by the amount of the fee (for example, reduce the value of a specific item owned by the user by "1"). The fee for extending the resurrection period may be an item different from the item requested as payment for resurrection. Furthermore, the fee for extending the resurrection period may be set to be the same type of fee as the resurrection fee, but in a smaller amount.

Furthermore, the game control unit 212 may vary the price of revival for a revival-enabled event depending on the number of times revival has occurred. For example, the game control unit 212 may increase the price of revival the more times revival has occurred.

The game control unit 212 may vary the reward for a specific resurrection-enabled event depending on the number of times the user revives the specific resurrection-enabled event (in other words, the number of times the specific resurrection-enabled event is played). For example, the game control unit 212 may increase the reward when the user revives and plays the specific resurrection-enabled event (specifically, the first play after reviving or the play after reviving a predetermined number of times) compared to the reward when the user first plays the specific resurrection-enabled event. Furthermore, the game control unit 212 may increase the reward obtained when playing the specific resurrection-enabled event the more times the user revives the specific resurrection-enabled event. Here, a high reward includes a large amount of reward, a high-quality item awarded as a reward, or an additional reward awarded in addition to the reward awarded when the reward is low. Furthermore, a high reward includes an item awarded that is not awarded when the reward is low (for example, an item that is rarer than the item awarded when the reward is low). The specific resurrection-enabled event may also be assigned a special item awarded depending on the number of times it is revived (in other words, an item awarded as a bonus depending on the number of times). In other words, the correspondence between the number of revivals and the reward to be granted for the specific revival-enabled event may be registered in the storage unit 220. Specifically, for example, a first special item may be set as the reward to be granted when the number of revivals is a first number, and a second special item may be set as the reward to be granted when the number of revivals is a second number. The game control unit 212 may then grant, as a reward, a specific item set in correspondence with the number of revivals.

As shown in FIG. 9, the guidance display 60 may include a display regarding the reward for the reviveable event. The display regarding the reward may, for example, indicate the content of the reward (e.g., the reward or the amount of the reward). The display regarding the reward may also indicate a special item that is awarded depending on the number of revivals (e.g., the first special item or second special item mentioned above). The guidance display 60 may also include a display of the cumulative number of times the target reviveable event has been revived.

The game control unit 212 may also increase the probability of acquiring a specific item in a specific resurrection event depending on the number of times the user revives the specific resurrection event (in other words, the number of times the specific resurrection event has been played). For example, the game control unit 212 may increase the probability of acquiring a specific item when the user revives and plays the specific resurrection event (specifically, the first play after reviving or the first play after reviving a predetermined number of times) compared to the first time the user plays the specific resurrection event. The game control unit 212 may also increase the probability of acquiring a specific item in a specific resurrection event the more times the user revives the specific resurrection event. In other words, in a configuration in which the game control unit 212 grants a specific item to the user in a specific resurrection event with a predetermined probability, the game control unit 212 may change the probability of granting the specific item depending on the number of times the specific resurrection event has been revived. The granting of the specific item may be performed at a predetermined trigger, such as when the resurrection event is cleared or when a predetermined enemy character is defeated during the resurrection event. In this embodiment, "increased probability (or high probability)" includes the case where the lower probability (in other words, the reference probability) is 0%.

The game control unit 212 may also generate a special event with a predetermined probability in a resurrectable event. For example, the game control unit 212 may generate a special event with a predetermined probability when a clear condition for the resurrectable event is met. In other words, the game control unit 212 may develop the resurrectable event with a predetermined probability. The special event may be, for example, an event in which a special character that does not normally appear (e.g., a special enemy character) appears. The game control unit 212 may also increase the probability of a special event occurring in a specific resurrectable event (in other words, the probability of the resurrectable event developing) depending on the number of times the user has revived the specific resurrectable event (in other words, the number of times the specific resurrectable event has been played). For example, the game control unit 212 may increase the probability of the special event occurring when the user revives and plays the specific resurrectable event (specifically, the first play after revival or the first play after revival a predetermined number of times) compared to when the user first plays the specific resurrectable event. Additionally, the game control unit 212 may increase the probability of a special event occurring the more times a user revives a particular revivable event.

In other words, the game control unit 212 may grant a predetermined benefit to the user depending on the number of times a specific reviveable event is revived (in other words, the number of times the specific reviveable event is played). The benefit may be, for example, a higher reward, an increased probability of obtaining a specific item, or an increased probability of a special event occurring.

The game control unit 212 may also increase the difficulty level of a specific reviveable event depending on the number of times the user revives the specific reviveable event (in other words, the number of times the specific reviveable event has been played). For example, the game control unit 212 may increase the difficulty level of the specific reviveable event when the user revives and plays the specific reviveable event (specifically, the first play after revival or the first play after a predetermined number of revivals) compared to the first time the user plays the specific reviveable event. The game control unit 212 may also increase the difficulty level of the specific reviveable event the more times the user revives the specific reviveable event. Specifically, the game control unit 212 may make the enemy characters that appear in the specific reviveable event stronger or increase the number of enemy characters that appear in the specific reviveable event the more times the game control unit 212 revives the specific reviveable event.

In games that use location information indicating a user's location in real space, such as location-based games, the user must first trigger an event corresponding to a specific event object 33 by physically traveling to a location within the usable range X where the specific event object 33 is located. Therefore, triggering an event can be a burden for the user. However, with the configuration of this embodiment, a specific event associated with a specific location in real space can be replayed after it has been cleared by paying a fee, thereby reducing the user's burden and promoting game play. For example, in a configuration that allows a specific event to be revived and replayed even if the user is not in a location corresponding to the specific location (e.g., a location where the specific location is within the usable range X), the locational constraints for playing the specific event can be reduced, making the game easier to play and promoting game play. Furthermore, even if the configuration requires the user to be in a location corresponding to the specific position (for example, a location where the specific position is within the usable range X) in order to revive the specific event and play it again, this eliminates the need for the user to walk around looking for a location where the specific event can occur (for example, a location where a specific event object 33 is located) or to revisit a location where a specific event previously occurred after a predetermined period of time (for example, waiting for the special object 33d related to the specific event to revive naturally), making the game easier to play and promoting game play.

(Return of multiplayer events)
Up to this point, the explanation has been given assuming that one user repeatedly plays and revives in reviveable events by themselves to earn rewards, etc. However, reviveable events may also be events that allow multiplayer. Hereinafter, reviveable events that allow multiplayer will be referred to as "multiplayer events."

The game control unit 212 grants the right to revive the multiplay event to multiple users who participated in the multiplay event. The control unit 110 of each of the multiple users' terminal devices 10 then accepts a revival operation to revive the multiplay event. The acceptance of the revival operation on each terminal device 10 and the guidance for reviving a revival-enabled event (e.g., guidance display 60, etc.) can be performed in the same way as in the case where a single user plays and revives a revival-enabled event described above, and therefore explanations will be omitted.

The game control unit 212 may revive a multiplayer event in response to a revival operation by one of the multiple users participating in the multiplayer event.

When one of the multiple users participating in the multiplay event performs a revival operation, the game control unit 212 revives the multiplay event. The game control unit 212 also instructs the terminal device 10 of the other user to notify the other users of the multiple users that the multiplay event has been revived. Based on the instruction, the control unit 110 of the terminal device 10 of the other user notifies the other users that the multiplay event has been revived. For example, as shown in FIG. 10, the control unit 110 of the terminal device 10 of the other user causes the display unit 18 to display a revival notification display 80 notifying the other users that the multiplay event has been revived.

The revival notification display 80 also asks whether you want to participate in the revived multiplayer event. The revival notification display 80 can also be thought of as a display recruiting members to participate in the revived multiplayer event.

Other users who are notified that a multiplayer event has been revived can participate in the revived multiplayer event by performing a predetermined operation in response to the notification. In other words, other users who are notified that a multiplayer event has been revived can play the revived multiplayer event together with the user who revived the multiplayer event by performing a predetermined operation. For example, the control unit 110 may display a join button 82 on the display unit 18 as a UI that accepts an operation to join the revived multiplayer event (hereinafter referred to as a "join operation"), along with a revival notification display 80. Note that the revival notification display 80 may also serve as this UI. The game control unit 212 allows other users who are notified that the multiplayer event has been revived to participate in the revived multiplayer event based on the join operation by the other users. In other words, the game control unit 212 starts a multiplayer event in which the user who performed the revival operation to revive the multiplayer event and the user who performed the join operation play together, and controls the progress of the multiplayer event. In other words, when reviving a cleared multiplayer event, the game control unit 212 controls the event so that the revivable event can be played again with the same members who cleared it.

In this way, when one of the multiple users participating in the multiplay event performs a revival operation, the other users are notified that a request to revive the multiplay event has been made, and the other users are able to participate in the multiplay event in response to the notification. Note that here, users who participate in the multiplay event in response to the notification can also be said to be users who agree to the revival of the multiplay event (in other words, to play again). In other words, the participation operation to participate in the multiplay event can also be said to be an operation of agreeing to the revival of the multiplay event. Note that the game control unit 212 may revive the multiplay event when more than one of the multiple users participating in the multiplay event (in other words, a predetermined number or more, for example, all users) agree to the revival of the multiplay event (in other words, they have performed an operation to agree), and may not revive the multiplay event unless more than one of the multiple users agrees.

Furthermore, if there are multiple users participating in the revived multiplayer event, the game control unit 212 may be able to have the revival fee shared among the multiple users participating in the revived multiplayer event. For example, once the game control unit 212 confirms the members participating in the multiplayer event based on each user's revival or participation operation to revive the multiplayer event, it determines each member's share of the fee and has each member pay that share (specifically, by deducting the share from the value owned by each user). The share may be determined according to a predetermined rule; for example, the total amount of the fee required to revive the multiplayer event may be divided equally among the number of members, or some members (e.g., the user who performed the revival operation or the user who performed the participation operation) may be required to pay a larger amount. When dividing the payment among users, the game control unit 212 may first collect the entire amount required to revive the multiplayer event from one user (for example, the user who performed the revival operation), and then, if other users participate in the multiplayer event, collect the other users' share of the cost from those other users and return it to the user who initially paid the entire amount.

For example, the user who performed the revival operation may pay a fee, and other users participating in the revived multiplayer game may be able to participate in the multiplayer event without paying a fee. Furthermore, each user participating in the revived multiplayer event may pay a set fee regardless of the number of users participating in the revived multiplayer event. That is, for example, the user who performed the revival operation may consume one revival item regardless of whether there are other users participating in the revived multiplayer event. Furthermore, each of the other users participating in the revived multiplayer event may also consume one revival item.

Furthermore, for example, the user may be able to set the proportion of the fee that each user will bear. For example, the game control unit 212 may determine each user's share of the fee based on an operation by the user performing the revival operation to set the proportion of the fee that each user will bear participating in the multiplayer event being revived. The game control unit 212 may then have each member participating in the multiplayer event pay their share of the fee. Note that the operation to set the proportion of the fee may be accepted, for example, on the screen on which the revival operation is performed.

Note that at least some (in other words, some or all) of the members participating in the revived multiplayer event may be users other than the users who completed the multiplayer event together (in other words, the users who participated in the previous multiplayer event). For example, when one of multiple users participating in the multiplayer event performs a revival operation, the game control unit 212 instructs the terminal device 10 of that other user to notify other users who meet certain conditions that the multiplayer event has been revived (in other words, that users are being recruited to participate in the revived multiplayer event). Based on the instruction, the control unit 110 of the terminal device 10 of that other user notifies the other users that the multiplayer event has been revived. For example, the control unit 110 of the terminal device 10 of that other user causes the display unit 18 to display a revival notification display 80 notifying the other users that the multiplayer event has been revived. The other users who have been notified that the multiplayer event has been revived can participate in the revived multiplayer event by performing a certain operation in response to the notification.

Here, other users who satisfy the specified conditions may be other users who have a specified relationship with the user who performed the revival operation. Specifically, as described above, other users who satisfy the specified conditions may be other users who have completed a multiplayer event together. Furthermore, other users who satisfy the specified conditions may be other users who are friends or follow the user who performed the revival operation. Furthermore, users who satisfy the specified conditions may be other users who belong to the same organization as the user who performed the revival operation (for example, an in-game group that cooperates for a specified purpose, such as a team, party, or guild). Furthermore, users who satisfy the specified conditions may be other users who are located within a specified range of the current location of the user who performed the revival operation (in other words, users whose locations indicated by each other's location information are within a specified distance).

Note that friend and following can be similar to conventional games and SNS (Social Networking Services). In the game of this embodiment, each user may be able to register other users as friends. Furthermore, each user may be able to follow other users. For example, if a first user makes a friend registration request to a second user and the second user accepts the request, the control unit 210 may register the first user and the second user as friends. Furthermore, if a first user makes a follow request to a second user, the control unit 210 may register the first user as a follower of the second user. Note that each request and its acceptance can be executed by each user performing a predetermined input operation on their own terminal device 10.

Furthermore, other users who meet certain conditions may be other users who are located within a certain range from the location where the revived multiplayer event is set.

The game control unit 212 may control the notification to notify only one type of other user that the multiplayer event has been revived, or may control the notification to notify multiple types of other users that the multiplayer event has been revived. That is, for example, the game control unit 212 may control the notification to notify other users who completed the multiplayer event together with the user who performed the revival operation, and friends of the user who performed the revival operation, that the multiplayer event has been revived. In this way, when notifying multiple types of other users, the game control unit 212 may control the notification to be sent to multiple types of other users simultaneously, or may control the notification to be sent preferentially to a specific type of user. Specifically, the game control unit 212 may first control the notification to be sent to other users who completed the multiplayer event together with the user who performed the revival operation, and if the number of users wishing to participate in the revived multiplayer event does not reach a predetermined number, may control the notification to be sent to friends of the user who performed the revival operation.

The user performing the revival operation may also be able to set the type of users to be notified that the multiplayer event has been revived (in other words, the type of users to be recruited). For example, the game control unit 212 may determine the type of users to be recruited based on an operation performed by the user performing the revival operation to set the type of users to be recruited as members to participate in the revived multiplayer event. The game control unit 212 may then instruct the terminal devices 10 of the determined type of users to send the notification.

(Reviving events that other users have cleared)
Each user may be able to revive and play a reviveable event that another user has completed (in other words, a reviveable event that the user has never played). For example, a user may be able to revive and play a reviveable event that another user who has a predetermined relationship with the user has completed.

For example, as shown in FIG. 11 , the control unit 110 of the user's terminal device 10 may be able to display on the display unit 18 a list 90 of reviveable events that have been cleared by other users who have a predetermined relationship with the user. For example, the control unit 110 may cause the display unit 18 to display a list 90 of reviveable events that have been cleared by other users who have a predetermined relationship with the user, based on a predetermined operation by the user (e.g., an operation on a predetermined icon displayed on a predetermined play screen). Note that the list 90 may also display reviveable events that the user himself has cleared. When another user who has a predetermined relationship with the user clears a reviveable event, the game control unit 212 adds the cleared reviveable event to the reviveable events to be displayed on the list 90. The control unit 110 also accepts, as a revive operation, a user operation to select a specific reviveable event from among the multiple reviveable events displayed on the list 90. In other words, when a second user (e.g., a friend of the first user) who has a predetermined relationship with the first user clears a reviveable event, the game control unit 212 transmits information about the reviveable event cleared by the second user to the terminal device 10 of the first user. When the information is transmitted, the control unit 110 of the terminal device 10 of the first user causes the display unit 18 to display a list 90 including the reviveable events cleared by the second user. The control unit 110 of the terminal device 10 of the first user accepts, as a revive operation, an operation by the first user to select a specific reviveable event from among the multiple reviveable events displayed in the list 90. The game control unit 212 revives the selected reviveable event (e.g., a reviveable event cleared by the second user) based on the operation. Specifically, the game control unit 212 controls the first user to play the reviveable event cleared by the second user as the selected reviveable event based on the operation. For example, based on this operation, the game control unit 212 may cause the first user to start playing a reviveable event that was cleared by the second user as the selected reviveable event. With this configuration, for example, it is possible to make a reviveable event cleared by another user with a predetermined relationship playable without the user having to visit the location where the reviveable event is set. Therefore, for example, it is possible to allow the first user to play a specific reviveable event in cases where a special object 33d corresponding to a specific reviveable event does not appear near the first user.

The game control unit 212 may enable multiplayer between the first and second users when the first user plays a reviveable event that has been cleared by the second user. Specifically, when the first user revives a reviveable event that has been cleared by the second user, the game control unit 212 may instruct the terminal device 10 of the second user to notify the second user that the multiplayer event has been revived, and may cause the terminal device 10 of the second user to display a revive notification display 80 related to the notification.

<Processing flow>
Next, an example of processing related to revival of a revivable event will be described with reference to the flowchart shown in FIG.

First, the location information acquisition unit 116 acquires location information indicating the user's current location in real space (step S101).

Next, the game control unit 212 determines whether the positional relationship between the user's current location indicated by the acquired location information and the location associated with the reviveable event satisfies a predetermined condition (step S102). Specifically, the game control unit 212 determines whether the location where the special object 33d corresponding to the reviveable event is placed is within a predetermined range (e.g., usable range X) determined based on the user's current location.

If the positional relationship between the user's current location indicated by the acquired location information and the location associated with the reviveable event satisfies a predetermined condition (YES in step S102), the game control unit 212 starts the reviveable event based on a predetermined operation by the user (e.g., an operation on the special object 33d) (step S103).

Next, when the set clearing conditions for the started revivable event are met, the game control unit 212 ends the revivable event (step S104).

Next, the game control unit 212 instructs the terminal device 10 of the user who cleared the reviveable event to display a guidance display 60 that provides guidance about reviving the cleared reviveable event (step S105).

Next, based on the instruction, the control unit 110 of the terminal device 10 causes the display unit 18 to display the guidance display 60 and accepts a predetermined operation by the user in response to the guidance (in other words, an operation to revive a cleared revivable event) (step S106).

Next, the game control unit 212 revives the cleared reviveable event based on a predetermined operation performed by the user in response to the guidance (step S107). Specifically, the game control unit 212 makes the cleared reviveable event playable again and starts the reviveable event. At this time, the game control unit 212 reduces the value owned by the user by the amount of the price for revival.

Next, an example of processing related to reviving a multiplayer event will be explained with reference to the flowchart shown in Figure 13.

When the set clear conditions for a started multiplayer event are met, the game control unit 212 ends the multiplayer event (step S201).

Next, the game control unit 212 instructs the terminal devices 10 of each of the multiple users who participated in the multiplayer event to display a guidance display 60 informing them about the revival of the cleared multiplayer event (step S202).

Next, based on the instruction, the control unit 110 of each user's terminal device 10 displays the guidance display 60 on the display unit 18 and accepts a predetermined operation by each user in response to the guidance (in other words, an operation to revive the multiplayer event) (step S203).

Next, the game control unit 212 revives the cleared multiplayer event based on a predetermined operation performed by any user in response to the prompt (step S204). In other words, the game control unit 212 makes the cleared multiplayer event playable again.

Next, the game control unit 212 instructs the terminal devices 10 of the multiple users who participated in the reviveable event, other than the user who performed a predetermined operation in response to the notification, to notify the other users that the multiplayer event has been revived (step S205).

Next, based on the instruction, the control unit 110 of the terminal device 10 of the other user causes the display unit 18 to display a revival notification display 80 notifying the other user that the multiplayer event has been revived, and accepts an operation by the other user to participate in the revived multiplayer event (step S206).

Next, when the other user performs an operation to participate in the revived multiplay event, the game control unit 212 causes the user who performed the operation to revive the multiplay event and the user who performed the operation to participate in the revived multiplay event to participate in the revived multiplay event, and starts the multiplay event (step S207).

The present invention is not limited to the above-described embodiment and can be modified in various ways without departing from the spirit and scope of the present invention. The configuration of this embodiment may be applied to games that utilize information regarding the user's position in real space. Furthermore, the configuration of this embodiment may be applied to games that link virtual space with real space, such as the location-based game described in this embodiment or games that utilize images captured in real space. Games that utilize images captured in real space may include, for example, games that display superimposed images in which virtual objects (e.g., virtual space objects such as player characters) are superimposed on images captured in real space (in other words, games that utilize augmented reality), or games in which images captured in real space have a predetermined effect on the virtual space (e.g., games in which the parameters of objects in virtual space are changed or the shape of objects in virtual space is deformed based on the captured images). In other words, the control unit 110 of the terminal device 10 may be capable of acquiring images captured by a predetermined camera, such as a camera built into the terminal device 10, and generating superimposed images in which virtual objects are superimposed on the captured images. The configuration of this embodiment may also be applied to games other than games that link virtual space and real space. The configuration of this embodiment may also be applied to games other than games that use information about the user's position in real space. The configuration of this embodiment may also be applied to services (in other words, applications) other than games. For example, it may be applied to walking apps, running apps, pedometer apps, etc.

Within the scope of the present invention, it is possible to freely combine each component, modify any component, replace any component, omit any component, or add other components. Furthermore, the processing flow described in this specification is merely an example, and the order and configuration of each process may be different. Furthermore, some processes described in this specification may not exist. In other words, the processing flow and specific determination processes may differ from those exemplified in this specification.

<Additional Notes>
The configuration of this embodiment may be used, for example, to promote the use of a service. Furthermore, the configuration of this embodiment may be used, for example, to increase the interest of a service. The matters described in the above embodiment may also be written as follows:

(Appendix 1)
Computer,
A program that functions as a replay control means (e.g., a game control unit 212) that executes control to make a specific event associated with a specific location in real space playable again in response to payment of a fee by the user after the specific event associated with a specific location in real space has been cleared in a service that uses location information indicating the user's location in real space.
According to this configuration, when a specific event associated with a specific location in real space is cleared, the specific event can be played again. Therefore, users who are highly motivated to play the specific event can easily play the specific event, which can promote user use of the service. Furthermore, since a user must pay a fee to play the specific event again, the value of the specific event is prevented from decreasing compared to when the event can be played again an unlimited number of times, which can increase the interest of the service.

(Appendix 2)
Computer,
The program described in Appendix 1 functions as an event control means (e.g., a game control unit 212) that starts a specific event based on a user's operation on a specific object corresponding to the specific event, which is placed at a position in the virtual space corresponding to the specific position, when the specific object is located within a predetermined range determined based on the position information.
In such a configuration, since a user must travel to a location where a specific object is located within a predetermined range determined based on the user's location information to start a specific event, for users who find it troublesome or difficult to travel to that location, the difficulty of playing the specific event may be a reason for them to stop using the service. However, in this configuration, such a specific event can be made playable again by paying a fee, making it easier for users to play the specific event and promoting user use of the service.

(Appendix 3)
The replay control means
The program according to appendix 1, wherein the conditions for making the specific event playable again are changed depending on the relationship between the user's current location indicated by the location information and the specific location.
With this configuration, the conditions for being able to play a particular event again change depending on the user's current location, giving the user a reason to move in real space in order to replay a particular event, thereby increasing the interest of the service.

(Appendix 4)
The replay control means
The program described in Appendix 1 manages the period during which the specific event that has been cleared can be played again, and extends the period in response to payment of a fee by the user.
This configuration sets a limit on the period during which a specific event can be played again, encouraging users to use the service without waiting for a certain period. Furthermore, users can extend the period during which a specific event can be played again by paying a fee, enabling them to use the service in a new style of play. This can therefore encourage users to use the service.

(Appendix 5)
the specific event is an event that allows multiplayer play,
The program described in any one of Appendices 1 to 4, wherein the replay control means makes it possible to replay the specific event that has been cleared in multiplayer based on a predetermined operation by one of multiple users who participated in the multiplayer.
With this configuration, for events that allow multiplayer, a user who participated in a multiplayer game can replay the event alone, thereby enabling users to enjoy the event together with other users, improving each user's freedom of play and promoting user use of the service.

(Appendix 6)
Computer,
5. The program according to claim 1, wherein the program functions as a limiting means for limiting the number of times that the specific event that has been cleared can be made playable again.
With this configuration, it is possible to prevent the value of a particular event from decreasing, compared to when the particular event can be played again an unlimited number of times, and to increase the interest of the service.

(Appendix 7)
Computer,
functioning as a reward granting means for granting a reward to a user who plays the specific event;
The program according to any one of appendices 1 to 4, wherein the reward granting means changes the reward granted to the user who played the specific event depending on the number of times the user has made the specific event playable again.
With this configuration, the change in reward can motivate users to pay a fee to make a specific event playable again, thereby encouraging users to use the service.

(Appendix 8)
Computer,
5. The program according to any one of appendices 1 to 4, wherein the program functions as a guidance means for providing a user who has cleared the specific event with guidance about being able to play the cleared specific event again when the specific event is cleared.
With this configuration, a user who has completed a specific event can be prompted to replay the event, thereby encouraging the user to use the service.

The problem-solving means constituted by the above-mentioned program (for example, the components described in the appendix) can be appropriately adapted for use in devices, systems, methods, media, etc.

1 Information processing system, 10 Terminal device, 11 Processor, 12 Memory, 13 Storage, 14 Communication IF, 15 Input/output IF, 17 Input unit, 18 Display unit, 20 Server, 21 Processor, 22 Memory, 23 Storage, 24 Communication IF, 25 Input/output IF, 110 Control unit, 111 Operation reception unit, 112 Transmission/reception unit, 113 Game control unit, 114 Display control unit, 116 Location information acquisition unit, 120 Memory unit, 210 Control unit, 211 Transmission/reception unit, 212 Game control unit, 220 Memory unit, X Availability range

Claims (8)

Computer,
a registration means for, when an event that is located at a specific position in a virtual space that is not a position designated by the user in a game is cleared by the user, registering the cleared event as a candidate for an event to be revived upon payment of a fee by the user;
a replay control means for restoring an event selected by the user from among a plurality of registered candidates to the position in the virtual space where the event was originally placed , thereby enabling the user to replay the event ;
the registration means is capable of , when another user having a predetermined relationship with the user clears an event that is located at a specific position in the virtual space that is not a position designated by the other user , registering the cleared event as a candidate for an event to be revived upon payment of a fee by the user;
The replay control means is a program that revives an event that has been cleared and registered as a candidate for revival by the other user to the location in the virtual space where the event was located, in response to payment of a fee by the user, thereby enabling the user to play the event. Computer,
The program according to claim 1 , wherein the program functions as a notification means for notifying the other user that an event cleared by the other user has been revived in response to payment of a fee by the user. Computer,
a registration means for, when a multiplay event that is located at a specific position in a virtual space and that is available for multiplay in a game is cleared, registering the cleared multiplay event as a candidate for an event to be revived upon payment of a fee by a user who participated in the multiplay event ;
a replay control means for reviving an event selected by the user from among a plurality of registered candidates and enabling the user to replay the event;
The replay control means revives the revived multi-play event as a replayable event at the position in the virtual space where the revived multi-play event was placed.
program. Computer,
a registration means for, when an event located at a specific position in a virtual space in a game is cleared by a user, registering the cleared event as a candidate for an event to be revived upon payment of a fee by the user;
a replay control means for reviving an event selected by the user from among a plurality of registered candidates, and enabling the user to replay the event;
a control means for displaying information about the deadline for reviving an event on a screen displaying candidates for an event to be revived, and for changing the display order of the candidates according to the deadline for reviving each candidate;
The replay control means is a program for reviving the event to be revived as a replayable event at the position in the virtual space where the event was originally placed. Computer,
The event revival deadline can be extended in response to payment of a fee by the user.
The program according to claim 4 , wherein the extension means is capable of extending the deadline based on an operation by the user on a screen displaying information about the deadline by which the event can be revived. a registration means for, when an event that is located at a specific position in a virtual space that is not a position designated by the user in a game is cleared by the user, registering the cleared event as a candidate for an event to be revived upon payment of a fee by the user;
a replay control means for restoring an event selected by the user from among a plurality of registered candidates to the position in the virtual space where the event was originally placed , thereby enabling the user to replay the event ;
the registration means is capable of , when another user having a predetermined relationship with the user clears an event that is located at a specific position in the virtual space that is not a position designated by the other user , registering the cleared event as a candidate for an event to be revived upon payment of a fee by the user;
The replay control means revives an event that has been cleared and registered as a candidate for reviving by the other user to the location in the virtual space where the event was located , in response to payment of a fee by the user, thereby enabling the user to play the event. a registration means for, when a multiplay event that is located at a specific position in a virtual space and that is available for multiplay in a game is cleared, registering the cleared multiplay event as a candidate for an event to be revived upon payment of a fee by a user who participated in the multiplay event ;
a replay control means for reviving an event selected by the user from among a plurality of registered candidates, and enabling the user to replay the event;
The replay control means revives the revived multi-play event as a replayable event at the position in the virtual space where the revived multi-play event was placed.
Information processing system. a registration means for, when an event located at a specific position in a virtual space in a game is cleared by a user, registering the cleared event as a candidate for an event to be revived upon payment of a fee by the user;
a replay control means for reviving an event selected by the user from among a plurality of registered candidates, and enabling the user to replay the event;
a control means for displaying information about a deadline by which an event can be revived on a screen displaying candidates for the event to be revived, and for changing the display order of the candidates according to the deadline by which each candidate can be revived;
The replay control means revives the event to be revived as a replayable event at the position in the virtual space where the event was placed.