Programs and Systems

Abstract

The present invention aims to enhance the player's enjoyment. [Solution] The program causes the computer to function as a generation means for generating a virtual map in the game that corresponds to the real space based on the player's position information in the real space, and a position update means for moving a first object placed in a first area on the virtual map to a second area different from the first area, according to predetermined movement conditions, and when moving the first object to the second area, the program moves the first object to the second area while maintaining predetermined parameters of the first object that were affected by a second object different from the first object in the first area.

Description

Technical Field

[0004] , , , , , , , , , , ,

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

Background Art

[0002] Conventionally, a so-called "location information game" is known, in which an avatar is moved in a virtual space corresponding to the real space following the movement of a player in the real space, and an event is generated when the avatar satisfies a predetermined positional relationship with an object arranged in the virtual space (see, for example, Patent Documents 1 and 2). Further, in games for smartphones and online games, an event (raid boss event) in which a powerful enemy character (so-called raid boss) is defeated as a multi-player event in which a large number of players cooperate is widely implemented (see, for example, Patent Document 3).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Patent Document 2

Patent Document 3

Summary of the Invention

Problems to be Solved by the Invention

[0004] As described above, in raid boss events, the raid boss appears only at a specific location for a limited time, and players must access that location within that time and cooperate with other players to fight the raid boss. Therefore, players need to be in a specific place at a specific time, which created a problem of high barriers to participation. In addition, in raid boss events, the boss may appear at a single location, or even if it appears at multiple locations, each battle is independent, and the outcome of a battle at one location does not affect battles at other locations, which can easily lead to monotonous gameplay.

[0005] This invention has been made in view of the above circumstances, and its purpose is to provide a game that allows players to feel a sense of cooperation with other players while easing the restrictions on players participating in multiplayer events, especially raid boss battles, and thereby increasing player enjoyment. [Means for solving the problem]

[0006] To solve the aforementioned problems, the program according to the present invention provides a computer that functions as a generation means for generating a virtual map in the game that corresponds to the real space based on the player's position information in the real space, and a position update means for moving a first object placed in a first area on the virtual map to a second area different from the first area, according to predetermined movement conditions, and when moving the first object to the second area, it maintains predetermined parameters of the first object that were affected by a second object different from the first object in the first area, while moving the second area of The first object is placed within the area. Furthermore, a second object that has influenced the first object within the first area cannot influence the first object located within the second area. . [Effects of the Invention]

[0007] According to the present invention, it is possible to provide a game in which players can feel a sense of cooperation with other players while relaxing the restrictions on players participating in multiplayer events, especially raid boss battles, thereby increasing player enjoyment. [Brief explanation of the drawing]

[0008] [Figure 1] This diagram shows an overview of the system according to this embodiment. [Figure 2] This is a hardware configuration diagram for the server. [Figure 3] This is a hardware configuration diagram of the user terminal. [Figure 4] This is a functional block diagram of the user terminal. [Figure 5] This is a diagram showing the database of monster tables. [Figure 6] This figure shows the database of the deck table according to the first embodiment. [Figure 7] This is a flowchart of the event control process. [Figure 8] This is an example of a field screen. [Figure 9] This is an example of the deck selection screen. [Figure 10] This is an example of the deck editing screen according to the first embodiment. [Figure 11] This is an example of the battle screen in manual control mode. [Figure 12] This is an example of the deck confirmation screen. [Figure 13] This is an example of the battle screen in automatic response mode. [Figure 14] This is a diagram showing the map table database. [Figure 15] This is an example of the map selection screen. [Figure 16] This is a functional block diagram of the server according to the second embodiment. [Figure 17] This figure shows the movement condition table according to the second embodiment. [Figure 18]It is a diagram showing the monster M table according to the second embodiment. [Figure 19] It is a flowchart of the raid boss event control process of the second embodiment. [Figure 20] It is a screen example for explaining the case where the monster M appears in area A in the second embodiment. [Figure 21] It is a screen example for explaining the case where the monster M appears in area B in the second embodiment. [Figure 22] It is a screen example for explaining the case where the monster M appears in area C in the second embodiment.

Modes for Carrying Out the Invention

[0009] Hereinafter, the system 1 according to the embodiment will be described based on the drawings. Note that the embodiments of the present invention described below are examples when embodying the present invention, and do not limit the scope of the present invention to the scope of the description of the embodiments. Therefore, the present invention can be implemented with various modifications to the embodiments.

[0010] [Overview of System 1] FIG. 1 is a diagram showing an overview of the system 1 according to the present embodiment. As shown in FIG. 1, the system 1 mainly includes a server 10 and a user terminal 20. Although one user terminal 20 is shown in FIG. 1, the example of the user terminal 20 included in the system 1 is not limited to this. The server 10 and the user terminal 20 are connected to be able to communicate with each other via a communication network 2. A specific example of the communication network 2 is not particularly limited, but for example, it is composed of the Internet, a mobile communication system (for example, 4G, 5G, etc.), a wireless network such as Wi-Fi (registered trademark), or a combination thereof.

[0011] System 1 according to this embodiment is a game system that implements a game on a user terminal 20. The game implemented by System 1 is, for example, an online game implemented on the user terminal 20 through mutual communication between the server 10 and the user terminal 20. However, the game may also be an offline game that is completed on a single user terminal 20.

[0012] Hereafter, the user who operates user terminal 20 to play the game will be referred to as the "player." Furthermore, the object (character) that acts as the player's avatar in the virtual space will be referred to as the "avatar."

[0013] [Server 10 Configuration] Figure 2 is a hardware configuration diagram of server 10. Server 10 enables online games by synchronizing game data from user terminals 20. Server 10 is implemented using a general-purpose computer such as a workstation or personal computer. As shown in Figure 2, server 10 mainly consists of a processor 11, memory 12, storage 13, input / output interface 14, and communication interface 15. Each component of server 10 is connected to the communication bus 19.

[0014] The processor 11 performs the processing described later by executing a series of instructions contained in the server program 13P stored in memory 12 or storage 13. The processor 11 can be implemented as, for example, a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), an MPU (Micro Processing Unit), an FPGA (Field-Programmable Gate Array), or other device.

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

[0016] Storage 13 permanently holds the server program 13P and data. Storage 13 can be implemented as, for example, ROM (Read-Only Memory), a hard disk drive, flash memory, or other non-volatile storage device. Alternatively, storage 13 may be implemented as a removable storage device, such as a memory card. In yet another example, instead of being built into the server 10, storage 13 may be connected to the server 10 as an external storage device. With such a configuration, for example, in a scenario where multiple user terminals 20 are used, such as in an amusement facility, it becomes possible to update the server program 13P and data all at once.

[0017] The input / output interface 14 is an interface for connecting external devices such as monitors, input devices (e.g., keyboards, pointing devices), external storage devices, speakers, cameras, microphones, and sensors to the server 10. The processor 11 communicates with external devices through the input / output interface 14. The input / output interface 14 can be implemented using, for example, USB (Universal Serial Bus), DVI (Digital Visual Interface), HDMI (Registered Trademark) (High-Definition Multimedia Interface), or other terminals.

[0018] The communication interface 15 communicates with other devices (e.g., user terminal 20) connected to the communication network 2. The communication interface 15 can be implemented as 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).

[0019] [Configuration of User Terminal 20] The user terminal 20 can be implemented 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, or a desktop computer. In this embodiment, an example of the user terminal 20 as a tablet terminal is described, as shown in Figure 1.

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

[0021] The configuration of the processor 21, memory 22, storage 23, and communication interface 25 is the same as that of the server 10's processor 11, memory 12, storage 13, and communication interface 15. The storage 23 also stores the terminal program 23P.

[0022] The monitor 31 is mounted on the surface of a flat casing, as shown in Figure 1, for example. The monitor 31 is a display device (display unit) that displays images or videos. The camera 33 is mounted on the surface of the flat casing and is a so-called in-camera that captures the face of the user viewing the monitor 31. The camera 34 is mounted on the back of the flat casing (the side opposite the monitor 31) and is a so-called out-camera that captures the surroundings.

[0023] 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. The user terminal 20 may include earphones instead of the speaker 36.

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

[0025] The position sensor 42 detects the current location of the user terminal 20. Since it is assumed that the user terminal 20 is in the possession of the user, the location of the user terminal 20 corresponds to the location of the user possessing the user terminal 20. The position sensor 42, for example, acquires signals from a GPS (Global Positioning Satellite) and outputs information indicating the current location (hereinafter referred to as "current location information"). The specific examples of current location information are not particularly limited, but for example, it may be a combination of the latitude and longitude of the current location.

[0026] The user terminal 20 may use the detection results of the motion sensor 41 and the position sensor 42 to calculate the user's step count, distance traveled, and direction of movement. The user's location may also be determined using values ​​detected by external devices (sensors). For example, the results detected by imaging equipment or position sensors (such as infrared sensors) placed in the building could be used. Alternatively, the user may own multiple terminals (devices) and determine their location by sharing the detection results of sensors between these devices.

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

[0028] [Details of the game implemented by System 1] System 1 according to this embodiment provides, for example, a "location-based game." In the location-based game, avatar A moves on a field F (virtual space) corresponding to the real space in conjunction with the player's movement in the real space. Furthermore, in the location-based game, when avatar A (i.e., the player) meets predetermined location conditions in response to an event placed on field F, the event occurs on the user terminal 20. The following description will focus on the game implemented on the user terminal 20.

[0029] Furthermore, Avatar A moving on Field F in conjunction with (following) the player moving in the real world is an example of Avatar A moving in the virtual world in accordance with the player's movement in the real world. However, the direction of movement, speed of movement, and distance of movement of the player in the real world and Avatar A in the virtual world do not necessarily have to be exactly the same. In addition, Avatar A may move in the virtual world not only in accordance with the player's movement in the real world, but also in accordance with the player's operations through the control device 43. In other words, "a user operating Avatar A" may include either or both of the following: the player holding the user terminal 20 moving, or the player operating the control device 43 of the user terminal 20.

[0030] "Field F" is a virtual space that corresponds to the real-world space where, for example, user terminal 20 (i.e., the player) exists. Field F does not need to be exactly the same as the real-world space; it only needs to be similar enough that the player can perceive it as the "same place." For example, the layout of major roads and intersections in Field F is the same as in the real-world space. On the other hand, buildings and areas inaccessible to unauthorized persons (e.g., highways, factories) in Field F do not need to match those in the real-world space. The shape of Field F is defined by field data. More specifically, the field data indicates the shape of Field F (e.g., roads, buildings, parks, etc.) and includes information indicating its correspondence with the real-world space (e.g., latitude and longitude). Avatar A and various objects are also placed in Field F.

[0031] An "avatar" is, for example, a 3D object with a three-dimensional shape and coordinates. Avatar A is a representation of the player moving in the virtual space, reflecting the player's movement in the real world. However, the specific example of Avatar A is not limited to a human form; it may also be an animal, monster, robot, vehicle, etc. Hereinafter, among the Avatar A displayed on the user terminal 20, the avatar operated by the player on that user terminal 20 will be referred to as the "player's avatar." The appearance, shape, possessions (e.g., weapons, armor, accessories), job (e.g., tank, attacker, archer, healer, wizard), status (e.g., attack power, defense power, stamina, skills, speed, etc.), and current location on field F of Avatar A are defined by the avatar data.

[0032] An "event" can be anything that can be implemented in a location-based game, such as a battle event where you fight an enemy character, an item acquisition event where you obtain an item, a movie (video) viewing event, a facility event where you enter a facility (such as an inn, weapon shop, church, or dungeon), or a preparation event where you change the state of your avatar (such as recovering health, changing your job or equipment, or organizing your items).

[0033] Battle events (sometimes simply referred to as "battles") progress through actions taken by Avatar A and enemy characters (e.g., attacking, activating skills, using items, etc.). The battle event ends when the health of either Avatar A or the enemy character decreases due to an action by the other, and either Avatar A or the enemy character's health reaches 0. Other events also progress in predetermined ways.

[0034] An "object" refers to anything that can be placed on Field F (for example, Avatar A, Monsters S1-S3, Items I11-I13, as well as symbols representing dungeons and facilities). An object is a 3D object that represents the shape of the corresponding thing. An object may be fixed on Field F or may move within Field F. The object's appearance, characteristics, position, status, and current location on Field F are defined by the object data.

[0035] However, the games provided by System 1 are not limited to location-based games. As another example, System 1 may provide a game in which an avatar acts (moves, battles) on Field F, reflecting the actions of an operator via the control device 43. In this case, Field F does not necessarily correspond to real space. Furthermore, System 1 may provide so-called "MMO" or "MO" type games in which multiple avatars operated by different players act on a common Field F (i.e., multiple players share a common virtual space). In addition, System 1 may provide so-called "single-player" type games in which only the avatar operated by the player on the user terminal 20 acts on Field F.

[0036] [Functional block diagram of user terminal 20] Figure 4 is a functional block diagram of the user terminal 20. As shown in Figure 4, the terminal program 23P loaded into memory 22 causes the user terminal 20 (computer) to function as a storage means 210, a selection means 220, and a progress means 230. The user terminal 20 may also be equipped with other control means (for example, control means for progressing a location-based game). The functional blocks of the user terminal 20 will be described below.

[0037] The storage means 210, for example, allows the player to store a deck record (deck data) indicating the deck selected by the player via the operating device 43 in the storage 23. More specifically, the storage means 210 associates the deck name, deck, and label selected by the player via the deck editing screen (described later) with the deck ID assigned by the terminal program 23P and registers them in the deck table.

[0038] The selection means 220 allows the player to select, for example, a manual operation mode and an automatic response mode, as described later, via the operation device 43. Furthermore, if a battle event occurs while the manual operation mode is selected, the selection means 220 selects a deck previously chosen by the player before the battle event occurred. On the other hand, if a battle event occurs while the automatic response mode is selected, the selection means 220 selects a deck from among multiple decks stored in the storage means 210 that is compatible with the event that occurred. Additionally, the selection means 220 may present the selected deck to the player via the monitor 31.

[0039] The progression means 230 advances the battle event, for example, by using the deck selected by the selection means 220. As an example, the progression means 230 may advance the event according to instructions from the player via the operation device 43. As another example, the progression means 230 may advance the event automatically according to predetermined rules, without relying on instructions from the player. The battle event also includes a so-called raid boss event in which multiple players participate in a battle against a predetermined boss monster (raid boss). The progression means 230 may advance the raid boss event based on information about the appearance of the raid boss.

[0040] [First Embodiment] [Explanation of the Monster Table] Figure 5 shows an example of monster table data. The storage 13 of server 10 stores the monster table shown in Figure 5. The monster table is data that indicates monsters that can be opponents in battle events. The monster table contains one or more monster records (monster data). A monster record indicates the content of an event (battle event). A monster record includes, for example, a monster ID, a symbol image, a status, and monster attributes.

[0041] The Monster ID uniquely identifies the monster (battle event). The Symbol Image is the image of the monster displayed on monitor 31. The Status indicates the monster's stats in the battle event (e.g., attack power, defense power, stamina, skills, speed, and other ability values). The Monster Attribute indicates the type of monster to which the monster belongs (e.g., demon, insect, slime, dragon, material).

[0042] Multiple monsters that share common characteristics (for example, high / low resistance to a particular attack) are assigned the same monster attribute. In other words, multiple monsters assigned the same monster attribute share common characteristics. A monster attribute is an example of an attribute that can be set in a battle event. Note that specific examples of monster attributes are not limited to the example in Figure 5, and examples of characteristics corresponding to monster attributes are not limited to those below. Monster records are pre-registered in the monster table at the time of the game's release. Monster records may also be added, modified, or deleted as the game progresses.

[0043] For example, monsters with the "Demon" attribute have low resistance to attack skills that healers can learn, and high resistance to attack skills that wizards can learn. Another example is monsters with the "Insect" attribute, which have low resistance to ranged attacks and high resistance to melee attacks. Yet another example is monsters with the "Slime" attribute, which have low resistance to physical attacks and high resistance to magical attacks. And yet another example is monsters with the "Dragon" attribute, which have low resistance to certain weapons (for example, Dragon Killer) and high resistance to breath skills (for example, Fire Breath).

[0044] [Deck table description] Figure 6 shows an example of deck table data. The storage 23 of the user terminal 20 stores the deck table shown in Figure 6. The deck table may also be stored in the storage 13 of the server 10. The deck table is data that indicates the decks that can be used in a battle event. The deck table contains one or more deck records. A deck record includes, for example, a deck ID, a deck name, a deck type, and a label.

[0045] The deck ID uniquely identifies a deck. The deck name is an arbitrary string assigned to the deck so that the player can easily understand its characteristics. A deck represents a combination of characters (more specifically, jobs) that battle monsters in a battle event. The label is set to one of the monster attributes assigned to the monsters that appear in the game. Furthermore, in the deck table according to the first embodiment, the same monster attribute is assigned to only one deck record (in other words, the same monster attribute is not assigned to multiple deck records). However, this is not limited to this.

[0046] The deck according to this embodiment is a combination of jobs for three characters. Note that the number of characters battling monsters in a battle event is not limited to three; it can be one or more. Furthermore, the deck is not limited to job combinations; it may also represent character possessions (e.g., weapons, armor, accessories). The deck is an example of the characteristics of an object used in the progression of a battle event.

[0047] Labels indicate the monster attributes of monsters that can battle advantageously with the corresponding deck. In other words, when a player uses a deck with a label that matches the monster attributes of the monster they are facing in a battle event, the battle event will proceed more favorably for the player compared to when a player uses a deck with a label that does not match the monster attributes (i.e., the deck is well-suited for the battle event against that monster). Matching monster attributes and labels is an example of "meeting the appropriateness requirements for the event that has occurred." Labels are an example of information regarding compatibility with events. "The battle event proceeding favorably" means that effects such as dealing more damage to monsters, receiving less damage from monsters, increasing the avatar's stats (buffs), decreasing monster stats (debuffs), and having a higher drop rate for rare items occur.

[0048] At the time the terminal program 23P is installed on the user terminal 20, no deck records are registered in the deck table. Then, based on the information entered by the player through the terminal program 23P and the deck editing screen described later, a new deck record may be registered, or the contents of an existing deck record may be modified. The player can assemble the desired deck through the deck editing screen and assign labels to monsters that are compatible with that deck.

[0049] For example, Deck ID "Deck 1" is a healer-centered deck consisting of a tank, a healer, and another healer, and is labeled "Demon-type". In other words, the deck represented by Deck ID "Deck 1" is more compatible with battle events against monsters of the "Demon-type" monster attribute compared to other decks. As another example, Deck ID "Deck 2" is a deck specializing in ranged attacks consisting of a tank, an archer, and a wizard, and is labeled "Insect-type". As yet another example, Deck ID "Deck 3" is a deck specializing in physical attacks consisting of a tank, an attacker, and a healer, and is labeled "Slime-type". As yet another example, Deck ID "Deck 4" is a deck consisting of an attacker, an attacker, and a healer who can equip weapons effective against dragon-type monsters, and is labeled "Dragon-type".

[0050] Furthermore, the labels assigned to decks may not only provide information about their compatibility with the event, but may also indicate "information about their suitability for the event." Information about suitability for the event includes, for example, any information that indicates the player's intention to use this deck to progress through this event, in addition to information about its compatibility with the event.

[0051] Decks may be assigned labels such as "Level Up" or "Strongest," regardless of their compatibility with the event. For example, terminal program 23P may select a deck with the label "Level Up" in a battle event against a specific monster with high experience points and proceed with the battle event. As another example, terminal program 23P may select a deck with the label "Strongest" in a battle event against a so-called "boss character" and proceed with the battle event.

[0052] [Event control processing] The game progresses on user terminal 20 when server program 13P causes server 10 (an example of a computer) to execute the following processes, and terminal program 23P causes user terminal 20 (another example of a computer) to execute the following processes. Hereafter, the act of server program 13P (terminal program 23P) causing server 10 (user terminal 20) to execute processes will simply be referred to as "server 10 (user terminal 20) executes the processes." The following explanation will focus on the game implemented on user terminal 20.

[0053] Furthermore, the server 10 and user terminal 20 identify the account the user will use before the game progresses, and then execute a process to proceed with the game using the identified account. In addition, the user terminal 20 transmits, for example, the current location information detected by the location sensor 42 to the server 10 via the communication IF 25 in order to associate it with the account currently in use.

[0054] Figure 7 is a flowchart of the event control process according to the first embodiment. Figure 8 is an example of the field screen. Figure 9 is an example of the deck selection screen. Figure 10 is an example of the deck editing screen. Figure 11 is an example of the battle screen in manual operation mode. Figure 12 is an example of the deck confirmation screen. Figure 13 is an example of the battle screen in automatic response mode.

[0055] [Explanation of the field screen] Server 10 transmits field data, which includes the current location indicated by the current location information received from user terminal 20, to user terminal 20 via communication IF 15 in order to synchronize it with the ongoing account.

[0056] The terminal program 23P displays the field screen shown in Figure 8 on the monitor 31 (S11). The field screen displays field F, which is represented by the field data received from the server 10. In other words, the field screen displays field F, which includes the position corresponding to player A's current location in real space. The field screen displayed on the user terminal 20 also displays field F centered on avatar A, which is operated by player A. Note that avatar A displayed on the field screen is one of several characters included in the selected deck.

[0057] As an example, the field screen may display an area of ​​field F, as shown in Figure 6, captured by a virtual camera (not shown) positioned above and behind avatar A. In this case, the terminal program 23P displays avatar A at a position on the field screen corresponding to the player A's current location. As another example, the field screen may display an area of ​​field F, as shown in the field data, captured by a virtual camera (not shown) positioned at the head (more specifically, the eyes) of avatar A. In this case, the terminal program 23P does not display avatar A on the field screen.

[0058] Then, terminal program 23P updates field F, which is displayed on the field screen, in accordance with the movement of player A in the real world. That is, terminal program 23P moves avatar A (in other words, virtual camera) on field F in accordance with the movement of player A in the real world. Then, terminal program 23P displays on the field screen the area of ​​field F that has been captured by the virtual camera after the move (i.e., the area included in the field of view of the virtual camera).

[0059] Additionally, a mode switching icon I1 may be displayed on the field screen. The mode switching icon I1 is an icon for switching game modes. The game modes include a manual operation mode (first mode) in which events are generated according to the actions of player A through the control device 43, and an automatic response mode (second mode) in which events are generated without the action of player A through the control device 43. The game mode is switched each time player A selects the mode switching icon I1. The mode switching icon I1 also displays the currently selected game mode (i.e., "manual" or "automatic").

[0060] The manual operation mode is a mode in which, for example, when player A, who has met predetermined positional conditions for an event (e.g., a monster symbol), instructs the progress of the event (e.g., by selecting monsters S1, S2, and S3), the event is started. In other words, the game according to the first embodiment employs a so-called "symbol encounter method" in which a battle event occurs in response to the selection of monsters S1, S2, and S3 displayed on the field screen. In addition, in manual operation mode, the event may progress through the manual operation of player A, the user terminal 20 may progress the event automatically, or these may be switched by player A. The manual operation mode is a mode suitable for when player A operates the user terminal 20 while remaining at their current location.

[0061] The automatic response mode is a mode in which, for example, if player A meets predetermined positional conditions for an event, the user terminal 20 automatically generates an event without any instruction from player A. In the automatic response mode, the user terminal 20 also automatically proceeds with the event. The automatic response mode is suitable when player A is moving with the user terminal 20 in their pocket or bag.

[0062] Additionally, a menu icon I2 may be displayed on the field screen. The menu icon I2 is an icon that allows player A to set various parameters for advancing the game (more specifically, the battle event). For example, when player A taps the menu icon, the terminal program 23P displays various screens (e.g., deck selection screen, deck editing screen) on the monitor 31 and accepts player A's operations to set various parameters (e.g., deck selection, deck record creation or editing) through the operation device 43. The terminal program 23P then stores the parameters selected (set) by player A through the operation device 43 in the storage 23 or sends them to the server 10.

[0063] As an example, terminal program 23P displays the deck selection screen shown in Figure 9 on monitor 31. The deck selection screen allows player A to select one of several decks registered in the deck table. The deck selection screen displays deck icons D1 to D4, each corresponding to one or more deck records registered in the deck table. When one of the deck icons D1 to D4 is selected (tapped) by player A, terminal program 23P selects the deck corresponding to the selected deck icon as the deck to be used in subsequent battle events. In the first embodiment, the following explanation will continue assuming that deck icon D1 has been selected.

[0064] Additionally, the deck selection screen may display a [New Deck] icon N. The [New Deck] icon N is an icon that allows player A to create a new deck (more specifically, a deck record). When the [New Deck] icon N is selected (tapped) by player A, the terminal program 23P displays the deck editing screen shown in Figure 10 on the monitor 31.

[0065] The deck editing screen is a screen that allows player A to select each item included in the deck record (i.e., deck name, jobs of characters 1-3, and labels). The deck editing screen includes a text box for entering the deck name, a pull-down menu for selecting the jobs and labels of characters 1-3, and a [Register] icon. When the [Register] icon is selected (tapped), terminal program 23P registers a new deck record in the deck table shown in Figure 6, which includes a new deck ID (e.g., Deck 5), the deck name entered in the text box (e.g., Magic Specialist), the decks indicating the jobs of characters 1-3 selected via the pull-down menu (e.g., Tank, Wizard, Wizard), and the labels selected via the pull-down menu (e.g., Material). Although not shown in the illustration, there may also be a screen for modifying the contents of an existing deck record.

[0066] Furthermore, monsters S1 to S3 are displayed on the field screen. In other words, terminal program 23P receives monster data (object data) from server 10 via communication IF25 and displays monsters S1 to S3, which are indicated by the received monster data, on the field screen. Monsters S1 to S3 are the opponent characters that avatar A battles against in battle events. In other words, monsters S1 to S3 are symbolic images that trigger battle events. That is, terminal program 23P makes events appear on the field screen according to the monster data received from server 10.

[0067] The terminal program 23P may move monsters S1-S3 on the field screen, or stop monsters S1-S3 at their current location. The number of monsters S1-S3 displayed on the field screen is not limited to three. Depending on the field of view of the virtual camera, monsters S1-S3 may not be displayed on the field screen. Furthermore, the server 10 may send some of the monster records registered in the monster table to the user terminal 20 based on, for example, the current location of player A, the level of avatar A, and the selected map. In other words, the terminal program 23P selectively displays monsters from among the monsters registered in the monster table that are indicated by the monster records (monster data) received from the server 10.

[0068] Then, terminal program 23P waits for the execution of steps S13 and beyond until Avatar A encounters one of monsters S1 to S3 on the field screen (S12: No). An encounter refers to the fulfillment of the conditions for triggering a battle event.

[0069] For example, in manual operation mode, an encounter may refer to the player A selecting monster S3 (by tapping the location of monster S3 on the field screen) when Avatar A has met the predetermined positioning conditions relative to monster S3. As another example, in automatic response mode, an encounter may refer to the player A having met the predetermined positioning conditions relative to monster S3. The following describes an example of Avatar A encountering monster S3.

[0070] "Saving the predetermined positional relationship" may mean, for example, that Avatar A has entered a predetermined area containing Monster S3. As another example, "Saving the predetermined positional relationship" may mean that Monster S3 has entered a predetermined area containing Avatar A. The specific shape of the predetermined area is not particularly limited, but for example, it is a circular area centered on the positions of Monster S3 and Avatar A.

[0071] Next, terminal program 23P determines the current game mode (manual operation mode, automatic response mode) if avatar A encounters monster S3 (S12: Yes) (S13). Then, if manual operation mode is selected (S13: No), terminal program 23P proceeds with the battle event using the deck that player A selected in advance (before the battle event occurred) through the deck selection screen (S14).

[0072] In step S14, terminal program 23P displays the battle screen shown in Figure 11 on monitor 31. The battle screen includes the characters C1, C2, and C3 that make up the selected deck 1, as well as monster S4 and various icons I3, I4, and I5. Terminal program 23P then advances the battle event by having characters C1, C2, and C3 take action (i.e., attack, use items, withdraw from battle events) according to player A's operations on icons I1 to I3, and by having monster S3 take action according to predetermined rules.

[0073] On the other hand, if the automatic response mode is selected (S13: Yes), the terminal program 23P determines whether or not a deck that is compatible with a battle event against monster S3 is registered among the multiple decks registered in the deck table shown in Figure 6 (S15).

[0074] If the terminal program 23P determines that there is no deck that is compatible with the battle event against monster S3 (S15: No), it executes the process in step S14. On the other hand, if the terminal program 23P determines that there is a deck that is compatible with the battle event against monster S3 (S15: Yes), it displays the deck confirmation screen shown in Figure 12 on the monitor 31 (S16). A "deck that is compatible with the battle event against monster S3" refers to, for example, a deck that has been assigned a label that matches the monster attribute "Slime type" of monster S3. In the first embodiment, this refers to the deck identified by deck ID "Deck 3".

[0075] The deck confirmation screen is a screen that allows player A to confirm whether to proceed with the battle event using deck 1, which player A has selected in advance, or using deck 3, which is compatible with monster S3. The deck confirmation screen includes messages such as "Player A has selected deck 1" and "Deck 3 is compatible with monster S3," as well as a [YES] icon corresponding to deck 3, which is compatible with monster S3, and a [NO] icon corresponding to the previously selected deck 1. The terminal program 23P then waits for player A to select either deck 1 or 3 via the icon (S17: No), or until a predetermined threshold time (for example, 10 seconds) has elapsed (S18: No), before executing the process from step S19 onward.

[0076] Then, if player A selects the [YES] icon before the threshold time elapses (S17: Yes & S18: No), terminal program 23P proceeds with the battle event using deck 3 which is compatible with monster S3 (S19). In this case, terminal program 23P displays the battle screen shown in Figure 13 on monitor 31 in step S19. The battle screen shown in Figure 13 differs from the battle screen in Figure 11 in that the characters C4, C5, and C6 that make up deck 3 are displayed, and icons I3, I4, and I5 are omitted. Then, terminal program 23P proceeds with the battle event by having characters C4, C5, C6 and monster S3 act (i.e., act automatically without player A's input) according to predetermined rules.

[0077] Furthermore, if player A selects the [NO] icon before the threshold time elapses (S17:Yes & S18:No), terminal program 23P proceeds with the battle event using deck 1 previously selected by player A (S19). In this case, terminal program 23P displays the battle screen shown in Figure 11 on monitor 31 in step S19, omitting icons I3, I4, and I5. Then, terminal program 23P proceeds with the battle event by having characters C4, C5, C6 and monster S3 act (i.e., act automatically without player A's input) according to predetermined rules.

[0078] Furthermore, if the threshold time elapses without player A selecting an icon (S17: No & S18: Yes), terminal program 23P proceeds with the battle event using deck 3 which is compatible with monster S3 (S20). In this case, terminal program 23P proceeds with the battle screen through the battle screen shown in Figure 13. The processing in step S20 is executed, for example, when player A selects automatic response mode and moves around with the user terminal 20 in their pocket or bag.

[0079] As another example, if terminal program 23P determines that there is no deck suitable for a battle event against monster S3 (S15: No), it may proceed with the event using a general-purpose deck. A general-purpose deck is, for example, a well-balanced deck that can be widely used in battle events against various monsters, and does not need to have a label assigned to it. As yet another example, if the same label is assigned to multiple decks, terminal program 23P may select multiple decks with monster labels assigned to them in step S15. In this case as well, terminal program 23P may have player A confirm which deck to use to proceed with the battle event through a deck confirmation screen.

[0080] [Effects of the First Embodiment] According to the first embodiment, the game can be progressed without having to re-select a deck for each battle event by automatically selecting a deck that is compatible with the encountered monster according to its label. As a result, player convenience is improved. Note that "automatically selecting a deck" can also be rephrased as, for example, changing (switching) from the deck selected by the player through the deck selection screen (Figure 9) to a deck that corresponds to the label.

[0081] Furthermore, according to the first embodiment, by automatically selecting a deck and proceeding with the battle event in automatic response mode, the player can select a deck that suits their game style. As a result, player convenience is improved. However, deck selection is not limited to "fully automatic" by the terminal program 23P, but may also be "semi-automatic," allowing the player to confirm through the deck confirmation screen shown in Figure 12. Also, deck selection using labels is not limited to when automatic response mode is selected, but may also be performed when manual operation mode is selected.

[0082] Furthermore, according to the first embodiment, even if a deck compatible with a monster is not registered, the battle event can proceed using a deck that the player has selected in advance. As a result, the convenience for the player is improved.

[0083] In the first embodiment, an example was described in which Player A selects a deck that is compatible with the encountered monster from among several decks that have been pre-organized. As another example, the terminal program 23P may generate a new deck that is compatible with the encountered monster from among the jobs and items that Player A can select, and proceed with the battle event.

[0084] [Second Embodiment] Next, a second embodiment of the present invention will be described. In this embodiment, a raid boss (hereinafter referred to as "Monster M") managed by Server 10 appears in multiple areas according to a predetermined schedule (movement conditions) and battles with one or more players at each location. The damage and status ailments inflicted by these players on Monster M in those battles are accumulated and carried over to the battle in the next area, enabling the implementation of a raid battle. Components identical to those described in the first embodiment are denoted by the same reference numerals, and additional explanations may be added if necessary, or omitted if there are no additional explanations.

[0085] [Functional block diagram of Server 10] Figure 16 is a functional block diagram of the server 10 according to the second embodiment. As shown in Figure 16, the server program 13P loaded into memory 12 causes the server 10 (computer) to function as a movement condition setting means 110, a raid boss state management means 120, an event control means 130, a calculation means 140, and a reward granting means 150.

[0086] The movement condition setting means 110 sets movement condition information (sometimes referred to as a schedule) based on the movement condition table 112 described later, so that the monster M, as a raid boss, is sequentially placed in multiple appearance areas according to predetermined movement conditions. This movement condition information can be notified to each user terminal 20.

[0087] As shown in Figure 17, the movement condition table 112 is stored in the storage 13 of the server 10 and functions as a data table that stores data defining which area and at what timing monster M will appear (be placed). The movement condition table 112 contains one or more schedule records associated with the ID in the monster M table 122, which will be described later. The schedule record specifies, for example, the record number, the order of appearance, the appearance area, and the time period of appearance.

[0088] The record number is data that indicates a code assigned to each record so that it can be uniquely identified. The first part is assigned the ID from the monster M table 122, and the second part is assigned a number that represents the record. The appearance order is data that indicates the order in which monster M appears. The appearance area is data that indicates the area on field F in which monster M appears (for example, coordinate information specified by the region name, longitude, latitude, etc.). In this embodiment, each area does not overlap with another, and the areas are set to be far enough apart (at least a distance that is difficult to travel on foot) that a player who has participated in a battle in one area cannot easily participate in a battle in the next appearance area. The appearance time period is data that indicates the period during which monster M appears in the appearance area (for example, the start date and time and the end date and time). The movement condition table 112 may be predetermined, or it may be determined, for example, at the start of the event or each time an area is moved using a generated AI.

[0089] The Raid Boss Status Management System 120 stores and manages the parameters of Monster M (for example, total HP, current HP, presence and nature of status ailments, etc.) and updates the stored parameters based on instructions from the Event Control System 130. Specifically, it manages these parameters by updating each parameter (also referred to as data) in the Monster M Table 122 based on instructions from the Event Control System 130.

[0090] The Monster M Table 122 functions as a data table that stores data about Monster M stored in the storage 13 of the server 10. As shown in Figure 18, the Monster M Table 122 contains multiple Monster M records. A Monster M record includes, for example, an ID, a name, total HP (MAXHP), current HP (HP), and status. It may also include information about the monster's weaknesses and resistances.

[0091] The ID is data that uniquely identifies Monster M. The Name is data that indicates the name of Monster M displayed to the player. Total HP is data that indicates the total amount of damage required to defeat Monster M. Current HP is data that indicates the current HP, calculated by subtracting the damage taken (damage dealt by the player) accumulated through battles in each area from the total HP. Note that at the start of the event, MAXHP and HP are set to the same value. Status is data that indicates any status ailments (e.g., poison, paralysis, defense reduction, etc.) applied to Monster M. Note that status may also include data indicating the status of body part destruction, etc.

[0092] The event control means 130 causes monster M to appear in each appearance area according to the movement condition information set by the movement condition setting means 110. In addition, during battle in each appearance area, the event control means 130 receives information from multiple user terminals 20 indicating the amount of damage dealt to monster M in response to player operations. Based on the received amount of damage, it causes the raid boss state management means 120 to update the parameters of monster M. For example, if the amount of damage received from multiple players is "50,000" damage, the event control means 130 updates the parameters of monster M by subtracting "50,000" from monster M's current HP. Furthermore, when monster M appears in the next appearance area, the event control means 130 controls the appearance of monster M to apply the parameters that were last updated in the current appearance area.

[0093] The calculation method 140 calculates the degree of influence (contribution) each player had on Monster M at the end of the event (for example, when Monster M is successfully defeated or when the schedule ends). Contribution is a numerical representation of actions that directly affected Monster M, such as the total amount of damage dealt to Monster M by one or more players during the event period, or the application of status ailments (poison, paralysis, being unable to use skills or magic, reduced attack or defense, etc.). Note that contribution may include actions that are not directly affected by Monster M, but are involved in the battle with Monster M. For example, it may be calculated based on the amount of damage a player received from Monster M, or the number of times they took actions that increased the probability of being targeted by Monster M (raising hate).

[0094] The reward distribution method 150 distributes rewards to each player according to their calculated contribution. Rewards may include, for example, in-game currency, experience points, equipment such as weapons, armor, and accessories, materials for synthesis, items, tickets that can be used in a predetermined lottery, or the right to participate in a specific event.

[0095] [Raid boss event control processing] Next, the raid boss event control process according to the second embodiment will be described with reference to the flowchart in Figure 19. This process is mainly realized by the processor 11 of the server 10 executing the server program 13P.

[0096] First, when the event start time arrives (Y in S31), the movement condition setting means 110 of server 10 refers to the movement condition table and identifies the initial appearance area and time period (S32). Then, the event control means 130 reads the parameters of the target monster M (current health equal to total health in the initial state) from the monster M table 122 (S33) and makes monster M appear in the identified appearance area (S34). Server 10 transmits the appearance information of monster M (appearance area, appearance time period, current health, etc.) to each user terminal 20 (S35).

[0097] On the user terminal 20, the terminal program 23P receives information about the appearance of monster M from the server 10, and if the player is within a predetermined range of the monster M's appearance area, monster M is displayed on the field screen. The player can start a battle event by selecting the displayed monster M.

[0098] The event control means 130 of server 10 receives information from multiple user terminals 20 indicating the amount of damage dealt to monster M by the players during the time period when monster M appears (S36). The user terminals 20 send the amount of damage dealt by the players in battle to server 10 as needed.

[0099] The event control means 130 instructs the raid boss state management means 120 to update the current health of monster M stored in the monster M table 122 in real time based on the amount of damage received (S37). In addition to the amount of damage, the parameters are also updated when information on status changes such as the accumulation value of status ailments or the destruction of body parts is received. The server 10 may also transmit the updated information, such as the current health of monster M, to the user terminal 20 during combat.

[0100] The event control means 130 determines whether the current appearance time period has ended (S38). If the appearance time period has not ended (S38:N), the process returns to step S33 and continues receiving damage information and updating parameters.

[0101] When the appearance period ends (S38:Y), the event control means 130 makes monster M disappear from the current appearance area. Next, the event control means 130 refers to the information from the raid boss state management means 120 and determines whether or not monster M's current HP has become 0 or less, that is, whether or not the defeat has been completed (S39).

[0102] If the current HP of monster M is greater than 0 (S39:N), the event control means 130 refers to the movement condition table 112 and determines whether there is a next appearance area (S40). If there is a next appearance area (S40:Y), the process returns to step S32, and monster M is made to appear in the next appearance area with its updated current HP carried over. At this time, the server 10 may notify all user terminals 20 of information regarding the next appearance area, the time of appearance, and the updated state of monster M.

[0103] On the other hand, if there is no next appearance area (S40:N), the defeat of Monster M is considered a failure, and the event ends. In this case, the calculation means 140 on server 10 calculates the contribution level of the participating players up to that point (S41), determines a participation reward that is of lower quality and quantity than the reward for defeating the monster, according to the calculated contribution level, and grants it as a reward (S42). In the case of a failed defeat, the contribution level may be not calculated, and a uniform participation reward may be granted.

[0104] In step S39, if it is determined that the current HP of monster M has become 0 or less (S39:Y), the defeat of monster M is considered successful and the event ends. In this case, the calculation means 140 calculates the contribution based on the total amount of damage received from each player (S41), determines the reward for successful subjugation according to the contribution, and processes the distribution of the reward to all participating players (S42). In this embodiment, the higher the contribution, the larger the amount of the reward for successful subjugation, and the higher the quality of the reward (for example, the equipment, items, materials, etc. that are awarded may be of a higher rarity that is normally difficult or impossible to obtain).

[0105] [Effects of the second embodiment] According to the second embodiment, Monster M moves between multiple areas according to a predetermined schedule, and the battle results in each area are accumulated and carried over, allowing players to participate in the event at a time and place convenient for them. This significantly lowers the barrier to participation, allowing more players to enjoy the event. As a result, player convenience is improved.

[0106] Furthermore, because player access is distributed both temporally and geographically, it avoids concentrated access at specific times or locations. This helps to level out the load on the servers and provide a stable gaming environment.

[0107] Furthermore, the contributions (impacts on Monster M) of many players fighting at different times and in different locations are brought together towards the single goal of defeating Monster M. This allows players to feel a sense of unity and cooperation with other players who are not playing directly at the same time, creating a new and unprecedented cooperative gameplay experience and enhancing player enjoyment.

[0108] [Examples of applying this invention to games] As a specific example of a game to which the present invention is applied, the event of defeating monster M "Mono-Eyed Devil King" will be explained using Figures 20-22.

[0109] First, Server 10 sets "Mono-Eyed Devil King" as Monster M with a total HP of 5,000,000 and registers it in Monster M Table 122. Server 10 also sets the appearance conditions for the monster to occur in "X District XX Town between 10:00 and 12:00", "Y District △△ Town between 13:00 and 15:00", and "Z District ◇◇ Town between 16:00 and 18:00", and registers these conditions in the Movement Conditions Table. This event summary information may be announced to players in advance within the game.

[0110] When the event starts and it reaches 10:00, as shown in Figure 20, Server 10 will make a "Mono-Eyed Devil King" with 5,000,000 HP appear in X-District XX Town (A in Figure 20) of Area A. Players A1, A2, A3, and A4 who are near X-District XX Town can find the Mono-Eyed Devil King on the Field F screen and challenge it to battle. Let's assume that the total amount of damage dealt by all players who participated in the battle in X-District XX Town during the two hours until 12:00 is 1,500,000. Server 10 will accumulate this amount of damage and update the Mono-Eyed Devil King's current HP to 3,500,000 as shown in Figure 18. At 12:00, the Mono-Eyed Devil King will disappear from X-District XX Town.

[0111] Next, at 13:00, as shown in Figure 21, Server 10 makes the "Mono-Eyed Devil King" appear in Y-district △△ town (B in Figure 20) in Area B. At this time, the Mono-Eyed Devil King's initial health is 3,500,000, carried over from the battle results in X-district 〇〇 town. Players B1, B2, B3, and B4 in Y-district △△ town can fight this weakened Mono-Eyed Devil King. Let's assume that the total amount of damage dealt by the players in Y-district △△ town by 15:00 is 2,000,000. Server 10 records this and updates the Mono-Eyed Devil King's current health to 1,500,000. At 15:00, the Mono-Eyed Devil King disappears from Y-district △△ town. Furthermore, the distance between Y-district △△ town in Area B and X-district 〇〇 town in Area A is more than 5 hours on foot, making it difficult for players A1, A2, A3, and A4, who have completed battles in Area A, to immediately participate in battles in Area B.

[0112] Finally, at 16:00, Server 10 will make a "Mono-Eyed Devil King" with 1,500,000 HP appear in Z District ◇◇ Town in Area C. Similar to the relationship between Area A and B, Z District ◇◇ Town in Area C is more than a 5-hour walk from X District △△ Town in Area B, making it difficult for players B1, B2, B3, and B4, who have completed battles in Area B, to continue participating in battles in Area B. Furthermore, the distance from Area A is more than an 8-hour walk, making it difficult for players A1, A2, A3, and A4, who have completed battles in Area A, to continue participating in battles in Area C.

[0113] If players from Z District ◇◇ Town deal more than 1,500,000 damage, the boss will be defeated. If the boss is defeated, all players who participated in this event (who fought the Mono-Eyed Devil King at least once) will receive rewards according to their contribution. For example, a ranking will be created based on the total amount of damage dealt, and top players will receive luxurious rewards such as limited equipment, and all participants will receive the right to draw from a special gacha as a reward for the successful defeat. This eliminates the unfairness of rewards being concentrated only on the player from Z District ◇◇ Town who happened to be the last to appear, and ensures that the contributions of all participants are rewarded.

[0114] Furthermore, not only the amount of damage dealt, but also the accumulated values ​​of status ailments such as "poison" and "paralysis," and the state of destruction of specific body parts (wings, tail, etc.) may be carried over to the next area. This would allow players to engage in more strategic cooperative play by leveraging their achievements at previous locations. Additionally, a branching route element may be added, where the boss's next destination is determined from multiple options based on the battle results at each location (e.g., the amount of damage dealt within a certain time). This would provide players with an experience where their actions influence the unfolding of the story. While previously, by making the areas far apart, users who participated in a battle in one area could not participate in battles in other areas, it would be possible to, for example, assign tag data to players who participated in a battle in one area, identifying which area's battle they participated in, and then have server 10 control which areas' battles players with that tag data cannot participate in.

[0115] [Differentiation] Although the above embodiment was described using a location-based game, it may also be applied to various application services that utilize location information. Examples include fitness apps, training apps, health support apps, transportation guidance apps, and tourist information apps. Furthermore, although the embodiment was described using a game where players set combinations of objects, it may also be applied to various application services that utilize combinations of objects.

[0116] Furthermore, the program according to the present invention is not limited to a single program, but may be a collection of multiple programs. Also, the program according to the present invention is not limited to being executed on a single device, but may be executed by multiple devices in a shared manner. Moreover, the division of roles between the server 10 and the user terminal 20 is not limited to the examples described above. That is, a part of the processing of the server 10 may be executed by the user terminal 20, and a part of the processing of the user terminal 20 may be executed by the server 10. The embodiments described herein can be combined in part or in whole, and parts may be replaced, added, deleted, or modified with other elements. It is also acceptable to appropriately adopt known technical elements at the time of filing, even for matters not explicitly described herein. Furthermore, the first and second embodiments of this specification may be combined as appropriate, and appropriate combinations are possible, such as applying a part of the configuration of one embodiment to the other embodiment.

[0117] Furthermore, some or all of the means implemented by the program can also be implemented by hardware such as integrated circuits. Additionally, the program may be provided by being recorded on a non-transient recording medium readable by a computer. Recording mediums include, for example, hard disks, SD cards, DVDs, and servers on the internet.

[0118] [Note 1] The present invention is summarized below. [assignment] For example, the present invention aims to enhance the player's enjoyment. [Solution] (1) Computers, A generation means for generating a virtual map within the game that corresponds to the real space based on the player's location information in the real space, It functions as a position updating means that, according to predetermined movement conditions, moves a first object placed in a first area on the virtual map to a second area different from the first area. A program that places the first object in the second area while maintaining predetermined parameters of the first object that were affected by a second object different from the first object within the first area. (2) The second object includes multiple player objects, each operated by multiple players, The program according to (1), wherein the predetermined parameters are predetermined parameters of the first object that is affected by the plurality of player objects. (3) Within the first area, only one or more first player objects located within the first area can have an effect on the first object. The program according to (2), wherein within the second area, only one or more second player objects that are different from the first player object and located within the second area can affect the first player object. (4) The computer further, A reward-granting means that grants rewards to the multiple player objects that have affected the first object when the predetermined parameters satisfy specific conditions, This is configured to function as a calculation means for calculating the degree of influence each of the plurality of player objects has on the first object. The reward-granting means is a program according to (2) or (3) that changes the reward to be granted according to the calculated degree of influence. (5) A generation means for generating a virtual map in the game that corresponds to the real space based on the player's location information in the real space, A system comprising: a position updating means for moving a first object placed in a first area on the virtual map to a second area different from the first area, according to predetermined movement conditions, A system for placing the first object within the second area while maintaining predetermined parameters of the first object that were affected by a second object different from the first object within the first area. [Effects and Effects] According to the above solutions (1) to (4), Monster M moves between multiple areas according to a schedule, and battle results are carried over, making it easier for players to participate in events at their own convenience. In addition, the server load is distributed, allowing players in different locations to feel a sense of unity in cooperative play, thereby increasing player enjoyment.

[0119] Furthermore, the program according to the present invention is not limited to a single program, but may be a collection of multiple programs. Also, the program according to the present invention is not limited to being executed on a single device, but may be executed by multiple devices in a shared manner. Moreover, the division of roles between the server 10 and the user terminal 20 is not limited to the examples described above. That is, a part of the processing of the server 10 may be executed by the user terminal 20, and a part of the processing of the user terminal 20 may be executed by the server 10. The embodiments described herein can be combined in part or in whole, and parts may be replaced, added, deleted, or modified with other elements. It is also acceptable to appropriately adopt known technical elements at the time of filing, even for matters not explicitly described herein. Furthermore, the first and second embodiments of this specification may be combined as appropriate, and appropriate combinations are possible, such as applying a part of the configuration of one embodiment to the other embodiment.

[0120] Furthermore, some or all of the means implemented by the program can also be implemented by hardware such as integrated circuits. Additionally, the program may be provided by being recorded on a non-transient recording medium readable by a computer. Recording mediums include, for example, hard disks, SD cards, DVDs, and servers on the internet. [Explanation of symbols]

[0121] 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...Operating device, 110...Movement condition setting means, 120...Raid boss state management means, 130...Event control means, 140...Calculation means, 150...Reward granting means

Claims

1. Computers, A generation means for generating a virtual map within the game that corresponds to the real space based on the player's location information in the real space, It functions as a position updating means that, according to predetermined movement conditions, moves a first object placed in a first area on the virtual map to a second area different from the first area. When placing the first object within the second area, the first object is placed within the second area while maintaining predetermined parameters of the first object that were affected by a second object different from the first object within the first area. A program in which a second object that has influenced the first object within the first area cannot influence the first object located within the second area.

2. The second object includes multiple player objects, each operated by multiple players. The program according to claim 1, wherein the predetermined parameter is a predetermined parameter of the first object that is affected by the plurality of player objects.

3. The aforementioned computer, further, A reward-granting means that grants rewards to the multiple player objects that have affected the first object when the predetermined parameters satisfy specific conditions, This is configured to function as a calculation means for calculating the degree of influence each of the plurality of player objects has on the first object. The reward-granting means changes the reward to be granted according to the calculated degree of influence, as described in claim 2.

4. A generation means for generating a virtual map within the game that corresponds to the real space based on the player's location information in the real space, A system comprising: a position updating means for moving a first object placed in a first area on the virtual map to a second area different from the first area, according to predetermined movement conditions, A system in which a second object that has influenced a first object within the first area cannot influence a first object located within the second area.

Images