Program and system

Abstract

To provide a program capable of improving amusement.SOLUTION: In a case where a player proceeding with a first event satisfies a predetermined positional condition for a second event associated with a position, the program causes a computer to receive an operation associated with the second event from the player.SELECTED DRAWING: Figure 6

Description

[Technical Field]

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

[0002] Conventionally, so-called "location-based games" have been known in which events associated with positions in real space are placed on a field, and the events progress on the terminals of players who satisfy predetermined position conditions for the events (see, for example, Patent Documents 1 to 4). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 7280520 [Patent Document 2] Patent No. 6867595 [Patent Document 3] Patent No. 6860790 [Patent Document 4] Patent No. 6090495 Summary of the Invention [Problem to be solved by the invention]

[0004] However, in previous location-based games, if the location of a second event is passed while a first event is in progress, the second event cannot be progressed, and there is room for improvement in terms of increasing interest.

[0005] The present invention has been made in view of the above circumstances, and an object of the present invention is to provide a program that can increase interest. [Means for solving the problem]

[0006] In order to solve the above problem, the program of the present invention causes a computer to accept an operation related to the progress of a second event from a player who is progressing through a first event, when the player satisfies a predetermined position condition for a second event associated with the position. [Effects of the Invention]

[0007] According to the present invention, interest is increased. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a diagram illustrating an overview of a system according to an embodiment of the present invention. [Figure 2] FIG. 2 is a hardware configuration diagram of a server. [Figure 3] FIG. 2 is a hardware configuration diagram of a user terminal. [Figure 4] FIG. 1 is a plan view of the field. [Figure 5] 10 is an example of a field screen. [Figure 6] 10 is a flowchart of a first event control process. [Figure 7] 10 is an example of a solo battle screen. [Figure 8] 10 is a flowchart of a second event control process according to the first embodiment. [Figure 9] 10 is an example of a selection screen. [Figure 10] 10 is an example of reservation list data. [Figure 11] 10 is a screen example of a list screen. [Figure 12] 10 is an example of a raid battle screen. [Figure 13] 10 is a flowchart of a second event control process according to the second embodiment. [Figure 14] 11 is a flowchart of a second event control process according to the third embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] A system 1 according to an embodiment will be described below with reference to the drawings. Note that the embodiment of the present invention described below is an example of how the present invention can be realized, and the scope of the present invention is not limited to the scope of the described embodiment. Therefore, the present invention can be implemented by adding various modifications to the embodiment.

[0010] [System 1 Overview] FIG. 1 is a diagram illustrating an overview of a system 1 according to this embodiment. As shown in FIG. 1, the system 1 mainly includes a server 10 and user terminals 20A, 20B, 20C, and 20D (hereinafter, these may be collectively referred to as "user terminals 20"). Note that while four user terminals 20 are illustrated in FIG. 1, examples of the user terminals 20 included in the system 1 are not limited to this. The server 10 and the user terminals 20 are connected to each other so as to be able to communicate with each other via a communication network 2. Specific examples of the communication network 2 are not particularly limited, and may include, for example, the Internet, a mobile communication system (e.g., 4G, 5G, etc.), a wireless network such as Wi-Fi (registered trademark), or a combination of these.

[0011] The system 1 according to this embodiment is a game system that realizes a game on a user terminal 20. The game realized by the system 1 is, for example, an online game realized on each of the multiple user terminals 20 by mutual communication between the server 10 and the multiple user terminals 20. However, the game may also be an offline game that is completed on one user terminal 20. As another example, the system 1 may realize a virtual space in which users of multiple user terminals 20A to 20D communicate via avatars. Hereinafter, a user who operates a user terminal 20 to play a game (or moves an avatar in the virtual space) will be referred to as a "player."

[0012] [Server 10 configuration] FIG. 2 is a hardware configuration diagram of the server 10. The server 10 realizes an online game by synchronizing game data of each of a plurality of user terminals 20. The server 10 is realized by, for example, a general-purpose computer such as a workstation or a personal computer. As shown in FIG. 2, the server 10 mainly includes a processor 11, a memory 12, a storage 13, an input / output interface 14, and a communication interface 15. Each component of the server 10 is connected to a communication bus 19.

[0013] The processor 11 performs the processes described below by executing a series of instructions included in a server program 13P stored in the memory 12 or the storage 13. The processor 11 is realized as, for example, a central processing unit (CPU), a graphics processing unit (GPU), a micro processing unit (MPU), a field-programmable gate array (FPGA), or other devices.

[0014] The memory 12 temporarily stores a server program 13P and data. The server program 13P is loaded from, for example, the storage 13. The data includes data input to the server 10 and data generated by the processor 11. For example, the memory 12 is realized as a RAM (Random Access Memory) or other volatile memory.

[0015] The storage 13 permanently stores the server program 13P and data. The storage 13 is realized, for example, as a ROM (Read-Only Memory), a hard disk drive, a flash memory, or other non-volatile storage device. The storage 13 may also be realized as a removable storage device such as a memory card. As yet another example, the storage 13 may be connected to the server 10 as an external storage device instead of being built into the server 10. With this configuration, for example, in a situation where multiple user terminals 20 are used, such as an amusement facility, it becomes possible to collectively update the server program 13P and data.

[0016] The input / output interface 14 is an interface for connecting external devices such as a monitor, input device (e.g., keyboard, pointing device), external storage device, speaker, camera, microphone, sensor, etc. to the server 10. The processor 11 communicates with the external devices through the input / output interface 14. The input / output interface 14 is realized using, for example, a Universal Serial Bus (USB), a Digital Visual Interface (DVI), a High-Definition Multimedia Interface (HDMI (registered trademark)), or other terminals.

[0017] The communication interface 15 communicates with other devices (e.g., user terminal 20) connected to the communication network 2. The communication interface 15 is realized as, for example, a wired communication interface such as a LAN (Local Area Network), or a wireless communication interface such as Wi-Fi (Wireless Fidelity), Bluetooth (registered trademark), or NFC (Near Field Communication).

[0018] [Configuration of user terminal 20] The user terminal 20 is realized as, for example, an HMD (Head Mounted Display) set, a tablet terminal, a wearable device, smart glasses, a smartphone, a feature phone, a laptop computer, a desktop computer, etc. In this embodiment, an example of the user terminal 20 as a tablet terminal will be described as shown in FIG.

[0019] Fig. 3 is a hardware configuration diagram of the user terminal 20. As shown in Fig. 3, the user terminal 20 mainly includes a processor 21, a memory 22, a storage 23, a communication interface 25, a monitor 31, cameras 33 and 34, a microphone 35, a speaker 36, a motion sensor 41, a position sensor 42, and an operation device 43 (operation unit). Each component of the user terminal 20 is connected to a communication bus 29.

[0020] The processor 21, memory 22, storage 23, and communication IF 25 have the same configuration as the processor 11, memory 12, storage 13, and communication IF 15 of the server 10. The storage 23 also stores a terminal program 23P.

[0021] Monitor 31 is provided on the surface of a flat housing, as shown in Fig. 1, for example. Monitor 31 is a display device (display unit) that displays images or videos. Camera 33 is a so-called in-camera that is attached to the surface of the flat housing and captures an image of the face of a user viewing monitor 31. Camera 34 is a so-called out-camera that is attached to the back surface of the flat housing (the surface opposite to monitor 31) and captures an image of the surroundings.

[0022] The microphone 35 converts the user's speech into an audio signal (electrical signal) and outputs it. The speaker 36 converts the audio signal into sound and outputs it to the user. Note that the user terminal 20 may include earphones instead of the speaker 36.

[0023] The motion sensor 41 detects the motion of the housing (for example, rotation around three mutually orthogonal axes). The motion sensor 41 may be realized by, for example, an angular velocity sensor, a geomagnetic sensor, or an acceleration sensor.

[0024] The position sensor 42 detects the current location of the user terminal 20. Since the user terminal 20 is assumed to be carried by a user, the location of the user terminal 20 corresponds to the location of the user who carries the user terminal 20. The position sensor 42, for example, acquires a signal from a GPS (Global Positioning Satellite) and outputs information indicating the current location (hereinafter referred to as "current location information"). Specific examples of the current location information are not particularly limited, and may be, for example, a combination of the latitude and longitude of the current location. The user terminal 20 may calculate the number of steps, movement distance, and movement direction of the user using the detection results of the motion sensor 41 and the position sensor 42. The user terminal 20 may then proceed with an event, described below, triggered by at least one of the calculated number of steps, movement distance, and movement direction. The user's location may be identified using values ​​detected by an external device (sensor). For example, the results of detection by a photographing device or a position sensor (such as an infrared sensor) installed in a building may be used. Furthermore, a user may own multiple terminals (devices) and the location of the user may be identified by sharing the detection results of the sensors of the devices.

[0025] The operation device 43 accepts input (operation) of commands by the user to the user terminal 20. The operation device 43 is, for example, a touch panel that is superimposed on the monitor 31 and accepts various touch operations by the user. In other words, the monitor 31 according to this embodiment is a touch panel display unit. As another example, the user terminal 20 may be provided with a controller equipped with buttons, an operation stick, etc. as the operation device 43.

[0026] [Details of the games that System 1 realizes] The system 1 according to this embodiment provides, for example, a "location-based game." In a location-based game, an avatar moves on a field F (virtual space) corresponding to the real space in conjunction with the player's movement in the real space. In addition, in a location-based game, when an avatar (i.e., a player) satisfies a predetermined position condition for an event placed on the field F, the event progresses (starts) on the user terminal 20. Furthermore, in a location-based game, an event that satisfies a predetermined position condition can be reserved, and the reserved event can progress at a timing specified by the player.

[0027] "Field F" corresponds to, for example, the real space in which the user terminal 20 (i.e., the player) exists. Field F does not need to be completely identical to real space, but only needs to be similar enough that the player can feel that it is the "same place." Field F shares with real space, for example, the layout of major roads and intersections. On the other hand, field F does not need to coincide with real space in terms of buildings and places that are off-limits to anyone other than authorized personnel (e.g., highways, factories, etc.).

[0028] An "avatar" is, for example, a 3D object with a three-dimensional shape having three-dimensional coordinates. An avatar is an alter ego of a player that moves on the field F in conjunction with the player moving in real space. However, specific examples of avatars are not limited to those in the shape of a person, and may be animals, monsters, robots, vehicles, etc. Hereinafter, of the avatars displayed on a user terminal 20, an avatar operated by a player of that user terminal 20 will be referred to as a "player's avatar," and an avatar operated by another player will be referred to as an "other player's avatar."

[0029] An "event" may be anything that can be implemented in a location-based game, such as a battle event in which you battle an enemy character, an acquisition event in which you acquire an item, a viewing event in which you watch a movie (video), a facility event in which you enter a facility (e.g., an inn, weapon shop, church, dungeon, etc.), or a preparation event in which you change the state of your avatar (e.g., recovering stamina, changing your job or equipment, organizing your tools), etc. Furthermore, a battle event may include at least one of a solo battle, a raid battle, and a versus battle.

[0030] A "solo battle" is a battle event in which one player battles an enemy character alone. However, a "solo battle" may also include an event in which one player controls multiple avatars, or an event in which an avatar controlled by a player cooperates with an NPC (Non-Player Character) to battle an enemy character.

[0031] A "raid battle" is a battle event in which multiple players can cooperate to battle enemy characters. However, if only one player has expressed interest in participating in a raid battle, the enemy character may be battled by the player's own avatar alone, or by the player's own avatar and an NPC. However, any battle in which multiple players can participate may be included in the "raid battle." Furthermore, compared to solo battles, raid battles may be more difficult, occur less frequently, have a shorter time limit (described below), offer more experience points, or allow the acquisition of rare items.

[0032] A "competitive battle" is a battle event in which multiple players (typically, avatars) compete against each other. A competitive battle may be not only a one-on-one "PvP" battle, but also an m-on-n "GvG" battle, or a "free-for-all battle" in which all players fight against each other. Furthermore, the number of players (m, n) in a group in a GvG may be the same or different. Compared to solo battles, competitive battles may occur less frequently, may have a shorter time limit (described below), may offer more experience points, and may allow players to acquire rare items.

[0033] "Satisfying a predetermined location condition" may mean, for example, that an avatar (i.e., a player) has entered a predetermined area that includes the installation location of an event. As another example, "Satisfying a predetermined location condition" may mean that the installation location of an event has entered a predetermined area that includes the avatar. The specific shape of the predetermined area is not particularly limited, but it may be, for example, a circular area centered on the location of the event or the avatar. In other words, the event progresses when the avatar approaches the installation location of the event. However, the condition for progressing (starting) the event is not limited to a location condition, and may be other conditions such as the use of an item.

[0034] "Progressing an event" refers to, for example, displaying a battle screen (e.g., FIGS. 7 and 12) for battling an enemy character on the monitor 31, accepting the player's operations via the operation device 43 to instruct the player's avatar to perform actions (e.g., attack, activate a skill, use an item, etc.), attacking the enemy character in accordance with the accepted instructions, and repeating the process of updating the player's avatar's state in response to attacks from the enemy character. Other events also progress in a predetermined manner. Furthermore, while an event is in progress, the screen for that event is displayed on the monitor 31 instead of the field screen (FIG. 5). Therefore, the player cannot check the position of the avatar and the event on the field screen while the event is in progress.

[0035] "Reserving the progress of an event" means that, instead of progressing the event when a predetermined location condition is met or when an event in progress ends at the time the predetermined location condition is met, the event can be made to progress later at any timing designated by the player. Events that are reserved for progress are registered in a reservation list (Figure 10) described below.

[0036] Events implemented in the location-based game may be broadly divided into events that can be registered in the reservation list (reservable) and events that cannot be registered in the reservation list (unreservable). For example, among battle events, raid battles may be reservable, and solo battles may include both reservable and unreservable events. However, all events may be reservable.

[0037] [Game Overview] The server program 13P causes the server 10 (an example of a computer) to execute the following process, and the terminal program 23P causes the user terminal 20 (another example of a computer) to execute the following process, thereby realizing a game on the user terminal 20. The server 10 and the user terminal 20 identify an account to be used by the user before progressing through the game, and execute a process to progress through the game using the identified account. Note that if multiple accounts are selectable, the server 10 and the user terminal 20 identify an account to progress through from the multiple accounts, and then execute a process to progress through the game. Hereinafter, the server program 13P (terminal program 23P) causing the server 10 (user terminal 20) to execute a process will be simply referred to as "the server 10 (user terminal 20) executes a process." The following explanation will focus on a game realized on the user terminal 20A. Furthermore, a player playing the game on the user terminal 20A will be referred to as "player A."

[0038] For example, the user terminal 20A transmits current location information detected by the position sensor 42 to the server 10 via the communication IF 25 in order to associate the information with the ongoing account. In addition, the server 10 transmits, for example, field data indicating a field F including the current location indicated by the current location information received from the user terminal 20A and event data indicating an event to be placed in the field F to the user terminal 20A via the communication IF 15 in order to synchronize the information with the ongoing account.

[0039] FIG. 4 is a plan view of a field F. As shown in FIG. 4, the field data shows a field F (map) in which at least major roads corresponding to real space are arranged. The event data includes an event ID, a symbol image, an event type, an event location, an enemy character name, a time limit, and a reservation flag. However, the items included in the event data are not limited to the above-mentioned example. The following explanation will be given using a battle event as an example.

[0040] The event ID is an identifier that uniquely identifies an event. The event type indicates the type of event (e.g., solo battle, raid battle). The event location indicates the location on the field F to which the event is associated. The enemy character name indicates the name of the enemy character you will battle. The time limit indicates the time until the event disappears. In this embodiment, the time limit is in the form of the time at which the event disappears, but it may also be in the form of the time remaining from the current time until the event disappears. The reservation flag indicates whether the progress of the event can be reserved. More specifically, the reservation flag is set to either a first value "Yes" indicating that the event can be reserved, or a second value "No" indicating that the event cannot be reserved.

[0041] Fig. 5 is an example of a field screen. The user terminal 20A displays the field screen shown in Fig. 5 on the monitor 31 based on the field data and event data received from the server 10. The field screen displays a field F indicated by the field data. The field screen also displays the user's avatar A at a position on the field F corresponding to the user's current location detected by the position sensor 42.

[0042] Furthermore, symbols S1, S2, and S3 indicating the event positions of events E1, E2, and E3, respectively, are displayed on the field screen. The symbols S1, S2, and S3 may be arranged in positions that the user can specify arbitrarily, or may be fixed to predetermined event positions on the field F, or may move over time. When the time limit for events E1, E2, and E3 has elapsed, the corresponding symbols S1, S2, and S3 are erased from the field screen. However, depending on the current location and timing of avatar A, the event symbols may not be displayed on the field screen.

[0043] The user terminal 20A moves the player A's avatar A on the field F on the field screen in conjunction with the player A carrying the user terminal 20A moving in real space (i.e., the current location detected by the position sensor 42 is updated). Then, when the player A satisfies a predetermined position condition for an event arranged on the field F, the user terminal 20A enables the event to start.

[0044] A mode switching icon M may also be displayed on the field screen. The mode switching icon M is an icon for switching the game mode. The game modes include a manual mode (manual operation) in which the start of an event is instructed by player A, and an auto mode (automatic response) in which the start of an event is determined by the user terminal 20A. The game mode is switched every time player A selects the mode switching icon M. The currently selected game mode (i.e., "manual" or "auto") is displayed on the mode switching icon M.

[0045] The manual mode is a mode in which an event starts when, for example, player A, who has satisfied a predetermined position condition for the event, instructs the event to proceed (for example, by selecting symbols S1, S2, or S3). That is, the game according to this embodiment employs a so-called "symbol encounter system" in which a battle event starts in response to the selection of symbols S1, S2, or S3 displayed on the field screen. In addition, in the manual mode, the event may proceed by manual operation by player A, or the user terminal 20A may automatically proceed with the event, or the player A may switch between these modes. The manual mode is a mode suitable for when player A operates the user terminal 20A while remaining at his or her current location.

[0046] The auto mode is a mode in which, for example, when player A satisfies a predetermined location condition for an event, the user terminal 20A automatically starts the event without any instruction from player A. In the auto mode, the user terminal 20A automatically progresses the event. Furthermore, in the auto mode, when player A satisfies a predetermined location condition for an event that cannot be reserved, the event may be started immediately. On the other hand, in the auto mode, when player A satisfies a predetermined location condition for an event that can be reserved, the event may not be started immediately but may be registered in the reservation list. The auto mode is a mode suitable for when player A is moving with the user terminal 20A in his pocket or bag.

[0047] Furthermore, a list icon L may be displayed on the field screen. The list icon L is an icon that accepts an operation by player A to instruct a list screen (FIG. 11) to be described later to be displayed on the monitor 31. Details of the list screen will be described later with reference to FIG. 11.

[0048] [First event control process] FIG. 6 is a flowchart of the first event control process. FIG. 7 is an example of a solo battle screen. The first event control process is a process that continues from the start of the first event until the first event ends without satisfying a predetermined position condition for the second event, or until the predetermined position condition for the second event is satisfied during the progress of the first event. It is assumed that the field screen shown in FIG. 4 is displayed on the monitor 31 at the start of the first event control process.

[0049] In this embodiment, the first event control process will be described assuming that the user's avatar A moves from the current location to the destination along the dashed route in Figure 4. That is, the user's avatar A moves from the current location to the destination by passing through a predetermined area including symbols S1 and S3. Furthermore, the following process will be described assuming that the auto mode is selected, but this does not deny application to the case where the manual mode is selected.

[0050] Furthermore, assume that event E3 is a more valuable event than event E1, and player A is traveling to the destination in the hope of playing event E3. However, assume that player A continues traveling while event E1 (first event) is in progress, and ends up passing through a predetermined area that satisfies the location condition of event E3 (second event) before event E1 ends. Note that "valuable" may refer to low appearance frequency, a short time limit, high experience points that can be obtained, many items that can be obtained, high rarity of items that can be obtained, etc.

[0051] First, the user terminal 20A waits until the avatar A enters a predetermined range including the symbol S1 (S11: No) before executing the processes from step S12 onwards. Then, when the avatar A enters a predetermined range including the symbol S1 (S11: Yes), the user terminal 20A starts the event E1 (in this embodiment, a solo battle) associated with the symbol S1 (S12).

[0052] In step S12, the user terminal 20A displays the solo battle screen shown in FIG. 7 on the monitor 31. The solo battle screen includes the player's avatar A, enemy characters "ABC," a strength gauge G, an "attack" icon, an "item" icon, and an "escape" icon. The user terminal 20A then progresses the solo battle by accepting player A's operations on the solo battle screen via the operation device 43 (S13). In addition, in parallel with the progress of the solo battle, the user terminal 20A determines whether player A has satisfied predetermined position conditions for other events E2 and E3, based on the position of the user terminal 20A detected by the position sensor 42 (S14).

[0053] The vitality gauge G is an indicator that shows the maximum vitality and remaining vitality of the user avatar A. The remaining vitality of the user avatar A decreases when attacked by the enemy character "ABC" and increases when recovery skills or recovery items are used. The [Attack] icon is an icon that instructs the user avatar A to attack the enemy character "ABC". Attacks may include attacks using weapons, skills, or magic. The [Item] icon is an icon that instructs the user avatar A to use an item. The [Escape] icon is an icon that instructs the user to leave the battle with the enemy character "ABC" midway.

[0054] When user avatar A attacks enemy character "ABC", the remaining vitality of enemy character "ABC" decreases. On the other hand, when user avatar A is attacked by enemy character "ABC", user avatar A's remaining vitality decreases. If the remaining vitality of enemy character "ABC" reaches 0 before user avatar A's remaining vitality reaches 0, user avatar A wins and the solo battle ends. Furthermore, if user avatar A's remaining vitality reaches 0 before the remaining vitality of enemy character "ABC" reaches 0, user avatar A loses and the solo battle ends. Furthermore, if the [Escape] icon is selected before the remaining vitality of both user avatar A and enemy character "ABC" reaches 0, the solo battle ends without a winner being decided.

[0055] If event E1 ends at point X before player A satisfies a predetermined position condition for event E3 (S14: No & S13: Yes), the user terminal 20A ends the first event control process and causes the monitor 31 to again display the field screen (where avatar A's position has changed from FIG. 5). Then, if player A satisfies a predetermined position condition for event E3 on the field screen, the user terminal 20A causes the monitor 31 to display the raid battle screen shown in FIG. 12, and progresses with the event E3.

[0056] On the other hand, if player A satisfies a predetermined position condition for event E3 while event E1 is in progress (S13: No & S14: No), the user terminal 20A compares player A's movement speed with a predetermined threshold speed (S15). Player A's movement speed can be identified, for example, from the change over time in the current location output from the position sensor 42. The threshold speed is set, for example, to a speed at which player A can be evaluated as walking (in other words, not moving at high speed on a vehicle such as a bicycle, train, or car).

[0057] If the movement speed of player A is less than the threshold speed (S15: Yes), the user terminal 20A executes the second event control process (S16). On the other hand, if the movement speed of player A is equal to or greater than the threshold speed (S15: No), the user terminal 20A does not execute the second event control process and executes the processes from step S13 onwards again. The second event control process is a process of accepting an operation related to the progress of the second event from player A when player A, who is progressing through the first event, satisfies a predetermined position condition for the second event.

[0058] [Second event control process according to the first embodiment] FIG. 8 is a flowchart of the second event control process according to the first embodiment. FIG. 9 is an example of a selection screen. FIG. 10 is an example of reservation list data. FIG. 11 is an example of a list screen. FIG. 12 is an example of a raid battle screen.

[0059] The user terminal 20A displays the selection screen shown in FIG. 9 on the monitor 31 while the event E1 is in progress (in other words, before the event E1 ends) (S21). More specifically, the user terminal 20A pauses the progress of the event E1 and displays the selection screen on the monitor 31, superimposed on the solo battle screen. The selection screen is a screen for accepting operations related to the progress of the event E3 from player A. For example, as shown in FIG. 9, the selection screen includes the message "Do you want to challenge the enemy character "xyz"?", a symbol image of the enemy character "xyz", a "Quit" icon, a "Reserve" icon, and a "Challenge" icon.

[0060] The [Quit] icon is an icon for accepting an operation by player A to instruct not to proceed with event E3. The [Reserve] icon is an icon for accepting an operation by player A to instruct to reserve the progress of event E3. The [Challenge] icon is an icon for accepting an operation by player A to instruct to proceed with event E3. Then, the user terminal 20A accepts player A's operation on the selection screen (i.e., an operation related to the progress of event E3) through the operation device 43 (S22).

[0061] In step S21, the user terminal 20A notifies the player A, who is currently playing the event E1, that he or she has satisfied a predetermined position condition for the event E3. The method of notification is not particularly limited, and may include, for example, outputting a notification sound from the speaker 36 or vibrating a vibrator (not shown) mounted on the user terminal 20A. The order of displaying the selection screen and notifying the player A may be arbitrary, or they may be performed simultaneously.

[0062] Next, when the user terminal 20A receives an operation from player A selecting the [Quit] icon via the operation device 43 (S22: Quit), it resumes the progress of event E1 (S24) without executing the processes of steps S23 and S25 to S29. That is, the user terminal 20A erases the selection screen from the monitor 31 and resumes the progress of event E1 via the solo battle screen. Then, when event E1 has ended (S24: Yes), the user terminal 20A ends the second event control process and causes the field screen shown in FIG. 5 to be displayed again on the monitor 31.

[0063] Furthermore, when the user terminal 20A receives an operation from player A selecting the [reserve] icon via the operation device 43 (S22: reserve), it registers information identifying event E3 in the reservation list shown in Fig. 10 (S23). The information to be registered in the reservation list is not particularly limited, and may include, for example, the event ID "E3", a symbol image, an event position "x3, y3", an enemy character name "xyz", and a time limit "16:48". Registering the information about event E3 in the reservation list is an example of reserving event E3 so that event E3 will proceed at the timing specified by player A.

[0064] Next, the user terminal 20A clears the selection screen and resumes the progress of the event E1 (S24). Then, when the event E1 has ended (S24: Yes), the user terminal 20A causes the monitor 31 to display the field screen shown in FIG. 5 again. Furthermore, when the user terminal 20A receives, via the operation device 43, an operation by player A to select a list icon L on the field screen, the user terminal 20A causes the monitor 31 to display the list screen shown in FIG. 11. The list screen is a screen that allows player A to select one of the events registered in the reservation list. The list screen includes one or more event icons corresponding to the events registered in the reservation list. The event icon displays, for example, the symbol of the corresponding event, the name of the enemy character, the time limit, etc.

[0065] Next, the user terminal 20A starts event E3, for example, when it receives an operation from player A selecting the event icon for event E3 via the operation device 43. As one example, if another player has already started a raid battle, the user terminal 20A allows player A to join the raid battle midway. As another example, if the raid battle has not started and another player is already recruiting members for the raid (group), the user terminal 20A allows player A to join the raid. As yet another example, if the raid battle has not started and another player is not recruiting members for the raid, the user terminal 20A allows player A to recruit new members for the raid.

[0066] The user terminal 20A then starts the raid battle and displays the raid battle screen shown in FIG. 12 on the monitor 31. The raid battle screen differs from the solo battle screen in that it also displays other avatars B and C who are members of the raid, but is otherwise the same as the solo battle screen. The other avatars B and C are operated by players B and C of the other user terminals 20B and 20C. Note that the number of players participating in the raid battle is not limited to three. The user terminal 20A progresses the raid battle by accepting player A's operations on the raid battle screen via the operation device 43. Note that the raid battle differs from the solo battle in that avatars A, B, and C cooperate to attack the enemy character "xyz," but is otherwise the same as the solo battle.

[0067] On the other hand, when the user terminal 20A receives an operation from player A selecting the [Challenge] icon on the selection screen via the operation device 43 (S22: Challenge), it clears the selection screen and resumes the progress of event E1. Then, when event E1 ends, the user terminal 20A determines whether player A has won event E1 (S25), whether the time limit for event E3 has already elapsed when event E1 ends (S26), and whether player A is a threshold distance or more away from the event position of event E3 when event E1 ends (S27).

[0068] Then, if player A wins event E1, the time limit for event E3 has not yet elapsed, and the distance from the event location of event E3 to player A is less than the threshold distance (S25: Yes & S26: Yes & S27: Yes), the user terminal 20A causes player A to prepare to progress through event E3 before starting event E3 (S28). "Preparation to progress through event E3" includes, for example, changing avatar A's job or equipment, recovering stamina, organizing items, etc. Next, the user terminal 20A progresses event E3 (S29). The processing of step S29 is the same as the processing when an event icon is selected from the list screen of FIG. 11.

[0069] On the other hand, if player A loses or drops out of event E1 (S25: No), if the time limit for event E3 has already elapsed (S26: No), or if player A is more than the threshold distance away from the event location of event E3 (S27: No), the user terminal 20A skips the processing of steps S28 to S29 (i.e., does not progress event E3) and terminates the second event control processing.

[0070] [Effects of the first embodiment] According to the first embodiment, if the location condition for event E3 is satisfied while event E1 is in progress, event E3 can be progressed. This prevents loss of opportunities to play event E3 while maintaining the premise of the location-based game that the location condition for event E3 is satisfied. As a result, the interest of the game is improved.

[0071] Furthermore, according to the first embodiment, the selection screen is displayed while event E1 is in progress, allowing player A to quickly recognize that the positional condition for event E3 has been met. This allows player A, whose goal was event E3, to recognize that he has acquired the right to execute event E3, and to proceed with event E1 with peace of mind. As a result, the entertainment value of the game is further improved.

[0072] Furthermore, according to the first embodiment, the progress of the event E1 is paused while the selection screen is displayed, so that the opportunity to enjoy the event E1 is not deprived of the player A. This further enhances the entertainment value of the game. As another example, the event E1 may be continued while the selection screen is also displayed.

[0073] Furthermore, according to the first embodiment, when the [Challenge] icon on the selection screen is selected, event E3 proceeds after event E1 ends, so the interruption time of event E1 can be minimized, which further increases the interest of player A without impairing his or her immersion in the game.

[0074] Furthermore, according to the first embodiment, event E3 is progressed only if event E1 is won, so player A, whose goal is event E3, can also focus on playing event E1. This may make player A aware of new charms of the game that he or she has not yet noticed. However, event E3 may be progressed after event E1 ends, regardless of the outcome of event E1 (win, loss, or withdrawal midway) (i.e., step S25 may be omitted).

[0075] Furthermore, according to the first embodiment, if the time limit for event E3 has already elapsed when event E1 ends, event E3 is not allowed to proceed. This makes it possible to strike a balance between preventing the loss of an opportunity to play event E3 and preventing the value of event E3 from being diminished. However, the processing of step S26 can be omitted. Furthermore, the processing when the time limit for event E3 has elapsed is not limited to the example described above.

[0076] As another example, if the time limit for event E3 has elapsed when event E1 ends, the user terminal 20A may proceed with a third event of the same type as event E3 but associated with a different location than event E3. The same type as event E3 may refer to, for example, a battle with the same enemy character "xyz" as event E3, or the same "raid battle" as event E3. Furthermore, it is desirable to select an event located near player A's current location from among those located in a different location from event E3.

[0077] As yet another example, when the time limit for event E3 has elapsed at the time event E1 ends, user terminal 20A may reserve (i.e., register in the reservation list) the progress of a third event that will occur in the future in association with the same location as event E3. However, the reserved third event cannot proceed until the occurrence time has passed.

[0078] Furthermore, according to the first embodiment, if player A is further away from the event location of event E3 by the time event E1 ends than the threshold distance, event E3 is not allowed to proceed. This makes it possible to strike a balance between preventing the loss of an opportunity to play event E3 and preventing the value of event E3 from being diminished. However, the processing of step S27 can be omitted.

[0079] Furthermore, according to the first embodiment, by giving player A an opportunity to prepare before the start of event E3, player A can be made to play event E3 in the best possible condition. This further increases the interest of the game. However, the processing of step S28 can be omitted.

[0080] Furthermore, according to the first embodiment, when [Reserve] is selected on the selection screen, event E3 is registered in the reservation list and progressed at the timing designated by player A. This allows player A to calmly play event E3 after arriving at his or her destination, for example. As a result, the entertainment value of the game is further enhanced.

[0081] However, in the second event control process, whether to execute step S23 or steps S25 to S29 is not limited to being selected by player A. As another example, the selection screen (i.e., steps S21 to S22) may be omitted, and step S23 (or steps S25 to S29) may always be executed. As yet another example, step S23 may be executed when auto mode is selected, and steps S25 to S29 may be executed when manual mode is selected.

[0082] As another example, if the user terminal 20A does not accept any operation from player A until a predetermined time has elapsed since the selection screen was displayed, the user terminal 20A may execute the processing of step S23, omitting the operation by player A. As yet another example, if the orientation of the user terminal 20A when the selection screen is displayed is a predetermined orientation (an orientation that can be evaluated as indicating that player A is not looking at the monitor 31), the user terminal 20A may execute the processing of step S23, omitting the operation by player A. The orientation of the user terminal 20A can be detected by, for example, the motion sensor 41.

[0083] Furthermore, according to the first embodiment, if player A's moving speed at the time the position condition of event E3 is satisfied is equal to or greater than a threshold speed, the second event control process is not executed. As a result, if player A is moving at high speed by bicycle, train, car, or the like, the right to play event E3 is not granted. As a result, it is possible to prevent player A from being granted an excessive number of opportunities to play event E3, which would deviate from the purpose of the position-based game. However, the process of step S15 can be omitted.

[0084] Furthermore, according to the first embodiment, by notifying a player who is currently playing event E1 that he has satisfied the position condition for event E3, player A, who was looking forward to playing event E3, can be made aware that he has been granted the right to play event E3. This further increases the entertainment value of the game. However, this notification can be omitted.

[0085] [Second event control process according to the second embodiment] 13 is a flowchart of the second event control process according to the second embodiment. Note that a detailed description of the commonalities with the first embodiment will be omitted, and the description will focus on the differences. In the second event control process according to the second embodiment, the process of step S24 is omitted, and the execution timing of the processes of steps S25 to S27 differs from that of the first embodiment. On the other hand, the contents of the processes of steps S21 to S23 and S25 to S29 are common to the first and second embodiments.

[0086] The user terminal 20A according to the second embodiment progresses the first event started in step S12 until it is completed. Then, if player A wins event E1, the time limit for event E3 has not yet elapsed, and the distance from the event location of event E3 to player A is less than the threshold distance (S25: Yes & S26: Yes & S27: Yes), the user terminal 20A executes the process of step S21.

[0087] That is, after event E1 ends, user terminal 20A accepts from player A an operation related to the progress of event E1. Furthermore, if the time limit for event E3 has already elapsed when event E1 ends, user terminal 20A does not accept from player A an operation related to the progress of event E3. Furthermore, if player A is away from the event position of event E3 by a threshold distance or more when event E1 ends, user terminal 20A does not accept from player A an operation related to the progress of event E3.

[0088] According to the second embodiment, the ongoing event E1 is not interrupted to display the selection screen, so that the sense of immersion of player A in event E1 is not lost. Note that in Figure 13, at least one of steps S26, S27, and S29 can be omitted. Also, in Figure 13, whether step S23 or steps S28 to S29 are executed may be the same as in the first embodiment.

[0089] [Second event control process according to the third embodiment] 14 is a flowchart of the second event control process according to the third embodiment. Note that a detailed description of the commonalities with the first embodiment will be omitted, and the description will focus on the differences. The second event control process according to the third embodiment differs from the first embodiment in that the processes of steps S25 to S27 are omitted and step S30 is added. On the other hand, the contents of the processes of steps S21 to S24 and S28 to S29 are common to the first and third embodiments.

[0090] When the [Challenge] icon is selected on the selection screen displayed after event E1 is suspended (S22: Challenge), the user terminal 20A according to the third embodiment executes the processes of steps S28 to S29 while event E1 is suspended (i.e., proceeds with event E3). After event E3 ends, the user terminal 20A resumes event E1 (S30). Note that it is preferable that the user terminal 20A resumes event E1 by restoring the status of avatar A to the state it was in when it was suspended (i.e., at the time of S21).

[0091] As one example, if Avatar A's level increases during play of event E3, the level can be restored to the level at the time of interruption and event E1 can be resumed. As another example, if Avatar A's stamina or the number of items in his possession decreases during play of event E3, the stamina and number of items can be restored to the levels at the time of interruption and event E1 can be resumed. As yet another example, if the job or equipment was changed in step S28, the job and equipment can be restored to the level at the time of interruption and event E1 can be resumed.

[0092] According to the third embodiment, event E3 is inserted during the progress of event E1, allowing player A to play his / her intended event E3 as soon as possible, and preventing the time limit from being exceeded and losing the opportunity to play. This further enhances the entertainment value of the game. Furthermore, event E1 is resumed by returning to the state at the time of interruption, allowing each of events E1 and E3 to be played in perfect condition. Note that in FIG. 14, at least one of steps S23-S24 and step S29 can be omitted.

[0093] Furthermore, the first or second embodiment and the third embodiment may be switched and executed depending on the priority of the first event and the second event. That is, if the priority of the first event is higher than that of the second event, the first or second embodiment may be executed. On the other hand, if the priority of the first event is lower than that of the second event, the third embodiment may be executed. Note that a high priority of an event may refer to, for example, a low appearance frequency, a short time limit, a high amount of experience points that can be acquired, a large number of items that can be acquired, or a high rarity of items that can be acquired. For example, the priority of a solo battle may be set lower than that of a raid battle.

[0094] Although the embodiment has been described above using a location-based game, it may also be applied to various application services that use location information, such as fitness applications and training applications.

[0095] [Other variations] Furthermore, the program according to the present invention is not limited to a single program, but may be a collection of multiple programs. Furthermore, the program according to the present invention is not limited to one executed by a single device, but may be shared and executed by multiple devices. Furthermore, the division of roles between the server 10 and the user terminal 20 is not limited to the example described above. That is, part of the processing of the server 10 may be executed by the user terminal 20, or part of the processing of the user terminal 20 may be executed by the server 10.

[0096] Furthermore, some or all of the means implemented by the program can be implemented by hardware such as an integrated circuit. Furthermore, the program may be provided recorded on a non-transitory recording medium that can be read by a computer. Examples of recording media include hard disks, SD cards, DVDs, and servers on the Internet.

[0097] [Note] Some of the features of the present invention are summarized below. [assignment] For example, the present invention aims to improve entertainment value. [Solution] (1) A program that causes a computer to accept an operation related to the progress of a second event from a player who is progressing through a first event when the player satisfies a predetermined position condition for a second event associated with the position. (2) In the program described in (1) above, a program that causes the computer to use an automatic response to accept an operation related to the progress of the second event from the player while the first event is in progress; (3) In the program described in (2) above, a program that causes the computer to suspend the progress of the first event while accepting an operation related to the progress of the second event from the player; (4) In the program described in (2) above, a program that causes the computer to progress the second event after the first event has ended, when an operation to progress the second event is accepted from the player; (5) In the program described in (4) above, the first event is a battle event in which the player battles an enemy character; a program that causes the computer to proceed with the second event if the first event is won; (6) In the program described in (4) above, a program for causing the computer to not proceed with the second event if the time limit for the second event has elapsed at the time the first event ends; (7) In the program described in (4) above, A program that causes the computer to progress a third event that is associated with a different position from the second event and is the same type as the second event, if the time limit for the second event has elapsed when the first event ends. (8) In the program described in (4) above, a program that causes the computer to reserve the progress of a third event that will occur in the future and be associated with the same position as the second event, if the time limit for the second event has elapsed when the first event ends. (9) In the program described in (4) above, A program that causes the computer to not progress the second event if, at the time the first event ends, the player is away from a position associated with the second event by a threshold distance or more. (10) In the program described in (3) above, The computer, when an operation to proceed with the second event is received from the player, proceeding with the second event while suspending the first event; A program that restarts the first event after the second event has ended. (11) In the program described in (10), A program that causes the computer to return to a state at the time when the first event was interrupted and resume the first event. (12) In the program described in (1) above, a program that causes the computer to accept, after the first event has ended, an operation related to the progress of the second event from the player; (13) In the program described in (12), a program that causes the computer to not accept an operation related to the progress of the second event from the player if the time limit for the second event has elapsed at the time the first event ends. (14) In the program described in (1), a program causing the computer to, when receiving an operation from the player to progress the second event, make the player execute preparations to progress the second event before starting the second event. (15) In the program described in (1), a program that, when an operation to reserve the progress of the second event is accepted from the player, causes the computer to progress the second event at a timing designated by the player. (16) In the program described in (1), A program that causes the computer to not accept an operation related to the progress of the second event if the player's movement speed at the time when a predetermined position condition for the second event is satisfied is equal to or greater than a threshold speed. (17) In the program described in (1), a program that causes the computer to notify that the player who is currently playing the first event has satisfied a predetermined position condition for the second event. (18) A system that, when a player who is progressing through a first event satisfies a predetermined position condition for a second event associated with a position, accepts an operation related to the progress of the second event from the player. The solution constituted by the above program may be appropriately applied to the fields of devices, systems, methods, and media. [Action and effect] According to the above solutions (1) and (18), for example, it is possible to prevent the loss of an opportunity to play the second event while maintaining the premise of the position information game that the position condition of the second event is satisfied. According to the above solution (2), for example, it is possible to make the player quickly recognize that the position condition of the second event has been satisfied. According to the above solution (3), for example, it is possible to prevent the player from being deprived of an opportunity to enjoy the first event. According to the above solution (4), for example, the interruption time of the first event can be minimized, so that the player's immersion in the game is not impaired and the interest is further increased. According to the above solution (5), for example, it is possible to have a player who is aiming for the second event concentrate on playing the first event. According to the above solution (6), for example, it is possible to balance between preventing the loss of opportunities to play the second event and preventing the value of the second event from being diminished. According to the above solution (7), for example, it is possible to give priority to preventing the loss of opportunities to play the second event. According to the above solution (8), for example, it is possible to give priority to preventing the loss of opportunities to play the second event without departing from the purpose of the position information game. According to the above solution (9), for example, it is possible to balance between preventing the loss of opportunities to play the second event and preventing the value of the second event from being diminished. According to the above solution (10), for example, a player who has been aiming for the second event can be given an opportunity to play early. According to the above solution (11), for example, the first event and the second event can be played in perfect condition. According to the above solution (12), for example, it is possible to prevent the player's immersion in the first event from being lost. According to the above solution (13), for example, it is possible to balance between preventing the loss of opportunities to play the second event and preventing the value of the second event from being diminished. According to the above solution (14), for example, it is possible to allow the player to play the second event in the best possible condition. According to the above solution (15), for example, player A can play the second event calmly. According to the above solution (16), for example, it is possible to prevent excessive opportunities to play the second event from being given to the player, to the extent that it deviates from the purpose of the position information game. According to the above solution (17), for example, a player who has been looking forward to playing the second event can be made aware that he or she has been granted the right to play the second event. [Explanation of symbols]

[0098] 1...system, 2...communication network, 10...server, 11,21...processor, 12,22...memory, 13,23...storage, 13P...server program, 14...input / output interface, 15,25...communication interface, 19,29...communication bus, 20...user terminal, 23P...terminal program, 31...monitor, 33,34...camera, 35...microphone, 36...speaker, 41...motion sensor, 42...position sensor, 43...operation device

Claims

1. A program that causes a computer to accept, when a player who is progressing a first event satisfies a predetermined position condition for a second event associated with a position, an operation related to the progress of the second event from the player.

2. 2. The program according to claim 1, a program that causes the computer to use an automatic response to accept an operation related to the progress of the second event from the player while the first event is in progress.

3. 3. The program according to claim 2, a program that causes the computer to suspend the progress of the first event while accepting an operation related to the progress of the second event from the player;

4. 3. The program according to claim 2, a program causing the computer to progress the second event after the first event has ended, when an operation to progress the second event is accepted from the player;

5. 5. The program according to claim 4, the first event is a battle event in which the player battles an enemy character; a program that causes the computer to proceed with the second event if the first event is won;

6. 5. The program according to claim 4, A program that causes the computer to progress a third event that is associated with a different position from the second event and is the same type as the second event, if the time limit for the second event has elapsed at the time the first event ends.

7. 5. The program according to claim 4, A program that causes the computer to reserve the progress of a third event that will occur in the future in association with the same position as the second event if the time limit for the second event has elapsed at the time the first event ends.

8. 5. The program according to claim 4, A program that causes the computer to not progress the second event if, at the time the first event ends, the player is away from a position associated with the second event by a threshold distance or more.

9. 4. The program according to claim 3, The computer, when an operation to proceed with the second event is received from the player, proceeding with the second event while suspending the first event; The program restarts the first event after the second event has ended.

10. 10. The program according to claim 9, A program that causes the computer to return to a state at the time when the first event was interrupted and resume the first event.

11. 2. The program according to claim 1, a program that causes the computer to accept, after the first event has ended, an operation related to the progress of the second event from the player;

12. 2. The program according to claim 1, a program causing the computer to, when receiving an operation from the player to progress the second event, make the player execute preparations to progress the second event before starting the second event.

13. 2. The program according to claim 1, a program that, when an operation to reserve the progress of the second event is accepted from the player, causes the computer to progress the second event at a timing designated by the player.

14. 2. The program according to claim 1, A program that causes the computer to not accept an operation related to the progress of the second event if the player's movement speed at the time when a predetermined position condition for the second event is satisfied is equal to or greater than a threshold speed.

15. 2. The program according to claim 1, a program that causes the computer to notify that the player currently playing the first event has satisfied a predetermined position condition for the second event;

16. A system that, when a player who is progressing a first event satisfies a predetermined position condition for a second event associated with a position, accepts an operation related to the progress of the second event from the player.

Images