Program and information processing system

Abstract

To provide a program that enhances interest of service.SOLUTION: A program causes a computer to function as event control means that, when an event associated with a specific position in real space satisfies a first condition in the virtual space, makes the event associated with the specific position unable to proceed, and that, when a second condition related to movement in real space is satisfied, makes the event associated with the specific position able to proceed. The second condition is that the user's movement record, which is the number of steps or distance traveled, reaches a predetermined threshold.SELECTED DRAWING: Figure 5

Description

[Technical Field]

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

[0002] BACKGROUND ART Conventionally, there has been known a technique that enables an event associated with a specific position in real space to be executed in a virtual space (for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent Publication No. 2024-28603 Summary of the Invention [Problem to be solved by the invention]

[0004] The present invention aims to improve the interest of the service. [Means for solving the problem]

[0005] In order to solve the above problem, the program of the present invention causes a computer to function as an event control means that prevents an event associated with a specific position in real space from progressing if the event satisfies a first condition in virtual space, and allows the event associated with the specific position to progress if the event satisfies a second condition regarding movement in real space. [Effects of the Invention]

[0006] According to the present invention, the interest of the service is improved. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 2 is a diagram illustrating each configuration of the information processing system. [Figure 2]FIG. 1 is a hardware configuration diagram of an information processing system. [Figure 3] FIG. 2 is a functional block diagram of the information processing system. [Figure 4] FIG. 10 is a schematic diagram of a specific example of a play screen. [Figure 5] FIG. 10 is a diagram for explaining a specific example of how an event is revived. [Figure 6] 3 is a flowchart of each process in the information processing system. [Figure 7] FIG. 10 is a diagram for explaining a second embodiment. [Figure 8] FIG. 10 is a diagram for explaining a third embodiment. [Figure 9] FIG. 10 is a diagram for explaining a fourth embodiment. [Figure 10] FIG. 10 is a diagram for explaining a modified example. DETAILED DESCRIPTION OF THE INVENTION

[0008] First Embodiment Fig. 1 is a diagram illustrating each component of an information processing system 1000. The information processing system 1000 includes a terminal device 100 and a server device 200. As shown in Fig. 1, the terminal device 100 and the server device 200 can communicate with each other via a network N. The network N may be, for example, the Internet.

[0009] The terminal device 100 is portable by a user, and may be, for example, a smartphone, a personal computer, or a portable game console. The terminal device 100 stores various programs including application programs. In reality, a plurality of terminal devices 100 communicate with the server device 200. However, for the sake of explanation, only one terminal device 100 is shown in FIG. 1 .

[0010] The server device 200 provides the terminal device 100 with various types of information that the terminal device 100 uses when executing an application program. Specifically, the terminal device 100 and the server device 200 work together to provide a service that uses the user's location information, such as a game that uses the user's location information (referred to as a location information game). Note that while FIG. 1 shows an example in which the server device 200 is configured as a single server device, the server device 200 may also be configured as a plurality of server devices (systems).

[0011] The terminal device 100 is configured to be able to acquire position information in the real space Sr. Specifically, the terminal device 100 is equipped with a GPS (Global Positioning System) receiving unit and is configured to be able to receive GPS signals. The GPS signals include position information indicating the position of the terminal device 100 on a horizontal plane. In this embodiment, the position of the terminal device 100 on the horizontal plane of the real space Sr may be referred to as a "user position Pr." Of course, height information (altitude) may be added to progress a position-information game, which will be described later. The user position Pr can be estimated to indicate the position of the user who owns the terminal device 100. Furthermore, the user position may be estimated by linking with position information acquired by an external device other than the terminal device 100. For example, information from a wearable device, a watch-type device, an eyeglass-type device, a communication repeater, various sensors installed in buildings in the real space, a camera, and the like may be used as position information.

[0012] In a location-based game, a user (terminal device 100) can perform various events in a virtual space Sv by moving around the real space Sr. Specifically, when the user moves to an event spot res in the real space Sr, an event associated with the event spot res can be performed. Various locations in the real space Sr are set as event spots res. For example, FIG. 1 shows event spots res1 and event spots res2 selected from the event spots res in the real space Sr.

[0013] In the specific example of FIG. 1, it is assumed that, of the event spots res, event spot res1 is set up near the user's home H. In the above case, the user can carry out the event associated with event spot res1 without traveling far from home H. On the other hand, it is assumed that, of the event spots res, event spot res2 is set up far from home H. In the above case, the user needs to travel far to carry out the event associated with event spot res2.

[0014] However, depending on the user's attributes, it may be difficult for the user to travel far from home. For example, if the user is a minor, it may be difficult for the user to travel far from home. Therefore, it is expected that some users may only carry out events at event spots res located near their home (e.g., res1 in Figure 1) and may not be able to proceed with events at event spots res located far from their home (e.g., res2 in the same figure).

[0015] As can be understood from the above explanation, a user who can travel far (e.g., an adult) can participate in events associated with event spots res that are far from their home in addition to events associated with event spots res that are close to their home. On the other hand, a user who cannot travel far (e.g., a minor) may only participate in events associated with event spots res that are close to their home.

[0016] However, if an event associated with the event spot res is executed (if the first condition is met), the event associated with the event spot res becomes unable to proceed. Furthermore, the event associated with the event spot res will not be able to be executed (will not be revived) until a predetermined rearrangement period has elapsed. The rearrangement period is set to, for example, one week.

[0017] Let's assume a configuration in which an event associated with the event spot res can be revived only when the rearrangement period has elapsed (a configuration in which an event cannot be revived unless the rearrangement period has elapsed). In this configuration, users who cannot travel far will be able to execute fewer events during the rearrangement period (one week) compared to users who can. Therefore, users who cannot travel far will find that their progress in the game is extremely slow, which can cause them to feel that the game is less interesting.

[0018] Taking the above circumstances into consideration, this embodiment employs a configuration in which an event associated with an event spot res can be revived when a predetermined condition (second condition) is met by the user's movement in the real space Sr (for example, when the number of steps traveled reaches a predetermined number). According to this embodiment, after a user executes an event associated with an event spot res, the user can execute the event associated with the event spot res again before the above-mentioned reappearance period has elapsed. For example, a user who cannot travel far can revive the event and progress through the game by traveling around the neighborhood of their home. This reduces the above-mentioned inconvenience.

[0019] As another means for suppressing the above-mentioned inconveniences, a configuration (hereinafter referred to as "comparative example") is envisioned in which an event is revived by using an item (for example, an item that is granted on the condition of a charge) that can be acquired even when the user does not move within the real space Sr. Even in the above-mentioned comparative example, as in the present embodiment, the event can be revived before the reappearance period has elapsed. Therefore, the above-mentioned inconveniences are suppressed.

[0020] However, in the above comparison, the game can be progressed even if the user does not move. However, location-based games inherently require the user to move in order to progress in the game, which is what creates the excitement that is not found in games other than location-based games. Therefore, the above comparison, in which the game can be progressed even if the user does not move, creates a new problem in that the inherent excitement of a location-based game may be lost.

[0021] In this embodiment, the condition for reviving an event is met by the user moving. Therefore, even for users who find it difficult to travel far, the effect is achieved of being able to progress in the game without waiting for the reappearance period to elapse, without losing the original fun of a location-based game. The above configuration will be described in detail later. Note that the present invention does not exclude the above-mentioned comparative examples.

[0022] Fig. 2 is a hardware configuration diagram of the information processing system 1000. As described above, the information processing system 1000 includes the terminal device 100 and the server device 200. As shown in Fig. 2, the terminal device 100 includes a processing device 101, a storage device 102, a communication device 103, a display device 104, a GPS receiving unit 105, and an acceleration and direction sensor 106. Each of the above components is connected to each other so as to be able to communicate with each other via a system bus.

[0023] The processing device 101 controls the entire terminal device 100. The processing device 101 may be configured with one or more processors. Specifically, the processing device 101 may be configured with one or more types of processors, such as a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC).

[0024] The storage device 102 stores various programs including a basic program and an application program PGx. Well-known storage media such as semiconductor storage media and magnetic storage media can be used as the storage device 102. The storage device 102 may be configured as a single storage medium or multiple storage media. The application program PGx is downloaded in advance and installed on the terminal device 100. The storage device 102 also stores various game data used in the location-based game (such as data indicating items given to the user and data indicating the status of the user character).

[0025] The display device 104 includes a display panel 104a and a touch panel 104b. The display panel 104a is, for example, a flat display configured with organic EL (Electro Luminescence). The touch panel 104b is configured to be able to detect a touch operation by a user. Specifically, the touch panel 104b is provided over the display panel 104a and receives a touch operation on an image displayed on the display panel 104a.

[0026] The GPS receiver 105 receives GPS signals from GPS satellites. The acceleration and direction sensor 106 is configured by combining various sensors including a compass, an acceleration sensor, and a gyro sensor that detects direction. The communication device 103 communicates with the server device 200 via the network N.

[0027] The server device 200 includes a processing device 201, a storage device 202, and a communication device 203. These components are communicatively connected via a system bus. The processing device 201 controls the entire server device 200. The processing device 201 of the server device 200 may be configured with one or more processors, similar to the processing device 101 of the terminal device 100 described above. Specifically, the processing device 201 may be configured with one or more types of processors, such as a CPU, a GPU, a DSP, an FPGA, or an ASIC.

[0028] The storage device 202 stores various programs including a basic program and a game management program PGy. The storage device 202 of the server device 200 may be, for example, a known storage medium such as a semiconductor storage medium or a magnetic storage medium. The storage device 202 may be configured with a single storage medium or multiple storage media. The storage device 202 also stores various game data used in the location-based game (such as data indicating items given to the user and data indicating the status of the user character) in association with the user's identifier. The communication device 203 communicates with the terminal device 100 via the network N.

[0029] 3 is a functional block diagram of the information processing system 1. As shown in FIG. 3, the information processing system 1 of this embodiment is configured to include a terminal device 10 and a management device 20. For example, the above-mentioned terminal device 100 executes an application program PGx to function as the terminal device 10. Furthermore, the above-mentioned server device 200 executes a game management program PGy to function as the management device 20. Each of the above components can communicate via a network N.

[0030] The terminal device 10 includes an event control means 11. However, the management device 20 may be configured to have the above configuration (functions).

[0031] When an event (for example, a fortress battle described below) associated with a specific position (event spot res) in real space Sr satisfies a first condition (for example, when the fortress battle is cleared), the event control means 11 disables the event associated with the specific position from progressing, and when a second condition regarding movement in real space is satisfied, the event associated with the specific position is enabled to progress (revives). Hereinafter, for the sake of explanation, the condition for reviving an event (second condition) may be referred to as the "revival condition."

[0032] Furthermore, the event control means 11 of this embodiment enables an event associated with a specific location to be executed when the user's travel history, which is the number of steps or travel distance, reaches a predetermined threshold. In this embodiment, the user's number of steps is used as the travel history. Specifically, the terminal device 10 detects the user's walking using the acceleration sensor and gyroscope described above, and counts the user's number of steps using the detection result.

[0033] When the user's travel distance is used as the travel history, the travel distance can be calculated from the location information of the terminal device 10. Specifically, a configuration can be adopted in which the travel route of the terminal device 10 is identified from the location information of the terminal device 10 at each time point, and the length of the travel route is calculated as the user's travel distance. However, both the user's travel steps and travel distance may be used as the travel history. For example, a configuration may be adopted in which an event can be revived when both the user's travel steps and travel distance satisfy predetermined conditions. In other words, the "travel history" of the present invention may also include a combination of the travel steps and travel distance.

[0034] 4 is a schematic diagram of a specific example of a play screen Mp displayed on the terminal device 10 (display panel 104a). A virtual space Sv is displayed on the play screen Mp, and a location-based game progresses in the virtual space Sv. Specifically, in the location-based game, various events (battles with monsters, acquisition of items) can be performed in the virtual space Sv by the user moving through the real space Sr.

[0035] The virtual space Sv is displayed based on map information in the real space Sr and the user position Pr. The above map information is provided to the terminal device 10 from the management device 20, for example. However, the management device 20 may acquire the map information from an external server and transfer the map information to the terminal device 10. The user position Pr is identified using the above-mentioned GPS signal.

[0036] As shown in Fig. 4, the play screen Mp is configured to include various objects. Specifically, the play screen Mp is configured to include a character image Gp, a monster image Gm, an item image Gi, a fortress image Gf, a home image Gh, and a ground image Gg. Note that the specific example in Fig. 4 shows only some of the objects displayed on the play screen Mp.

[0037] The ground surface image Gg in the virtual space Sv is displayed in an area corresponding to the ground surface in the real space Sr. The ground surface image Gg described above is displayed based on map information in the real space Sr. Specifically, road areas are displayed in the ground surface image Gg at positions corresponding to roads in the real space Sr. In other words, the ground surface image Gg described above represents a map in the real space Sr.

[0038] The character image Gp represents the user character in the virtual space Sv. As shown in FIG. 4, the character image Gp is ​​displayed at the character position Pv. The character position Pv in the virtual space Sv corresponds to the user position Pr in the real space Sr. In other words, the character position Pv indicates the user position Pr on the map of the real space Sr represented by the ground image Gg. Specifically, the character position Pv in the virtual space Sv moves as the user position Pr identified from the GPS signal moves. In other words, the character image Gp moves in the virtual space Sv as the user moves in the real space Sr.

[0039] Other objects (such as fortress images Gf) on the play screen Mp are arranged in the virtual space Sv in a predetermined manner. Specifically, the position information of the event spot res in the real space Sr and the type of event that can be started at the event spot res are associated (linked) and stored. Note that the event spot res in this embodiment (an example of a "specific position" in the present invention) may be a "point" defined by a combination of latitude and longitude, or may be a "surface" having a certain extent. In other words, the "specific position" in the present invention is a concept that encompasses both a "point" and an "area" in real space.

[0040] For ease of explanation, a location in the virtual space Sv that corresponds to an event spot res in the real space Sr may be referred to as an "event spot ves." An event associated with an event spot res in the real space Sr is also associated with an event spot ves in the virtual space Sv that corresponds to the event spot res. An object corresponding to the event associated with the event spot ves is placed at each event spot ves in the virtual space Sv.

[0041] In this embodiment, an area in the virtual space Sv that corresponds to an area within a predetermined distance (e.g., about 200 meters) from the user position Pr in the real space Sr is set as the available area. The available area is an area that can be selected to start an event in the virtual space Sv.

[0042] In the above configuration, when an event spot ves is located in an available area in the virtual space Sv, an event associated with the event spot ves becomes executable. Specifically, when an event spot ves is located in an available area in the virtual space Sv, touching an object placed on the event spot ves starts an event corresponding to the object. Note that an image showing the outer edge of the available area may be displayed on the play screen Mp.

[0043] For example, if a monster image Gm is located in the available area, the user can start a battle (event) with the monster by touching (selecting) the monster image Gm. In a battle with a monster, when the user character's attack hits, the monster's hit points decrease according to the user character's attack power (an example of a status). On the other hand, when the monster's attack hits the user character, the user character's hit points decrease. The battle can be won by reducing the monster's hit points to the value "0" before the user character does.

[0044] When a user character wins a battle with a monster, experience points are awarded to the user character. When the total experience points awarded to the user character reaches a predetermined threshold, the level (status) of the user character increases. Furthermore, when the battle with the monster ends, regardless of the outcome of the battle, the monster image Gm is hidden from the play screen Mp, making it impossible to rematch the monster. However, if the user is defeated by a monster, the monster image Gm may be configured not to be hidden, but to allow a rematch with the monster. In this embodiment, a new monster image Gm is rearranged on the play screen Mp every time a predetermined time (for example, approximately 5 minutes) has elapsed.

[0045] If an item image Gi is located in the available area, an item is granted to the user when the item image Gi is touched. When an item is granted by touching the item image Gi, the item image Gi is hidden from the play screen Mp. Note that an item may also be granted when defeating a monster, in addition to when the item image Gi is touched. In this embodiment, a new item image Gi is rearranged on the play screen Mp every time a predetermined time (for example, approximately 24 hours) has elapsed.

[0046] When the home image Gh is touched while it is located in the usable area, the hit points of the user character are restored. Specifically, when the hit points of the user character are restored by touching the home image Gh, the hit points can be restored again after a predetermined time (for example, one hour) has passed.

[0047] The position where the above-described home image Gh is placed (hereinafter referred to as "home position Ph") can be determined arbitrarily by the user. As described above, in this embodiment, a configuration is adopted in which the hit points of the user character can be repeatedly restored by touching the home image Gh. With the above configuration, the user can frequently restore the hit points of the user character by placing the home image Gh in a virtual space Sv corresponding to a location where the user spends a relatively long time. For the above reasons, the home image Gh is placed in the virtual space Sv corresponding to the address of the user's home, for example.

[0048] When a fortress image Gf is located in the available area, a fortress battle begins when the fortress image Gf is touched. In a fortress battle, a battle pits the fortress monster corresponding to the fortress image Gf against the user character. Hereinafter, to distinguish it from a fortress battle, a battle in which a monster image Gm is touched may be referred to as a "normal battle." If the user wins a fortress battle, advantageous benefits are more likely to be awarded to the user than if the user wins a normal battle. For example, if the user wins a fortress battle, advantageous items are awarded that are not awarded if the user wins a normal battle.

[0049] As described above, when a normal battle is executed, the monster image Gm is hidden from the play screen Mp. On the other hand, when a fortress battle is executed, the fortress image Gf is not hidden from the play screen Mp. Specifically, the fortress image Gf is displayed in either an available state or an unavailable state (see FIG. 5 described later). When a fortress image Gf in an available state is touched, the fortress battle begins. On the other hand, when a fortress image Gf in an unavailable state is touched, the fortress battle does not begin. Note that, as will be described in detail later, the unavailable state includes a cleared state and a revival state (see FIG. 5).

[0050] For example, assume that a fortress battle is won. In the above cases, the state of the fortress image Gf on the play screen Mp changes from a usable state to an unusable state before and after the fortress battle. On the other hand, if the fortress battle is lost, the state of the fortress image Gf on the play screen Mp is maintained in a usable state before and after the fortress battle. In the above configuration, if the fortress battle is lost, the fortress battle can be played again. On the other hand, if the fortress battle is won, the fortress battle cannot proceed. However, even if the fortress battle is lost, the fortress image Gf may be switched to an unusable state, making it impossible to proceed with the fortress battle.

[0051] In this embodiment, fortress images Gf may be placed at multiple event spots ves in the virtual space Sv. In the above cases, fortress battles can be started at multiple event spots ves. Specifically, if a fortress battle associated with an event spot ves is won, the fortress battle associated with that event spot ves cannot proceed, while the fortress battles associated with other event spots ves remain viable.

[0052] For example, in the specific example of FIG. 4, it is assumed that fortress images Gf are placed at both event spot ves1 and event spot ves2. In the above case, even if the fortress battle associated with event spot ves1 is won, the fortress battle associated with event spot ves2 remains viable. Specifically, if the fortress battle associated with event spot ves1 is won, the fortress image Gf of event spot ves1 changes to an unavailable state, but the fortress image Gf of event spot ves2 remains viable.

[0053] It is assumed that the event spot ves1 in the specific example of Fig. 4 corresponds to the event spot res1 in the real space Sr in the above-mentioned specific example of Fig. 1. Similarly, it is assumed that the event spot ves2 in the specific example of Fig. 4 corresponds to the event spot res2 in the real space Sr in the above-mentioned specific example of Fig. 1. As described above, the event spot res1 is located near the user's home, and the event spot res2 is located far from the user's home.

[0054] In the specific example of FIG. 4, a user who can travel far (an adult user) can participate in fort battles at both event spot ves1 and event spot ves2. On the other hand, a user who cannot travel far (a minor user) can participate in fort battles only at event spot ves1. As can be understood from the above explanation, if an event cannot be revived, a user who cannot travel far will have difficulty progressing in the game. Taking the above circumstances into consideration, this embodiment employs a configuration that suppresses the above inconveniences. Details of the above configuration will be explained using FIG. 5.

[0055] The appearance (display area and angle) of each of the above objects (such as the ground image Gg) changes as the character position Pv moves. That is, the appearance of each object in the virtual space Sv changes as the user moves through the real space Sr. Specifically, the play screen Mp displays the virtual space Sv in which the character position Pv (character image Gp) is viewed from a predetermined viewing direction. The above viewing direction may be configured to be changeable in response to a user operation.

[0056] 4, in addition to the objects in the virtual space Sv, button images Gb1, Gb2, and Gb3 are displayed on the play screen Mp. Each of the button images Gb (1-3) is displayed at a predetermined position on the play screen Mp, and their appearance does not change even if the character position Pv moves.

[0057] For example, when the button image Gb1 is touched, the play screen Mp is switched to an item screen. The user can use various items via the item screen. For example, an item that recovers the character's hit points can be used via the item screen. Furthermore, by appropriately operating the item screen, the item exchange screen Mc can be displayed. In this embodiment, walk points are awarded according to the number of steps taken by the user. The user can exchange the walk points for various items using the item exchange screen Mc. A specific example of the above configuration will be described in detail using Figures 7(a) and 7(b) of the second embodiment described later.

[0058] When the button image Gb2 is touched, the play screen Mp is switched to the map screen Mt. The map screen Mt is a bird's-eye view of the virtual space Sv, and displays a wider area of ​​the virtual space Sv than the play screen Mp. A specific example of the map screen Mt will be described in detail using FIG. 8(a) of the third embodiment.

[0059] When the button image Gb3 is touched, the play screen Mp is switched to the skill activation screen Ms. In this embodiment, if the skill activation screen Ms is operated appropriately during a period after a predetermined activation condition is satisfied, a special skill is activated. Specifically, when the user character's level reaches a predetermined level, the user character acquires the special skill. When the activation condition is satisfied while the user character has acquired the special skill, the special skill can be activated. The activation condition for the special skill is satisfied when the user's number of steps reaches a predetermined threshold. A specific example of the above configuration will be described in detail as a modified example using Figures 10(a) and 10(b).

[0060] FIG. 5 is a diagram for explaining the details of the operation of the event control means 11 of this embodiment. As described above, the fortress image Gf is displayed in one of a plurality of modes. Specifically, the fortress image Gf is displayed in either an available mode or an unavailable mode. The unavailable mode includes a cleared mode and a reviving mode. FIG. 5 shows the transition of the fortress image Gf mode.

[0061] As described above, when the rearrangement period has elapsed, a fortress image Gf is placed at one of the event spots ves (step S0 in FIG. 5). As shown in FIG. 5, the fortress image Gf is displayed in an available state immediately after placement. In this embodiment, fortress images Gf may be placed at multiple event spots ves. Immediately after the placement period has elapsed, a fortress battle can be started regardless of which fortress image Gf is touched.

[0062] In this embodiment, multiple types of fortress images Gf are provided, and the content of the fortress battle changes depending on the type of fortress image Gf. Specifically, the type of fortress monster that is the opponent in the fortress battle changes depending on the type of fortress image Gf. The type of fortress monster that will be battled when the fortress image Gf is touched is notified in the fortress image Gf in an available state. For example, an image representing the fortress monster that will be battled when the fortress image Gf is touched is included in the fortress image Gf.

[0063] If the fortress battle is won, the state of the fortress image Gf changes to a cleared state (uncleared state) (step S1 in FIG. 5). If the fortress battle is won and the fortress image Gf changes to a cleared state, the fortress battle will not start even if the fortress image Gf is touched. The fortress image Gf in the cleared state displays a string of characters informing that the fortress battle associated with the fortress image Gf (event spot ves) has been cleared. Note that the fortress image Gf in the cleared state may or may not be configured to notify the type of fortress battle that has been cleared.

[0064] In this embodiment, the number of steps the user has taken since winning the fortress battle until the present (hereinafter referred to as "number of steps ns") is counted. When the number of steps ns reaches "8000 steps", the revival condition is met and the fortress battle can be played again (the user is revived).

[0065] When the number of steps remaining until the revival condition is met falls to a predetermined number or less, the fortress image Gf changes from a cleared state to a reviving state (step S2 in FIG. 5). For example, when the number of steps remaining until the revival condition is met falls to 1000 steps or less, the fortress image Gf changes to a reviving state. The fortress image Gf in the reviving state notifies the number of steps remaining until the revival condition is met. For example, the specific example in FIG. 5 assumes that the number of steps remaining until the revival condition is met is "1000 steps." In this case, the character string "1000 steps until revival" is displayed on the fortress image Gf.

[0066] In addition, the fortress image Gf in the revival mode may or may not be configured to notify the type of fortress battle that will be revived thereafter. Also, in this embodiment, both the cleared mode and the revival mode are provided as impossible modes, but it is also possible to provide only one of the above modes.

[0067] For example, a configuration may be adopted in which only a cleared state is provided as an unavailable state. In the above configuration, the fortress image Gf is directly switched from the cleared state to the available state. Also, a configuration may be adopted in which only a reviving state is provided as an unavailable state. In the above configuration, the fortress image Gf is directly switched from the available state to the reviving state. For example, if the revival condition is met when the number of steps ns reaches "8000 steps", immediately after switching from the available state to the reviving state, the fortress image Gf will display the text "8000 steps until revival".

[0068] Incidentally, location-based games are often expected to attract users to various locations. Therefore, users who can travel long distances (e.g., adult users) are expected to actively travel to distant event spots (res).

[0069] However, if the fortress image Gf is configured to be directly switched from the available state to the reviving state, immediately after the fortress battle ends at the event spot res, the number of steps remaining until the fortress battle at the event spot res is revived is notified (see FIG. 5). In the above configuration, it is expected that some users will remain in the vicinity of the event spot res in order to re-run the fortress battle at the event spot ves, even though they are able to travel farther.

[0070] In the above cases, the above-mentioned effects expected in the location-based game may be reduced. In this embodiment, the fortress image Gf in the cleared state immediately after winning the fortress battle does not display the number of steps remaining until the revival condition is met. Therefore, the above-mentioned inconveniences can be suppressed. However, the present invention does not exclude a configuration in which the fortress image Gf is directly switched from the available state to the revival state.

[0071] When the number of steps ns traveled since the fortress image Gf was switched to the unavailable mode reaches "8000 steps," the revival condition is met, and the fortress image Gf is switched to the available mode (step S3 in FIG. 5). In the above cases, the fortress battle can be played again by touching the fortress image Gf. Also, as shown in FIG. 5, if the revived fortress battle is won, when the number of steps ns traveled thereafter reaches "8000 steps" again, the revival condition is met again, and the fortress image Gf is displayed in the available mode again.

[0072] In the present embodiment, the fortress battle can be repeatedly executed at the same event spot res each time the user's number of steps n satisfies the revival condition. Therefore, for example, a user who has difficulty traveling far can revive the event and progress through the game by traveling around their neighborhood.

[0073] 6 is a flowchart of the process executed by the terminal device 10. The terminal device 10 repeatedly executes the above process, for example, during a period when the fortress image Gf is in an unusable state. Note that each step of the above process may be executed by the terminal device 10 and the management device 20 in cooperation with each other, or may be executed by the management device 20.

[0074] As shown in FIG. 6, the movement record is updated during the period when the fortress image Gf is in an unavailable state. As described above, in this embodiment, the user's number of steps ns is used as the movement record for reviving the event (fortress battle). In the above embodiment, the number of steps ns is updated in step S101. Note that the current value of the number of steps ns may be stored in either the terminal device 10 or the management device 20, or may be stored in both devices. When the management device 20 stores the number of steps ns, the number of steps of the user counted by the terminal device 10 is transmitted to the management device 20.

[0075] When the movement record is updated, it is determined whether or not the revival condition is met (S102). For example, the terminal device 10 determines whether or not the number of movement steps ns updated in the immediately preceding step S101 has reached "8000 steps". If the number of movement steps ns has not reached "8000 steps" (S102: No), the processing shown in FIG. 6 ends. On the other hand, if the number of movement steps ns has reached "8000 steps" (S102: Yes), the revival processing (S103) is executed. Note that in a configuration in which the management device 20 determines whether or not the updated number of movement steps ns has reached "8000 steps", the result of this determination is notified to the terminal device 10. Furthermore, based on this notification, the terminal device 10 determines that the revival condition has been met.

[0076] The revival process is a process for reviving the fortress battle. For example, in the revival process, the terminal device 10 changes the fortress image Gf on the play screen Mp from an unavailable state to an available state, making the fortress image Gf touch-operable. After the revival process is executed, the process shown in FIG. 6 ends.

[0077] Second Embodiment Other embodiments of the present invention will be described below. In each of the following exemplary embodiments, elements that have the same actions and functions as those in the first embodiment will be designated by the same reference numerals as those in the first embodiment, and detailed descriptions thereof will be omitted where appropriate.

[0078] As in the first embodiment, the event control means 11 of the second embodiment can revive an event when the movement record (number of steps moved, movement distance) satisfies the revival condition. Specifically, in the second embodiment, the types of events that can be revived change depending on the movement record. Also, in the second embodiment, the events that can be revived when the revival condition is satisfied are a predetermined portion of the events that can be executed in the virtual space Sv.

[0079] In the second embodiment, an upper limit is set on the number of times an event can be revived when the revival condition is met (hereinafter referred to as "revival count"). Furthermore, if the revival condition is met and the event becomes executable, and the event does not proceed for a predetermined time (hereinafter referred to as "revival time"), the event will no longer be able to proceed. Each of the above configurations will be described in detail below.

[0080] FIG. 7(a) is a schematic diagram of the item exchange screen Mc in the second embodiment. In the second embodiment, walk points are awarded according to the number of steps taken by the user. Specifically, 40 walk points are awarded for every 1000 steps taken by the user. Note that in the above configuration, the number of walk points awarded when the user takes 1000 steps may be increased, for example, subject to a charge. As shown in FIG. 7(a), the item exchange screen Mc displays the walk points owned by the user.

[0081] The user can exchange walk points for various items by appropriately operating the item exchange screen Mc. Specifically, as shown in FIG. 7(a), the item exchange screen Mc is configured to include a plurality of selection images Gc. Each of the selection images Gc corresponds to one of the items that can be exchanged for walk points. Note that FIG. 7(a) shows an excerpt of each selection image Gc. The user can switch between the selection images Gc displayed by swiping the item exchange screen Mc (touch panel 104b).

[0082] Items that can be exchanged for walk points include, for example, items that can be equipped by a user character. Equipping a user character with these items improves the status of the user character. For example, among the selection images Gc in FIG. 7(a), the selection image Gc3 corresponds to a "dagger" (weapon) that can be equipped by a user character. When a user character is equipped with such a "dagger," the attack power (part of the status) of the user character improves.

[0083] Additionally, items that can be exchanged for walk points include "Fort Revival Tickets" for reviving fort battles. By using a Fort Revival Ticket, a user can revive the fort battle corresponding to the Fort Revival Ticket. Specifically, in the second embodiment, multiple types of fort battles can be progressed. The multiple types of fort battles described above include Fort Battle A, Fort Battle B, Fort Battle C, and Fort Battle X.

[0084] In each fortress battle (A to C, X), the opponent is a different fortress monster, and the benefits (type of item, amount of experience points) awarded if you win may vary. For example, the opponent in fortress battle A is a relatively weak fortress monster. Also, the opponent in fortress battle B is a stronger fortress monster than the opponent in fortress battle A. In other words, the user character level that can be cleared (recommended) is higher in fortress battle B than in fortress battle A. However, the benefits awarded for clearing fortress battle B are more likely to be advantageous to the user than the benefits awarded for clearing fortress battle A. For example, clearing fortress battle B is more likely to award the user with an advantageous item than clearing fortress battle A.

[0085] The opponent in Fortress Battle C is a fortress monster that is stronger than the opponent in Fortress Battle B. However, the reward for clearing Fortress Battle C is more likely to be advantageous to the user than the reward for clearing Fortress Battle B. For example, clearing Fortress Battle C is more likely to grant the user an advantageous item than clearing Fortress Battle B.

[0086] The opponent in Fortress Battle X is a special fortress monster. Specifically, fortress monsters in other fortress battles (A to C) usually do not flee. However, fortress monsters in Fortress Battle X may flee. If the fortress monster flees, Fortress Battle X is not cleared. However, if Fortress Battle X is cleared, the user character will be awarded more experience points than if they cleared other fortress battles.

[0087] In the second embodiment, similarly to the first embodiment described above, each fortress image Gf is placed at each event spot ves. The fortress images Gf in the second embodiment include a fortress image Gf where fortress battle A starts when touched, a fortress image Gf where fortress battle B starts, a fortress image Gf where fortress battle C starts, and a fortress image Gf where fortress battle X starts. Each of the above fortress images Gf is displayed on the play screen Mp in a manner that allows the type of fortress battle corresponding to the fortress image Gf to be understood. Furthermore, each fortress image Gf is displayed in either an available state or an unavailable state (see FIG. 5 described above).

[0088] Fortress revival tickets that can be exchanged for walk points include Fortress Revival Ticket A for reviving Fortress Battle A, Fortress Revival Ticket B for reviving Fortress Battle B, Fortress Revival Ticket C for reviving Fortress Battle C, and Fortress Revival Ticket X for reviving Fortress Battle X. The specific example in Figure 7(a) shows an excerpt of selection image Gc1 corresponding to Fortress Revival Ticket A for reviving Fortress Battle A out of the fortress battles (A to C, X), and selection image Gc2 corresponding to Fortress Revival Ticket B for reviving Fortress Battle B.

[0089] As shown in Figure 7(a), each selection image Gc displays a button image showing the character string "Exchange." When any of these button images is touched, the walk points are exchanged for the item corresponding to the selection image Gc on which the button image is displayed.

[0090] If a user has a fortress revival ticket, they can use it by operating the item screen as appropriate. When a fortress revival ticket is used, a fortress battle that has already been cleared is revived. For example, when fortress revival ticket A is used, the fortress image Gf corresponding to fortress battle A is changed to an available state, and fortress battle A becomes available. Also, when fortress revival ticket B is used, the fortress image Gf corresponding to fortress battle B is changed to an available state, and fortress battle B becomes available.

[0091] Similarly, when a fortress revival ticket C is used, the fortress image Gf corresponding to the fortress battle C is changed to an available state, and the fortress battle C becomes possible to be carried out. However, the event spot ves where the fortress image Gf is located does not change before and after the fortress battle is revived. In other words, the fortress battle is revived at the event spot ves where the fortress battle was cleared.

[0092] As can be seen from Figure 7(a), the Walk Points required for exchange may differ for each item. For example, among the items, Fortress Revival Ticket A can be exchanged for "500pt" of Walk Points. On the other hand, Fortress Revival Ticket B can be exchanged for "2000pt" of Walk Points.

[0093] As described above, in the second embodiment, 40 walk points are awarded for every 1,000 steps the user takes. Therefore, 500 walk points are awarded when the user takes 12,500 steps. The above configuration can also be said as follows: when the user takes 12,500 steps, the revival condition for Fortress Battle A is met. Also, when the user takes 50,000 steps, 2,000 walk points are awarded. In other words, when the user takes 50,000 steps, the revival condition for Fortress Battle B is met. The above configuration can also be said as follows: the type of Fortress Battle in which the user can be revived changes depending on the number of steps the user takes.

[0094] In addition, there may be a limit to the number of times each item can be exchanged. As shown in FIG. 7(a), the selection image Gc displays the remaining number of exchanges for the item corresponding to that selection image Gc. For example, among the items, fortress revival ticket A has no limit on the number of exchanges, but fortress revival ticket B can be exchanged up to two times. The above configuration can also be said to impose a limit on the number of revivals in fortress battle B. However, when the rearrangement period (one week) for fortress image Gf has elapsed, the remaining number of exchanges for each fortress revival ticket is reset.

[0095] 7(b) is a conceptual diagram of a revival management table according to the second embodiment. The revival management table defines various information (such as the number of revivals) for each fortress battle (A to C, X). For example, the revival management table is stored in the terminal device 10. However, the revival management table may be stored in the management device 20, or may be stored in both the terminal device 10 and the management device 20.

[0096] The revival management table specifies the number of walk points that can be exchanged for a fortress revival ticket to revive each fortress battle (A to C, X). For example, as described above, fortress revival ticket A to revive fortress battle A can be exchanged for 500 walk points. Fortress revival ticket B to revive fortress battle B can be exchanged for 2000 walk points, and fortress revival ticket C to revive fortress battle C can be exchanged for 3000 walk points. The revival management table also specifies the number of times each fortress revival ticket can be exchanged. As described above, there is no limit to the number of times fortress revival ticket A can be exchanged. On the other hand, fortress revival ticket B can be exchanged up to two times, and fortress revival ticket C can be exchanged up to one time.

[0097] However, as shown in FIG. 7(b), among the fortress battles, fortress battle X cannot be revived. That is, in the second embodiment, a configuration is adopted in which a predetermined portion of the fortress battles (A to C) among the fortress battles can be revived. In the above configuration, the inconvenience of the user being given an excessive advantage is suppressed compared to, for example, a configuration in which all fortress battles can be revived. However, a configuration in which all fortress battles can be revived may also be adopted.

[0098] The resurrection management table specifies the resurrection time for each fortress battle. As described above, a revived fortress battle becomes unable to proceed once the resurrection time has elapsed (the fortress image Gf is returned to an unplayable state). For example, the resurrection time for fortress battle A is approximately 3 hours. The resurrection time for fortress battle B is approximately 1 hour, and the resurrection time for fortress battle C is approximately 1 hour.

[0099] In the second embodiment described above, for example, assume that the user has moved 12,500 steps and been awarded 500 walk points. In this case, by obtaining Fortress Revival Ticket A once, Fortress Battle A can be revived for three hours. On the other hand, assume that the user has moved 25,000 steps and been awarded 1,000 walk points. In this case, by obtaining Fortress Revival Ticket A twice, Fortress Battle A can be revived for a total of six hours. In other words, in the configuration of the second embodiment, the more steps the user takes, the longer the Fortress Battle revival time will be.

[0100] In the second embodiment, the location where a fortress revival ticket can be used can be changed as appropriate. For example, a fortress revival ticket for reviving a fortress battle associated with an event spot ves can be used regardless of the distance from the event spot ves (fortress image Gf) to the character position Pv (character image Gp). Also, a fortress revival ticket for reviving a fortress battle associated with the event spot ves can be used on the condition that the event spot ves is located within the usable range.

[0101] According to the second embodiment described above, the same effect as in the first embodiment can be achieved. Note that, in the first embodiment as well, a limit may be placed on the number of times a fortress battle can be revived. Also, in the first embodiment as well, if a predetermined revival time has elapsed after a fortress battle has been revived, the fortress battle may be made unable to proceed (the fortress image Gf may be changed to an unprogressible state). In the above configuration, the revival time of a revived fortress battle may change depending on the number of steps taken by the user. For example, the revival time of a fortress battle may be extended as the number of steps taken by the user increases.

[0102] Third Embodiment The event control means 11 of the third embodiment can revive an event when the user moves to a predetermined area (an event spot res where a revival item, described later, can be obtained) in the real space Sr. Furthermore, the event control means 11 of the third embodiment can revive an event depending on the user's attributes (minor, adult).

[0103] FIG. 8(a) is a schematic diagram of a specific example of the map screen Mt in the third embodiment. The map screen Mt is a bird's-eye view of the virtual space Sv represented by the play screen Mp. As with the play screen Mp, the map screen Mt displays each object at each event spot ves. The map screen Mt also displays a current location image Gpy at the character position Pv in the virtual space Sv. A home image Gh is also placed at the home position Ph in the virtual space Sv. It is assumed that the home position Ph corresponds to the position of the user's home in the real space Sr.

[0104] In the third embodiment, similar to the second embodiment described above, multiple types of fortress battles (A, B) can be performed. Furthermore, fortress images Gf corresponding to each fortress battle are arranged on the play screen Mp and the map screen Mt. For example, in the specific example of FIG. 8(a), it is assumed that a fortress image Gf corresponding to fortress battle A is arranged at event spot ves1, and a fortress image Gf corresponding to fortress battle B is arranged at event spot ves2. Furthermore, in the specific example of FIG. 8(a), it is assumed that a period after the fortress battles have been cleared at each of the above event spots ves(1, 2). During this period, an unavailable fortress image Gf is displayed at each event spot ves(1, 2).

[0105] In the third embodiment, during the period when the unavailable fortress image Gf is displayed, a revival item image Gi(a, b) is displayed on the play screen Mp and the map screen Mt. When a revival item image Gi(a, b) located in the available area is touched, a revival item corresponding to the revival item image Gi is acquired. By acquiring the revival item, the user can revive the fortress battle corresponding to the revival item. In other words, the revival conditions for the fortress battle are met when the user moves to an event spot res in the real space Sr where the revival item can be acquired.

[0106] As described above, the specific example in Fig. 8(a) assumes the period after Fortress Battle A and Fortress Battle B have been cleared. During this period, a revival item image Gia corresponding to revival item A for reviving Fortress Battle A and a revival item image Gib corresponding to revival item B for reviving Fortress Battle B are displayed on the play screen Mp and the map screen Mt.

[0107] In the third embodiment, the number of revival items that must be acquired to revive varies depending on the type of fortress battle. For example, in fortress battle A, revival is achieved by acquiring one revival item A. On the other hand, in fortress battle B, revival is achieved by acquiring two revival items B. As shown in FIG. 8(a), the number of remaining revival items required to revive the fortress battle is displayed on the map screen Mt. However, in the virtual space Sv, more revival item images Gi(a, b) may be displayed than the number of revival items required to revive the fortress battle. The above configuration has the advantage of increasing the degree of freedom in the area that the user must move to in order to acquire revival items.

[0108] For example, in the specific example of FIG. 8(a), the user can revive fortress battle A by traveling to either event spot ves5 or event spot ves6 and obtaining one revival item A. The user can also revive fortress battle B by traveling to both event spot ves3 and event spot ves4 and obtaining a total of two revival items B. Note that, in the above configuration, the more revival items that need to be obtained, the more steps the user is likely to take. Taking the above into consideration, it is preferable to configure a fortress battle that requires a larger number of revival items to be revived, so that the user is granted a more advantageous benefit upon clearing the battle.

[0109] Now, let us consider a configuration in which a user needs to travel far from their home to revive a fortress battle. For example, let us consider a case in which the above-mentioned revived item image Gi is located far from the home position Ph. In this case, a user who has difficulty traveling far from their home may encounter the inconvenience of finding it difficult to revive the fortress battle. In consideration of the above circumstances, the third embodiment employs a configuration that can suppress the above inconvenience. The above configuration will be described in detail below with reference to FIG. 8(b).

[0110] 8(b) is a conceptual diagram of an item placement table. The above-described item placement table defines the range in which the revived item image Gi is placed (hereinafter referred to as the "placement range") for each user attribute. For example, the item placement table is stored in the terminal device 10. However, the item placement table may be stored in the management device 20, or may be stored in both the terminal device 10 and the management device 20.

[0111] In the third embodiment, the placement range is set according to the user attribute (minor, adult). For example, if the user attribute is "minor," the placement range is set to a virtual space Sr corresponding to "within 500 meters from home" in the real space Sr. Specifically, the placement range is set to a virtual space Sv corresponding to an area up to about 500 meters from the position in the real space Sr corresponding to the home position ph (the position of the home). On the other hand, if the user attribute is "adult," the size of the placement range is not limited.

[0112] When the fortress battle is cleared, if a placement range is set (if the user is a minor), the revival item image Gi is randomly placed in one of the event spots ves within the placement range. Specifically, the number of revival item images Gi equal to or greater than the number of revival items required to revive the fortress battle is placed in the placement range.

[0113] For example, one revival item A is required to revive fortress battle A. Therefore, when a placement range is set, one or more revival item images Gia corresponding to revival item A are placed in the placement range. Furthermore, two revival items B are required to revive fortress battle B. Therefore, two or more revival item images Gib corresponding to revival item B are placed in the placement range. With the above configuration, if the user is a minor, the fortress battle can be revived without traveling more than about 500 meters from their home.

[0114] On the other hand, if the placement range is not limited (if the user is an adult), the revival item image Gi may be placed in an event spot ves corresponding to an area more than approximately 500 meters from the user's home. In the above configuration, if the user is an adult, the user will travel far from home to revive the fortress battle. Therefore, it becomes easier to attract adult users who are able to travel far to various areas in the real space Sr.

[0115] The third embodiment described above also achieves the same effects as the first embodiment. User attributes can be identified by an appropriate method. For example, assume a configuration in which profile information can be input by appropriately operating the terminal device 10. In the above configuration, the user attributes may be identified by referring to "age" in the profile information. Furthermore, the terminal device 10 may be provided with a camera, and the age of the user may be estimated from a photograph of the user's face taken by the camera.

[0116] Furthermore, the location-based game may be linked to other services (e.g., social networking services), and the attributes of the user may be identified from user information acquired from the other services. Furthermore, a technology (so-called "item gacha") has been known in the past in which various items are awarded to users by lottery in exchange for consuming specific points. The specific points may also be awarded to users by paying a fee. In the above configuration, a user who has performed the item gacha many times (frequency) may be presumed to be an adult.

[0117] In the first and second embodiments described above, an event may be revived according to the user's attributes. For example, in the first embodiment, the number of steps ns that satisfy the event revival condition may be fewer for minors than for adults. In the second embodiment, the number of walk points that can be exchanged for fort revival tickets may be fewer for minors than for adults. Furthermore, the revival condition may be changed according to the user's "gender," or according to the user's "grade (elementary school, junior high school, high school, university, etc.)."

[0118] In addition, in the first and second embodiments described above, an event may be revived when the user moves to a predetermined area. For example, in the second embodiment, when a revival item is collected, a revival ticket for the event corresponding to the revival item may be provided.

[0119] <Fourth embodiment> In the fourth embodiment, when the revival condition is satisfied and an event becomes executable, the event control means 11 can restrict a new event from becoming executable even if the revival condition is subsequently satisfied again. A specific example of the above configuration will be described in detail below with reference to Figures 9(a) to 9(c).

[0120] 9(a) is a conceptual diagram of a specific example of a revival restriction table. The revival restriction table described above is provided to limit the number of events that can be revived at the same time. The revival restriction table described above is stored, for example, in the terminal device 10. However, the revival restriction table may be configured to be stored in the management device 20, or may be configured to be stored in both the terminal device 10 and the management device 20.

[0121] As shown in FIG. 9(a), the revival restriction table stores, for each fortress battle, the current "cleared status" of that fortress battle and whether that fortress battle can be revived. The "cleared status" of a fortress battle is updated to either "not cleared," "cleared," or "revived." Specifically, immediately after a fortress image Gf is placed on the play screen Mp, the cleared status of the fortress battle corresponding to that fortress image Gf becomes "not cleared." Furthermore, during the period from when a fortress battle is cleared until it is revived, the cleared status of that fortress battle becomes "cleared." Furthermore, if a "cleared" fortress battle is revived, the cleared status of that fortress battle becomes "revived."

[0122] That is, a fortress battle whose cleared state is "not cleared" or "revived" can be started, and the fortress image Gf corresponding to that fortress battle is in an available state. On the other hand, a fortress battle whose cleared state is "cleared" cannot be started, and the fortress image Gf corresponding to that fortress battle is in an unavailable state.

[0123] The "Revival Possibility" of a fortress battle indicates whether the fortress battle can be revived when the revival conditions are met. Specifically, in the fourth embodiment, if the number of fortress battles that have been cleared and are "revived" reaches the "limit number," a configuration is adopted in which the fortress battle is not revived even if the revival conditions are met.

[0124] The specific example in Figure 9(a) assumes that the limit is set to the number "2" (the same applies to Figures 9(b) and 9(c) described below). In the above case, even if three or more fortress battles are cleared, the number of fortress battles that can be revived at the same time will be two or less. With the above configuration, the inconvenience of the user having an excessive advantage is reduced compared to, for example, a configuration in which the number of fortress battles that can be revived at the same time is unlimited.

[0125] For example, in the specific example of Figure 9(a), it is assumed that the clear status of Fortress Battle A, Fortress Battle B, and Fortress Battle C among the Fortress Battles (A to D) is "Cleared." Also, it is assumed that the clear status of Fortress Battle D is "Not Cleared." In the above cases, the number of Fortress Battles with a clear status of "Resurrected" is 0, which is less than the limit of "2." Therefore, the "Resurrection Possibility" of Fortress Battles with a clear status of "Cleared" is "Resurrection Possible." Fortress Battles with a "Resurrection Possible" status can be revived if the resurrection conditions are met.

[0126] FIG. 9(b) is a conceptual diagram of another specific example of the revival restriction table. The specific example of FIG. 9(b) assumes that, of the fortress battles (A to C) whose cleared status is "cleared" in the specific example of FIG. 9(a) described above, fortress battles A and B are revived. In the above case, the cleared status of fortress battle A and the cleared status of fortress battle B are changed from "cleared" to "revived." In other words, the specific example of FIG. 9(b) assumes that the number of fortress battles whose cleared status is "revived" has reached the limit of "2."

[0127] As mentioned above, if the number of fortress battles with a cleared status of "Resurrected" reaches the limit of "2," new fortress battles cannot be revived. Specifically, if the number of fortress battles with a cleared status of "Resurrected" reaches the limit of "2," the revival possibility of a fortress battle will be changed to "Cannot be revived," even if the cleared status of the fortress battle is "Cleared." For example, in the specific example of Figure 9(b), the cleared status of fortress battle C is "Cleared," but the revival possibility is "Cannot be revived." In the above case, fortress battle C cannot be revived even if the revival conditions for fortress battle C are met.

[0128] 9(c) is a conceptual diagram of another specific example of the revival restriction table. The specific example of FIG. 9(c) assumes that Fortress Battle A, which was in the cleared state of "revived" in the specific example of FIG. 9(b), has been cleared again.

[0129] In the above cases, the cleared status of Fortress Battle A will be updated from "Resurrected" to "Cleared," and the number of Fortress Battles with a cleared status of "Resurrected" will be one (only Fortress Battle B). In other words, the number of Fortress Battles with a cleared status of "Resurrected" will be less than the limit of two. Therefore, the revival possibility of Fortress Battle A, whose cleared status has been changed from "Resurrected" to "Cleared," will be changed to "Resurrection Possible." In addition, the revival possibility of Fortress Battle C, which was cleared but not "Resurrection Possible," will be changed to "Resurrection Possible."

[0130] The third embodiment described above can also be employed in the first and second embodiments. For example, in the first embodiment, assume that multiple fortress battles have been "cleared." In the above case, when the user moves 8,000 steps after clearing the first fortress battle, that fortress battle is revived. Thereafter, the fortress battles may be revived sequentially in the order in which they were cleared every 8,000 steps. Furthermore, in the above configuration, when the number of fortress battles that have been "revived" and are cleared reaches a limit (for example, the number "2"), the revival of a new fortress battle may be restricted even if the user has moved 8,000 steps.

[0131] Furthermore, in the second embodiment, if the number of fortress battles revived using fortress revival tickets (fortress battles with a cleared status of "revived") reaches a limit, the use of fortress revival tickets may be temporarily restricted even if the player has a fortress revival ticket. Furthermore, in the above configuration, if a fortress battle with a cleared status of "revived" is cleared again, the use of a fortress revival ticket may be permitted.

[0132] <Modification> The above embodiments can be modified in various ways. Specific modified embodiments are exemplified below. Two or more embodiments selected from the following examples can be combined as appropriate.

[0133] (1) In each mode, the type of event that can be revived by the user moving through the real space Sr is not limited to the fortress battle. For example, an "event to acquire an item" that is executed by touching an item image Gi may be revived. Also, an event that recovers the hit points of the user character using the home image Gh may be revived.

[0134] (2) In each embodiment, a configuration is adopted in which an event can be revived based on the movement history of one user. However, a configuration may also be adopted in which an event can be revived based on the movement history of multiple users. For example, when each terminal device 10 of each user is appropriately operated, a common party formation request is sent from each terminal device 10 to the management device 20. The management device 20 sets each user of each terminal device 10 that sent the common party formation request to a common party. The terminal devices 10 of each user set to the common party can cooperate to progress each event.

[0135] In the above configuration, when the total movement records of each user belonging to a common party reaches a predetermined threshold, the event may be revived. Note that when one user belonging to a common party moves to a predetermined area (for example, an area where the above-mentioned revival item can be obtained), all users belonging to the party may be able to execute the revived event.

[0136] (3) In each embodiment, environmental information may be acquired, and an event may be revived in accordance with the environmental information.

[0137] Specifically, a configuration is assumed in which weather information can be acquired as environmental information. The above weather information includes various information including the weather at the user position Pr. In the above configuration, the type of revived event and / or the length of the revival time may be changed depending on the weather information. For example, if the weather at the user position Pr is "rain," a fortress battle with a special fortress monster may be revived.

[0138] Also, a configuration is assumed in which time information indicating the current time can be acquired. In the above configuration, the type of event to be revived and / or the length of the revival time may be changed depending on the time information. For example, if the time information indicates nighttime, a fortress battle with a special monster (e.g., a nocturnal monster) may be revived.

[0139] Similarly, when the time information indicates nighttime, the revival time of the revived event may be shorter than when the time information indicates daytime. Furthermore, when the time information indicates nighttime (late night), the event may not be revived. Furthermore, in each of the above configurations, when a special monster is defeated, a limited item that is not awarded when a normal monster is defeated may be awarded.

[0140] (4) In the first embodiment described above, a configuration was adopted in which the fortress battle was automatically revived when the user's number of steps satisfied the revival condition. Furthermore, in the second embodiment, a configuration was adopted in which the fortress battle was revived when the user's number of steps satisfied the revival condition (when walk points exchangeable for a fortress revival ticket were awarded) and the user used the fortress revival ticket. However, specific examples of the trigger for reviving the event (automatically or by using a fortress revival ticket) are not limited to the above examples.

[0141] FIG. 10(a) is a diagram illustrating a modified example. In the modified example of FIG. 10(a), the trigger for reviving an event differs from the above-described embodiments. Specifically, in this modified example, the user character is configured to be able to acquire various special skills. These special skills can be acquired, for example, each time the user character's level reaches a predetermined value. As will be described in more detail below, in this modified example, the fortress battle can be revived using special skills.

[0142] 10(a) is a schematic diagram of a specific example of the skill activation screen Ms. The skill activation screen Ms is displayed when the button image Gb3 (see FIG. 4) on the above-mentioned play screen Mp is touched. As shown in FIG. 10(a), the skill activation screen Ms includes a skill image Gs, a manual activation button Gbx, an automatic activation button Gby, and a step meter Gz.

[0143] A special skill can be executed when the user's movement record meets predetermined conditions. Specifically, when the number of steps the user has taken from the last time the special skill was used to the present reaches a predetermined threshold (e.g., 5,000 steps), the special skill can be executed again. The step meter Gz on the skill execution screen Ms displays the number of steps the user has taken from the last time the special skill was used to the present (1,000 steps in the specific example of FIG. 10(a)). The step meter Gz described above makes it easy to grasp the number of steps remaining until the special skill can be activated.

[0144] The skill image Gs corresponds to one of the special skills. Specifically, the skill image Gs corresponding to the special skill that the user character has acquired is displayed on the skill activation screen Ms. For example, if the user character has acquired multiple special skills, multiple skill images Gs are displayed on the skill activation screen Ms. The specific example in FIG. 10(a) assumes that the user character has acquired two special skills. In the above case, two skill images Gs, including skill image Gs1 and skill image Gs2, are displayed on the skill activation screen Ms.

[0145] The user can select one of the skill images Gs by appropriately touching the skill activation screen Ms. In the specific example of FIG. 10(a), it is assumed that the skill image Gs2 is selected among the skill images Gs. The user can also activate a special skill by touching the manual activation button Gbx on the skill activation screen Ms.

[0146] Specifically, when the manual activation button Gbx is touched, the special skill corresponding to the selected skill image Gs is activated. However, in the specific example of FIG. 10(a), it is assumed that the user's number of steps has not reached the number required to activate the special skill. In such a case, a message informing the user of this (for example, a message stating "insufficient steps") is displayed, and the special skill is not activated even if the manual activation button Gbx is touched.

[0147] Furthermore, in this modified example, the special skill can be automatically activated. Specifically, the automatic activation button Gby is switched between ON and OFF each time it is touched. When the automatic activation button Gby is in the ON state, if the user's number of steps from the last time the special skill was used until the present reaches 5,000, the special skill corresponding to the selected skill image Gs is automatically activated. This modified example can be controlled in auto mode, as in the first embodiment described above. Therefore, by turning the automatic activation button Gby ON in auto mode, the user can automatically activate the special skill and automatically execute various events.

[0148] The specific example in Figure 10(a) assumes that the user character has acquired the special skills "Can touch from a distance" and "Revive cleared events." For example, when the special skill "Can touch from a distance" is activated, the usable range expands for a predetermined time (for example, 5 minutes).

[0149] Specifically, as described above, the usable area is set to the virtual space Sv corresponding to an area up to 200 meters from the user in the real space Sr. In the above configuration, when the special skill "Can touch far away" is activated, the usable area is set to the virtual space Sv corresponding to an area up to 300 meters from the user in the real space Sr. The above special skill makes it possible to execute many events while limiting the user's movement distance in the real space Sr.

[0150] When the special skill "Reviving a Cleared Event" is activated, a predetermined cleared event becomes available for replay (is revived). For example, when the special skill "Reviving a Cleared Event" is activated, a cleared fortress battle is revived. In the above-described modified example, the revival condition is met when the user moves 5,000 steps. Furthermore, in the period after the revival condition is met, the fortress battle is revived when the special skill "Reviving a Cleared Event" is activated.

[0151] FIG. 10(b) is a conceptual diagram of a specific example of a skill management table. The skill management table is referenced when determining the type of fortress battle to be revived by a special skill. Specifically, in this modified example, the type of fortress battle to be revived changes depending on the number of steps taken by the user. Also, in this modified example, the number of steps required to revive a fortress battle changes depending on the number of times a special skill is executed (hereinafter simply referred to as the "number of executions") within a predetermined period (e.g., one day).

[0152] Specifically, if this is the first time a special skill has been used, Fortress Battle A can be revived when the user's number of steps reaches 5,000. Also, if this is the first time a special skill has been used, and the user's number of steps reaches 8,000, Fortress Battle B can be revived in addition to Fortress Battle A. Furthermore, if this is the first time a special skill has been used, and the user's number of steps reaches 15,000, Fortress Battle X can be revived in addition to Fortress Battle A and Fortress Battle B.

[0153] On the other hand, if the special skill is used for the second time, Fortress Battle A can be revived when the user's number of steps reaches 10,000. Also, if the special skill is used for the second time, Fortress Battle B can be revived in addition to Fortress Battle A when the user's number of steps reaches 15,000. However, if the special skill is used more than once, Fortress Battle X will not be revived. In other words, Fortress Battle X can only be revived once per day.

[0154] As described above, in this modified example, the more times the special skill is executed, the stricter the conditions for revival in the fortress battle become, and the fewer types of fortress battles that can be revived. Therefore, situations where the user has an excessive advantage are prevented. Note that in the modified example described above, the more steps the user takes, the more types of fortress battles that can be revived increase, and in addition (or instead), the revival time for the fortress battle may be extended.

[0155] (5) In each embodiment, when the rearrangement period has elapsed, each event can be executed even if the movement record and the like do not satisfy the revival conditions. In the above configuration, the movement record and the like may not be initialized when the rearrangement period has elapsed. For example, in the first embodiment, the movement step count ns may not be initialized when the rearrangement period has elapsed.

[0156] In addition, in the second embodiment, the walk points may not be initialized when the rearrangement period has elapsed. Furthermore, in the third embodiment, the resurrection items that have already been acquired may not be invalidated when the rearrangement period has elapsed. Similarly, in the modified example shown in FIG. 10(a) above, the number of steps traveled since the previous special skill activation may not be initialized when the rearrangement period has elapsed.

[0157] (6) In each mode, when an event associated with an event spot ves (fortress image Gf) is cleared, the type of event that is revived at the event spot ves is the same as the cleared event. However, it is also possible to have a configuration in which an event different from the cleared event can be revived.

[0158] For example, in the first embodiment described above, it is assumed that a fortress battle is held at an event spot ves where a fortress image Gf is placed. In the above configuration, when the number of steps ns of the user reaches a predetermined threshold value (8000 steps), a fortress battle A may be revived at the event spot ves regardless of the type of fortress battle that was cleared at the event spot ves.

[0159] In the above configuration, if the user moves another 8,000 steps after Fortress Battle A is revived at the event spot ves, Fortress Battle B may be made available to be executed at the event spot ves instead of Fortress Battle A. Furthermore, every time the user moves 8,000 steps, the fortress battles that can be executed at the event spot ves may change in order from Fortress Battle C to Fortress Battle X. In the above configuration, the fortress image Gf may be changed in accordance with the change in the fortress battles that can be executed. Specifically, the type of fortress monster notified by the fortress image Gf may be changed.

[0160] Furthermore, in the second embodiment, when a fortress revival ticket is used, the type of fortress battle corresponding to the fortress revival ticket may be revived regardless of the type of fortress battle actually cleared. For example, assume that fortress battle A is cleared at event spot ves. In the above case, when a fortress revival ticket for fortress battle B is used, fortress battle B may be revived at that event spot ves. Similarly, in the third embodiment, regardless of the type of fortress battle cleared at event spot ves, the fortress battle corresponding to the type of revival item obtained may be revived at that event spot ves.

[0161] Furthermore, a configuration may be used in which the user can specify from multiple types of events to revive at the event spot ves. For example, in the first embodiment, a configuration is assumed in which Fortress Battle A can be revived at the event spot ves when the user's number of steps ns reaches 8,000 steps, and either Fortress Battle A or Fortress Battle B can be revived at the event spot ves when the user's number of steps ns reaches 16,000 steps. In the above configuration, a configuration may be used in which the user can select whether to revive Fortress Battle A or Fortress Battle B when the user's number of steps ns reaches 16,000 steps.

[0162] The event that is revived at the event spot ves may be determined randomly. In the above configuration, the more steps the user takes, the more likely an event that is advantageous to the user is to be revived. Also, the revival time of the revived event may be randomly determined.

[0163] (7) In each embodiment, the actual travel history (e.g., the number of steps traveled) required to revive an event at an event spot ves may be changed depending on the distance from the character position Pv to the event spot ves. For example, the longer the distance from the character position Pv to the event spot ves, the greater the number of steps traveled required to revive the event at the event spot ves. In addition, in the above configuration, an event may be revived at an event spot ves located within the available range regardless of the number of steps traveled by the user.

[0164] (8) In each embodiment, a configuration may be adopted in which multiple events associated with different event spots ves can be revived at once.

[0165] For example, assume a configuration in which an event spot ves belongs to one of multiple groups. In the above configuration, when an event associated with an event spot ves is executed, events associated with other event spots ves that belong to the same group as the event spot ves become unable to proceed. In the above configuration, when an event associated with an event spot ves is revived, events associated with other event spots ves that belong to the same group as the event spot ves may also be revived.

[0166] Furthermore, in the second embodiment described above, a configuration is assumed in which a common fortress battle can be started at different event spots ves. In the above configuration, when a fortress revival ticket is used, the fortress battle corresponding to the fortress revival ticket may be revived at multiple (for example, all) event spots ves. Similarly, in the first embodiment, when the user's number of steps sn reaches a threshold (8000 steps) and the revival condition is met, the common fortress battle may be revived at multiple event spots ves.

[0167] (9) In the first embodiment described above, it is assumed that an event associated with the event spot vesx is executed, and then an event associated with another event spot vesy is executed. In the above case, the event associated with the event spot vesx and the event associated with the event spot vesy may be configured to be able to be restored separately.

[0168] For example, suppose that after performing an event associated with event spot vesx, the user moves 1000 steps and then performs an event associated with another event spot vesy. In this case, when the user moves 7000 steps after performing the event associated with event spot vesy, the number of steps traveled since performing the event associated with event spot vesx reaches 8000. In this modified example, the event associated with event spot vesx is revived when the user moves 8000 steps after performing the event.

[0169] Furthermore, when the user has moved another 1000 steps after the event associated with the event spot vesx is revived, the number of steps the user has taken since performing the event associated with the event spot vesy reaches 8000. In this modified example, the event associated with the event spot vesy is revived when the user has moved 8000 steps after performing the event.

[0170] (10) In each embodiment, when an event (for example, a fortress battle) is cleared, the event becomes unable to proceed (the first condition is satisfied). However, the occasion when the first condition of the present invention is satisfied is not limited to the above examples. For example, consider a configuration in which an upper limit on the number of attempts is set for each event. In the above configuration, when the number of attempts for an event reaches the upper limit, the event may become unable to proceed (the first condition is satisfied) even if the event cannot be cleared. In the above configuration, as in the other embodiments, when a second condition regarding movement in real space is satisfied (for example, when the user's number of steps reaches a predetermined threshold), the event becomes able to proceed again.

[0171] (11) In each embodiment, even if the second condition regarding movement in real space is satisfied, an event associated with a specific location may not be able to proceed (not be revived). For example, if the user's number of steps reaches a predetermined threshold (e.g., 8,000 steps), the event may be revived with a probability of less than 100% (e.g., approximately 50%). Furthermore, in the above configuration, the probability of the event being revived may be increased as the user's number of steps increases.

[0172] (12) In each embodiment, the type of event that can be revived at the event spot ves can be changed as appropriate. For example, the type of event (object) that can be placed at the event spot ves when the rearrangement period has elapsed may be the same as the type of event that can be revived at the event spot ves when the revival condition has been met. Also, the type of event that can be placed at the event spot ves when the rearrangement period has elapsed may be different from the type of event that can be revived at the event spot ves when the revival condition has been met.

[0173] For example, a configuration may be adopted in which a pre-transformation boss monster is first placed in an event spot ves, and if the boss monster is defeated, the transformed boss monster is revived in the event spot ves if a resurrection condition is subsequently met. In the above-described modified examples, a configuration in which the transformed boss monster is more difficult to defeat than the pre-transformation boss monster is preferable. Also, a configuration in which a more advantageous benefit is awarded to the user when defeating the transformed boss monster than when defeating the pre-transformation boss monster (for example, an advantageous item) is preferable. However, a configuration in which the benefit awarded to the user when defeating the transformed boss monster and when defeating the pre-transformation boss monster may be the same may also be adopted.

[0174] (13) In each embodiment, a specific example of the present invention applied to a location-based game has been described. However, the present invention may be applied to other than location-based games. For example, the present invention may be applied to a map service that helps a user reach a predetermined location (e.g., a store), a service that measures a user's movement history (number of steps traveled, distance traveled) to enable management of the user's health, a matching service that matches users, and a pedometer point service that awards points according to the number of steps a user takes.

[0175] The above-described embodiments may be appropriately combined, replaced with other configurations, partially deleted, or partially modified. Furthermore, publicly known technologies at the time of filing that are not described in this specification may be appropriately adopted.

[0176] <Summary of the functions and effects of the exemplary embodiments of the present invention> <First aspect> The program (PGx, PGy) of this embodiment is an event control means (11) that causes a computer (terminal device 10, management device 20) to make the event associated with a specific position (event spot res) in real space (Sr) unable to proceed (set to a cleared state) when the event (e.g., a fortress battle) associated with the specific position satisfies a first condition in virtual space (Sv), and makes the event associated with the specific position able to proceed when a second condition regarding movement in real space is satisfied. According to this embodiment, the excitement of the opportunity to revive a cleared event is increased.

[0177] <Second mode> In the program of this aspect, the second condition is that the user's travel record, which is the number of steps or distance traveled, reaches a predetermined threshold. According to this aspect, for example, by traveling around a specific location, an event can be performed multiple times without traveling far from the specific location. Therefore, even for users who find it difficult to travel far to perform an event, it is possible to easily perform the event multiple times.

[0178] <Third aspect> In the program of this aspect, the event control means enables a first event (Fortress Battle A) associated with a specific location when the movement record reaches a predetermined first threshold (12,500 steps, which earns 500 walk points), and enables a second event (Fortress Battle B) associated with a specific location when the movement record reaches a second threshold (50,000 steps, which earns 2,000 walk points), which is greater than the first threshold (see, for example, the second embodiment described above in Figures 7(a) and (b)). According to this aspect, the entertainment value of the service is improved compared to a configuration in which the events that are revived do not change depending on the number of steps traveled.

[0179] <Fourth aspect> In the program of this aspect, the event control means enables an event associated with a specific location to be executed when the user moves to a predetermined location in real space (for example, a location where a revival item can be obtained) (see, for example, the third embodiment described in FIGS. 8(a) and 8(b)). According to this aspect, for example, by enabling an event to be revived by moving to a location relatively close to the user's home location, it is possible to achieve the effect of making it easier for the user to execute an event multiple times without having to move far away.

[0180] <Fifth aspect> In the program of this aspect, the events that become executable when the second condition (revival condition) is satisfied are a predetermined portion of the events that can proceed in the virtual space (see, for example, the second embodiment described in FIG. 7(b)). According to this aspect, compared to a configuration in which all events can be revived, the inconvenience of the user being given an excessive advantage is suppressed.

[0181] <Sixth aspect> In the program of this aspect, an upper limit is set on the number of times an event can be executed when the second condition is satisfied (see, for example, the second embodiment described in FIG. 7(b)). According to this aspect, compared to a configuration in which there is no limit on the number of times an event can be revived, the inconvenience of the user gaining an excessive advantage is suppressed.

[0182] <Seventh aspect> The program of this aspect can restrict new events from being made executable when the second condition is met and an event becomes executable, even if the second condition is subsequently met again (see, for example, the fourth embodiment described with reference to FIGS. 9(a) to 9(c)). According to this aspect, the inconvenience of the user gaining an excessive advantage is suppressed compared to, for example, a configuration in which there is no limit to the number of events that can be revived at the same time.

[0183] <Eighth aspect> In the program of this aspect, the event control means disables the event if the conditions are met to enable the event, and the event is not progressed for a predetermined period of time after that. According to this aspect, the inconvenience of the user gaining an excessive advantage is suppressed compared to, for example, a configuration in which a revived event is maintained in an indefinitely clearable state.

[0184] <Ninth aspect> In the program of this aspect, the event control means allows an event associated with a specific location to proceed depending on the user's attributes (adult, minor) (see, for example, the third embodiment described in FIG. 8(b)). This aspect has the advantage that equality among users is more easily ensured compared to a configuration in which an event can be revived under uniform conditions regardless of the user's attributes.

[0185] <Tenth aspect> The information processing system (1) of this aspect includes an event control means for controlling a computer (terminal device 10, management device 20) to disable (set to a cleared state) an event (e.g., a fortress battle) associated with a specific location (event spot res) in real space (Sr) when the event satisfies a first condition in virtual space (Sv), and to enable (set to a cleared state) the event associated with the specific location when the event satisfies a second condition related to movement in real space. According to this aspect, the same effects as those of the first aspect described above can be achieved.

[0186] The problem-solving means configured by the above-mentioned program (for example, each configuration described in the appendix) can be appropriately diverted to an apparatus, a system, a method, an information recording medium, etc. [Explanation of symbols]

[0187] 1...information processing system, 10...terminal device, 11...event control means, 20...management device

Claims

1. Computer, an event control means for disabling the progress of an event associated with a specific position in real space when the event satisfies a first condition in the virtual space, and for enabling the progress of the event associated with the specific position when the event satisfies a second condition related to movement in real space; A program that functions as a

2. The second condition is that the user's travel record, which is the number of steps or distance traveled, reaches a predetermined threshold. The program according to claim 1.

3. The event control means When the movement record reaches a predetermined first threshold, a first event associated with a specific location is enabled; When the movement record reaches a second threshold value that is greater than the first threshold value, a second event associated with a specific location can be executed. The program according to claim 2.

4. The event control means When the user moves to a predetermined position in real space, an event associated with the specific position can be executed. The program according to claim 1.

5. The events that become executable when the second condition is satisfied are a predetermined part of the events that can proceed in the virtual space. The program according to claim 1.

6. An upper limit is set on the number of times the event can be executed when the second condition is met. The program according to claim 1.

7. When the second condition is satisfied and an event becomes executable, even if the second condition is satisfied again, a new event can be restricted from becoming executable. The program according to claim 1.

8. The event control means disables the event from proceeding if the second condition is satisfied and the event becomes executable, and the event is not proceeded for a predetermined period thereafter. The program according to claim 1.

9. The event control means enables the progress of an event associated with the specific location according to a user attribute. The program according to claim 1.

10. an event control means for disabling the progress of an event associated with a specific position in real space when the event satisfies a first condition in the virtual space, and for enabling the progress of the event associated with the specific position when the event satisfies a second condition related to movement in real space; An information processing system comprising:

Images