Program and system

Abstract

To increase interest in a user.SOLUTION: A program causes a computer to serve as control means which generates an event which can be progressed by multi-play by a plurality of users within a virtual space associated to an actual space and assigns to each user an element giving an influence on the progress of the event in response to the start of the multi-play.SELECTED DRAWING: Figure 11

Description

[Technical Field]

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

[0002] In recent years, there have been services that allow a user using a user terminal that executes a predetermined application program to participate in an event prepared in the application program by arriving at a predetermined location in real space.

[0003] However, in such services, there is a demand for increasing interest from users. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent No. 7227499 Summary of the Invention [Problem to be solved by the invention]

[0005] SUMMARY OF THE INVENTION It is therefore an object of the present invention to provide a program and a system that can increase the interest of users. [Means for solving the problem]

[0006] According to one aspect of the present invention, a program is provided that causes a computer to function as a control means that generates an event that can be played in multiplayer by multiple users in a virtual space associated with real space, and allocates elements that affect the progress of the event to each user in response to the start of the multiplayer play. [Effects of the Invention]

[0007] The present invention makes it possible to increase the interest of the user. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram showing an example of the configuration of a system according to an embodiment. [Figure 2] FIG. 2 is a diagram showing an example of the hardware configuration of a user terminal. [Figure 3] FIG. 2 is a diagram illustrating an example of a hardware configuration of a server device. [Figure 4] FIG. 2 is a diagram showing an example of the functional configuration of a user terminal. [Figure 5] FIG. 2 is a diagram illustrating an example of the functional configuration of a server device. [Figure 6] FIG. 10 is a diagram showing an example of setting data related to a location-based game. [Figure 7] 10 is a flowchart showing an example of a processing procedure of a game system. [Figure 8] FIG. 2 is a diagram specifically illustrating the operation of the game system. [Figure 9] FIG. 2 is a diagram specifically illustrating the operation of the game system. [Figure 10] FIG. 2 is a diagram specifically illustrating the operation of the game system. [Figure 11] FIG. 10 is a diagram for specifically explaining the allocation process of a game system. [Figure 12] FIG. 10 is a diagram for specifically explaining the allocation process of a game system. [Figure 13] FIG. 10 is a diagram for specifically explaining a battle screen. [Figure 14] FIG. 10 is a diagram for specifically explaining the allocation process of a game system. [Figure 15] FIG. 10 is a diagram for specifically explaining a request setting screen. [Figure 16] FIG. 10 is a diagram for specifically explaining the allocation process of a game system. [Figure 17] FIG. 10 is a diagram for specifically explaining the allocation process of a game system. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. Fig. 1 shows an example of the configuration of a system according to an embodiment. The system 1 shown in Fig. 1 is a system (hereinafter referred to as game system 1) configured to enable users to play games online, for example. As shown in Fig. 1, the game system 1 includes a plurality of user terminals 10 and a server device 20.

[0010] Each of the multiple user terminals 10 is, for example, a portable electronic device used by a user. In this embodiment, it is assumed that each of the multiple user terminals 10 is, for example, a smartphone, but the user terminal 10 may also be another portable electronic device such as a tablet terminal.

[0011] The server device 20 is communicably connected to a plurality of user terminals 10 via a network 30 such as the Internet.

[0012] Fig. 2 shows an example of the hardware configuration of the user terminal 10 shown in Fig. 1. Here, with reference to Fig. 2, the hardware configuration when the user terminal 10 is a smartphone will be described.

[0013] As shown in FIG. 2, the user terminal 10 includes a nonvolatile memory 11, a CPU 12, a main memory 13, a wireless communication device 14, a display 15, a touch panel 16, and the like.

[0014] The nonvolatile memory 11 stores various programs, including, for example, an operating system (OS) and various application programs that run on the user terminal 10.

[0015] The CPU 12 is a processor for controlling the operation of various components within the user terminal 10, and executes various programs stored in the non-volatile memory 11, for example. The CPU 12 may be a single processor or may be composed of multiple processors. The various programs stored in the non-volatile memory 11 are loaded from the non-volatile memory 11 to the main memory 13 and executed by the CPU 12, and the programs (application programs) executed by the CPU 12 include a game program 13A for operating as a user terminal in the game system 1.

[0016] The wireless communication device 14 is a device for performing wireless communication with an external device (for example, a server device 20, etc.).

[0017] The display 15 is a display device for displaying, for example, various screens relating to the game played by the user.

[0018] The touch panel 16 is an input device that detects the position where the user's fingertip or the like touches, and is disposed, for example, on top of the front surface of the display 15.

[0019] The display 15 and the touch panel 16 constitute a touch screen display, and the touch screen display can detect (accept) various operations performed by the user on the screen.

[0020] Fig. 3 shows an example of the hardware configuration of the server device 20 shown in Fig. 1. As shown in Fig. 3, the server device 20 includes a nonvolatile memory 21, a CPU 22, a main memory 23, a wireless communication device 24, and the like.

[0021] The nonvolatile memory 21 stores various programs, including, for example, an operating system (OS) and various application programs that run on the server device 20.

[0022] The CPU 22 is a processor for controlling the operation of various components in the server device 20, and executes various programs stored in the nonvolatile memory 21, for example. The CPU 22 may be a single processor or may be composed of multiple processors. The various programs stored in the nonvolatile memory 21 are loaded from the nonvolatile memory 21 to the main memory 23 and executed by the CPU 22, and the programs (application programs) executed by the CPU 22 include a game program 23A for operating as a server device in the game system 1.

[0023] The wireless communication device 24 is a device for performing wireless communication with external devices (for example, a plurality of user terminals 10, etc.).

[0024] The following describes the functional configuration of the game system 1 according to this embodiment. The game system 1 according to this embodiment has a function that enables users to play a game by, for example, operating in cooperation with a plurality of user terminals 10 and a server device 20.

[0025] Here, an overview of the game that can be played by the user in this embodiment will be described. The game system 1 according to this embodiment provides a game play environment in which it is possible to play a location-based game that uses location information indicating the user's location, for example.

[0026] In a location-based game, a user can participate in events that occur in various locations by moving through a virtual space associated with information about movement in the real world. In this embodiment, the event is assumed to be, for example, an event in which the user battles an enemy character (hereinafter referred to as a battle event), but may also be another type of event (including a quest, item acquisition, etc.).

[0027] Generally, in games in which a player battles an enemy character, the enemy character may have multiple destructible body parts. In the process of defeating the enemy character, the user can destroy the body parts of the enemy character and thereby obtain a reward corresponding to the destroyed body parts in addition to the reward obtained by defeating the enemy character.

[0028] Even in battle events in location-based games, enemy characters may have multiple destructible body parts associated with positions (locations). In such battle events, a user can damage and destroy each body part by moving to the position associated with each body part and attacking the enemy character. However, when a position is associated with each body part, as described above, the user cannot destroy each body part unless he or she moves to the position associated with each body part, which can result in a lack of interest and convenience.

[0029] In location-based games, multiple users can participate in the same event to play multiplayer games. Multiplayer games refer to multiple users playing a game together. Multiplayer games can be played, for example, when nearby users are matched and a predetermined relationship is established between them.

[0030] In location-based games, there are also battle events in which a multiplayer battle is conducted against an enemy character that includes multiple destructible body parts as described above. In such battle events, multiple destructible body parts included in the enemy character and associated with locations (points) may be assigned to each user.

[0031] When a position is associated with each body part, as described above, each user must travel to the position associated with that body part in order to destroy the body part assigned to that user. However, for example, if a user is assigned a body part that is associated with a position far from their current position as the body part they are responsible for destroying, they may not be able to travel to that far position during the battle event, which can be a problem, making the event less interesting. Furthermore, in a game in which a reward corresponding to a destroyed body part is awarded only to the user who destroyed that body part, not being able to destroy the body part assigned to them for the reasons described above may result in a decrease in the user's motivation for the game.

[0032] Therefore, the game system according to this embodiment provides a useful mechanism for increasing the interest in location-based games. More specifically, a useful mechanism for increasing the interest in battle events in location-based games in which a multiplayer battle is conducted against enemy characters having multiple destructible body parts is provided. Note that in this embodiment, a case will be described in which the event is a battle event in which a multiplayer battle is conducted against enemy characters having multiple destructible body parts, and the elements assigned to each user are body parts; however, the event may be of any format as long as it is an event in which multiple users can participate, and the elements assigned to each user may be any element as long as they affect the progress of the event.

[0033] 4 shows an example of the functional configuration of the user terminal 10. As shown in FIG. 4, the user terminal 10 includes an operation receiving unit 101, a control unit 102, a display processing unit 103, and a storage unit 104.

[0034] 4 are functional units realized by, for example, a CPU 12 (a computer of the user terminal 10) provided in the user terminal 10 executing the above-described game program 13A (i.e., software). This game program 13A may be downloaded to the user terminal 10 via the network 30, or may be distributed by being stored in advance in a computer-readable storage medium.

[0035] 4 is realized by the nonvolatile memory 11 shown in FIG. 2 or another storage device (not shown).

[0036] The operation reception unit 101 receives user operations (instructions) for playing a location-based game. When the user terminal 10 is a smartphone as described above, the operations received by the operation reception unit 101 include operations of touching a fingertip to a touch panel 16 (touch screen display) provided on the user terminal 10 (for example, a tap operation, a drag operation, a flick operation, a swipe operation, etc.).

[0037] The control unit 102 interprets the operation received by the operation receiving unit 101 and executes control to progress the position information game played in the game play environment.

[0038] The display processing unit 103 displays, for example, a screen (hereinafter referred to as a map screen) including a map of the real space in which the user using the user terminal 10 moves on the display 15. Note that on the map screen displayed by the display processing unit 103, for example, a first object corresponding to the user (for example, a character used by the user in a game) is placed at the user's current position, and a second object indicating (the occurrence of) a battle event (for example, an enemy character to fight in a battle event) is placed at the occurrence position of the battle event.

[0039] The location where a battle event occurs may be limited in time. The location where a battle event occurs may also be one that moves and displaces. Examples of the displaced location include one that moves and displaces in real time, and one that moves and displaces at regular time intervals.

[0040] In this embodiment, the user's position (or the position information indicating the position) is acquired using, for example, a global positioning system (GPS) installed in the user terminal 10. The display processing unit 103 updates the position (location) of the first object corresponding to the user that is placed on the map screen, based on the user's position that changes in accordance with the user's movement.

[0041] Here, in the location-based game of this embodiment, when a user moves near the location where a battle event occurs (i.e., when a first object placed on the map screen displayed by the display processing unit 103 moves to a position near a second object), the user can participate in the battle event.

[0042] The storage unit 104 stores, for example, game data and user data. In the game system 1, an account is issued for each user who can play the location-based game. The game data is data (information) common to the accounts and is referenced when the above-described game program 13A is executed. Specifically, the game data includes, for example, data for defining the game play environment and setting data related to the location-based game. Meanwhile, the user data is data related to the user that is managed for each user account. Specifically, the user data stored in the storage unit 104 included in the user terminal 10 (i.e., user data related to the user who uses the user terminal 10) includes, for example, data indicating the user's game progress in the location-based game and various points and items acquired by the user in the location-based game.

[0043] 5 shows an example of the functional configuration of the server device 20. As shown in FIG.

[0044] The storage unit 201 shown in FIG. 5 is realized by the nonvolatile memory 21 shown in FIG. 3 or another storage device (not shown).

[0045] 5 are functional units realized by, for example, a CPU 22 (a computer of the server device 20) provided in the server device 20 executing the above-described game program 23A (i.e., software). This game program 23A may be downloaded to the server device 20 via the network 30, or may be distributed by being stored in advance in a computer-readable storage medium.

[0046] The storage unit 201 stores game data similar to the game data stored in the storage unit 104 included in the above-described user terminal 10. The storage unit 201 also stores user data for each user (i.e., a user to whom an account has been issued) who has been pre-registered in the game system 1 (server device 20).

[0047] The data management unit 202 manages the game data and user data stored in the storage unit 201. Specifically, the data management unit 202 executes processes such as adding, updating, and deleting game data and user data.

[0048] The game data and user data managed by the data management unit 202 are transmitted from the data management unit 202 (server device 20) to each of the multiple user terminals 10 and stored in the storage unit 104 included in the user terminal 10. In this case, the game data is transmitted in common to the multiple user terminals 10, but the user data is transmitted only to the user terminal 10 used by the user corresponding to the user data.

[0049] Here, the data management unit 202 has been described as managing game data and user data, but the data management unit 202 may further manage (location information indicating) the locations of each of a plurality of users playing the location-based game. Furthermore, the data management unit 202 may further manage the locations where the above-mentioned battle events occur.

[0050] The control unit 203 executes various processes for providing a gameplay environment for playing a position information game (i.e., for enabling users to play a position information game). Specifically, the control unit 203 executes a process for allocating parts to be destroyed to each user in a battle event such as a multiplayer battle against an enemy character having multiple destructible parts.

[0051] Furthermore, the control unit 203 executes processing for realizing multiplay in the above-described location information game.

[0052] Here, for example, assume that user X1 and user X2 are playing a multiplayer game. In this case, a game screen for playing a multiplayer game (hereinafter referred to as a multiplayer screen) is displayed on the user terminal 10 used by user X1, and user X1 can play a multiplayer game with user X2 by operating the character of user X1 on the multiplayer screen. Similarly, a multiplayer screen is displayed on the user terminal 10 used by user X2, and user X2 can play a multiplayer game with user X1 by operating the character of user X2 on the multiplayer screen.

[0053] In order to realize such multiplay, the operations of user X2 must be reflected on the multiplay screen displayed on the user terminal 10 used by user X1, and the operations of user X1 must be reflected on the multiplay screen displayed on the user terminal 10 used by user X2.

[0054] Therefore, when user X1 and user X2 are playing multiplayer as described above, the control unit 203 receives an operation of user X1 from the user terminal 10 used by user X1 and transmits the operation to the user terminal 10 used by user X2. Similarly, the control unit 203 receives an operation of user X2 from the user terminal 10 used by user X2 and transmits the operation to the user terminal 10 used by user X1.

[0055] According to this, control for progressing a multiplay based on operations by users X1 and X2 is executed on both the user terminals 10 used by users X1 and X2, and a multiplay screen reflecting the operations of both users X1 and X2 can be displayed on both the user terminals 10 used by users X1 and X2. In other words, in the game system 1 according to this embodiment, game play content triggered by the operation of user X2 is reproduced (synchronized) on the multiplay screen of the user terminal 10 used by user X1, and game play content triggered by the operation of user X1 is reproduced (synchronized) on the multiplay screen of the user terminal 10 used by user X2, thereby real-time multiplay can be realized using the user terminals 10 of users X1 and X2.

[0056] The game system 1 according to this embodiment provides a game play environment for users to play a location-based game, and this "provision of the game play environment" is realized by a game program (i.e., the game program 13A executed on the above-mentioned multiple user terminals 10 and the game program 23A executed on the server device 20) that runs on the game system 1. However, the game program according to this embodiment may be a part of the above-mentioned game programs 13A and 23A.

[0057] Furthermore, in the game system 1 according to this embodiment, for example, the server device 20 may have at least some of the functions of the multiple user terminals 10, or the multiple user terminals 10 may have at least some of the functions of the server device 20. Furthermore, the game system 1 may include devices other than the multiple user terminals 10 and the server device 20. That is, the game program according to this embodiment (game programs 13A and 23A) may be executed by the multiple user terminals 10, the server device 20, or other devices.

[0058] An example of setting data related to a position information game included in the game data will now be described with reference to Fig. 6. Fig. 6 shows an example of the ability values ​​(status) of an enemy character that includes a plurality of destructible parts.

[0059] In the example shown in FIG. 6, the ability values ​​of an "enemy character E1" are shown, which include multiple destructible body parts. As shown in FIG. 6, the enemy character E1 is an enemy character that includes destructible body parts: a "main body," a "head," "front legs," "hind legs," and a "tail." The "main body" corresponds to the parts of the enemy character E1 other than the head, front legs, hind legs, and tail. The destructible body parts are not limited to the parts shown in FIG. 6, and are set according to the enemy character, such as the belly, back, right wing, left wing, etc.

[0060] Each destructible part has a durability value (hit points) set, and when this durability value reaches zero, the part is destroyed and the user is given a reward associated with that part (part destruction reward).

[0061] In the example shown in FIG. 6, for example, the durability value of the "head" is set to "500." The user can destroy the head of the enemy character E1 by attacking the head and reducing the durability value of the head, "500," to zero. This allows the user to acquire an "item a1" as a reward for destroying the part associated with the head. Also, in the example shown in FIG. 6, the durability value of the "tail" is set to "1000." The user can destroy the tail of the enemy character E1 by attacking the tail and reducing the durability value of the tail, "1000," to zero. This allows the user to acquire an "item a4" as a reward for destroying the part associated with the tail. Although detailed explanations are omitted here, the same applies to the durability values ​​set for the "front legs" and "hind legs."

[0062] The user can defeat an enemy character by reducing the durability of the "main body" to 0. If the durability of the main body reaches 0 before the durability of other parts (for example, the head, front legs, hind legs, tail, etc.) reaches 0, the user will not be able to obtain the part destruction rewards associated with the other parts.

[0063] In addition to the durability values ​​described above, destructible parts are also assigned weak spots and weak attributes. Weak weapons and weak attributes indicate weapons and attributes that can efficiently reduce the durability value of each part.

[0064] In the example shown in FIG. 6, for example, a "bow" is set as the weak weapon for the "head," and "fire" is set as the weak attribute. In other words, when attacking the head of enemy character E1, the user can more efficiently reduce the durability value of the head by attacking with a bow than by attacking with another weapon (e.g., a sword). Similarly, when attacking the head of enemy character E1, the user can more efficiently reduce the durability value of the head by attacking with a fire-attribute weapon than by attacking with a weapon of another attribute (e.g., water attribute).

[0065] In the example shown in FIG. 6, for example, "sword" is set as the weak weapon for the "tail," and "water" is set as the weak attribute. In other words, when attacking the tail of enemy character E1, the user can more efficiently reduce the durability value of the tail by equipping the user with a sword than by equipping the user with another weapon (e.g., a bow, etc.). Similarly, when attacking the tail of enemy character E1, the user can more efficiently reduce the durability value of the tail by equipping the user with a weapon of water attribute than by equipping the user with a weapon of another attribute (e.g., fire attribute, etc.). Although a detailed explanation will be omitted here, the same applies to the weak weapons and weak attributes set for the "front legs" and "hind legs."

[0066] Here, the destructible parts include the "main body," but the main body may be set with a durability value, a weak point weapon, a weak point attribute, and a reward separately from the destructible parts.

[0067] In this embodiment, the destructible parts are characterized in that they are associated with the durability value, weak spot, weak spot attribute, and reward described above, but are not associated with a location (point).

[0068] 6 shows a case where items usable in the game, such as items a1 to a4, are set as part destruction rewards, but other rewards may also be points usable in the game, lottery rights, advantageous effects in the game progress, advantageous effects when cooperating with other users (when playing multiplayer), advantageous effects when competing against other users, improvements to the abilities of characters used by the user, experience points for raising the level of characters used by the user, etc. The various types of rewards may be selected in advance from a plurality of types of rewards by the user, or may be determined randomly.

[0069] An example of the processing procedure of the game system 1 according to this embodiment will be described below with reference to the flowchart in Fig. 7. Here, it is assumed that a user (hereinafter referred to as the first user) using one user terminal (hereinafter referred to as the first user terminal 10) among the multiple user terminals 10 plays a location information game.

[0070] In this case, the game program 13A is started in the first user terminal 10, and a map screen including a map of real space is displayed on (the display 15 provided in) the first user terminal 10. On the map screen displayed on the first user terminal 10, as described above, a first object corresponding to the first user is placed at the current position of the first user, and a second object indicating the battle event (an enemy character to be fought in the battle event) is placed at the position where the battle event occurs.

[0071] The first user moves through the real space while checking the positions of the first object and the second object on the map screen displayed on the first user terminal 10.

[0072] The game system 1 acquires the position of the first user moving in real space as described above (step S1). The position of the first user acquired in step S1 is managed as user data related to the first user in, for example, the server device 20 (data management unit 202).

[0073] The position (or position information indicating) of the first user can be acquired, for example, by using a GPS installed in the first user terminal 10, but may also be acquired by other methods.

[0074] The position of the first object placed on the map screen displayed on the first user terminal 10 is updated based on the position of the first user acquired in step S1.

[0075] When the process of step S1 is executed, the game system 1 acquires the occurrence position of a battle event managed, for example, in the server device 20 (data management unit 202) (step S2). Note that, if multiple battle events are occurring in the position information game, for example, the occurrence position of the battle event near the position of the first user acquired in step S1 is acquired in step S2.

[0076] When the game system 1 receives, for example, in the server device 20 (control unit 203), from the first user terminal 10, an operation by the first user to select a second object placed at a predetermined battle event occurrence position (for example, an operation by the first user to tap the second object), the game system 1 determines whether or not the position of the first user acquired in step S1 satisfies a first condition for the battle event occurrence position (step S3). Note that the first condition is assumed to be predetermined in, for example, the game system 1. Specific examples of the first condition will be described later.

[0077] If it is determined that the first condition is not satisfied (NO in step S3), the process returns to step S1 and is repeated.

[0078] On the other hand, if it is determined that the first condition is met (YES in step S3), the game system 1 notifies the first user that he or she can participate in the battle event corresponding to the operation of the first user received in step S3 (i.e., that he or she can battle an enemy character of the second object) (step S4).

[0079] Thereafter, when the game system 1 receives from the first user terminal 10 an operation by the first user to participate in the battle event notified in step S3, it transitions the screen displayed on the first user terminal 10 from the map screen to a preparation screen before the start of the battle event with the first user as the host (step S5). The host is the leader of the party participating in the battle event.

[0080] Here, when a user other than the first user is playing a position information game, the server device 20 (data management unit 202) manages the positions of the other users, for example.

[0081] For this reason, the game system 1 acquires the positions of other users managed in the server device 20, and searches for a user (hereinafter referred to as a second user) who is in a position that satisfies the second condition (step S6). It should be noted that the second condition is assumed to be predetermined in the game system 1, for example. Specific examples of the second condition will be described later.

[0082] Here, it is assumed that the processing of step S6 is automatically executed when the above-mentioned preparation screen is displayed on the first user terminal 10, but this processing may also be executed when a first user operation on the preparation screen, which is an operation by the first user to search for a second user, is received from the first user terminal 10.

[0083] When the process of step S6 is executed, the game system 1 notifies the second user found in step S6 to build a relationship with the first user (step S7). The notification in step S7 is sent, for example, via the user terminal 10 used by the second user (hereinafter referred to as the second user terminal 10), and is a notification to encourage the second user to participate in a battle event together with the first user and to play multiplayer in the battle event.

[0084] When the game system 1 receives from the second user terminal 10 an operation by the second user to build a relationship with the first user (i.e., an operation by the second user to play multiplayer with the first user), it transitions the screen displayed on the second user terminal 10 from the map screen to a preparation screen for participating in a battle event hosted by the first user (step S8). On the preparation screen, both the first user and the second user can confirm the members of the party that will participate in the battle event hosted by the first user.

[0085] Thereafter, when the game system 1 receives from the first user terminal 10 an operation by the first user to start a battle event, it refers to the ability value data of the enemy character to be fought in the battle event from the game data stored in the server device 20, and performs a process of allocating multiple destructible parts (excluding the main body) included in the enemy character to the first user and the second user who has established a relationship with the first user in step S8 (step S9). Note that the method of allocating destructible parts to the first user and the second user will be described later.

[0086] When the process of step S9 is executed, the game system 1 transitions the screens displayed on the first user terminal 10 and the second user terminal 10 of the second user who established a relationship with the first user in step S8 from the preparation screen to a battle screen for fighting enemy characters in a battle event hosted by the first user (step S10). This starts the battle event hosted by the first user. Details of the battle screen will be described later.

[0087] On the battle screen, each user can attack an enemy character by performing an attack operation. If a user's attack is successful (for example, if a user's attack hits an enemy character), the user can inflict damage on the body part assigned to them in step S9 (i.e., reduce the durability value set for that body part). If a user reduces the durability value of their assigned body part to zero and destroys their assigned body part, they may be assigned a body part (including the main body in this case) that is not assigned as a destructible body part in step S9 as a new body part, or they may be assigned a body part that was assigned to another user in step S9 and has not yet been destroyed as a new body part.

[0088] The game system 1 determines whether or not the end condition of the battle event started in step S10 has been met (step S11). The end condition of the battle event can be, for example, the durability value of the enemy character's main body being reduced to zero, the enemy character escaping, the annihilation or escape of all users, or the passage of a specific time period.

[0089] If it is determined that the end condition is not met (NO in step S11), the battle event started in step S10 continues.

[0090] On the other hand, if it is determined that the termination condition is met (YES in step S11), the game system 1 grants a reward based on the result of the battle event to the first user and the second user who participated in the battle event (step S12), and ends this series of processes. Note that the reward is granted, for example, by adding information indicating that the first user and the second user have the reward based on the result of the battle event to the user data managed in the server device 20 (data management unit 202).

[0091] 7, it is assumed that the processing of steps S1 to S12 is mainly performed by the server device 20 (control unit 203), but at least a part of the processing of steps S1 to S12 may be performed on the user terminal 10 side (for example, the control unit 102, etc.). In other words, the processing shown in FIG. 7 may be processing that is executed by at least the entire game system 1.

[0092] The operation of the game system 1 according to this embodiment will be described in detail below. Fig. 8 shows an example of a map screen 400 displayed on the first user terminal 10. Although shown schematically in Fig. 8, on the map screen 400, a first object O1a is placed at the current position of the first user, and a second object O2 is placed at the position where a battle event will occur.

[0093] Here, it is assumed that the map screen 400 shown in Fig. 8 is updated to the map screen 400 shown in Fig. 9 as a result of the first user moving in real space. In this case, the game system 1 determines whether or not the position of the first object O1a (i.e., the position of the first user) satisfies a first condition for the position of the second object O2 (i.e., the occurrence position of the battle event).

[0094] In this embodiment, the first condition includes, for example, that the position of the first object O1a and the position of the second object O2 are in a predetermined positional relationship (hereinafter referred to as the first positional relationship). Specifically, as shown in FIG. 9, for example, when the first object O1a is within a predetermined range r1 from the second object O2, the game system 1 determines that the positions of the first object O1a and the second object O2 are in the first positional relationship (i.e., the first condition is satisfied). On the other hand, when the first object O1a is not within the predetermined range r1 from the second object O2, the game system 1 determines that the positions of the first object O1a and the second object O2 are not in the first positional relationship (i.e., the first condition is not satisfied). In the example shown in FIG. 9, the predetermined range r1 is a circular range centered on (the position of) the second object O2, and is assumed to be predetermined in the game system 1 (the server device 20, etc.).

[0095] Next, the game system 1 searches for a second user who is in a position that satisfies a second condition. In this embodiment, the second condition includes, for example, that the position of the second user and the position of the first user are in a predetermined positional relationship (hereinafter referred to as a second positional relationship).

[0096] 10 shows an example of a map screen 500 displayed on the second user terminal 10 used by the second user. According to the example shown in FIG. 10, the first object O1b of the second user is within a predetermined range r2 from the first object O1a of the first user. In this case, the game system 1 searches for a second user who is in a second positional relationship with the position of the first object O1a of the first user (i.e., who satisfies the second condition). Note that the predetermined range r2 in the example shown in FIG. 10 is a circular range centered on (the position of) the first object O1a, which is wider than the range r1 shown in FIG. 9, and is assumed to be predetermined in the game system 1 (the server device 20, etc.), for example.

[0097] When a second user who is in a position that satisfies the second condition is found as described above, the game system 1 sends a notification to the second user via the second user terminal 10, for example, to build a relationship with the first user.

[0098] Next, a process executed in the game system 1 according to this embodiment, in which a plurality of destructible parts included in an enemy character are assigned to each user, will be described.

[0099] 11A and 11B are diagrams illustrating an example of a process for allocating multiple destructible parts of an enemy character to each user. Here, as shown in FIG. 11A, a user U1 is located in the upper right corner of the figure as viewed from the second object O2, a user U2 is located in the upper left corner of the figure as viewed from the second object O2, a user U3 is located in the lower left corner of the figure as viewed from the second object O2, and a user U4 is located in the lower right corner of the figure as viewed from the second object O2. Note that one of users U1 to U4 corresponds to the first user, and the remaining users correspond to the second users. Here, any one of users U1 to U4 may be the first user.

[0100] Here, it is assumed that the enemy character to be fought in the battle event corresponding to the second object O2 shown in FIG. 11(a) is the enemy character E1 shown in FIG.

[0101] The game system 1 allocates a plurality of destructible parts included in the enemy character E1 to be fought in the battle event to the users U1 to U4 participating in the battle event corresponding to the second object O2, according to the positions of each of the users U1 to U4 when the multiplayer play starts.

[0102] Here, as shown in Figure 11(b), user U1, who is located near the head of enemy character E1, is assigned the "head" as the part to be destroyed, user U2, who is located near the tail of enemy character E1, is assigned the "tail" as the part to be destroyed, user U3, who is located near the hind legs of enemy character E1, is assigned the "hind legs" as the part to be destroyed, and user U4, who is located near the front legs of enemy character E1, is assigned the "front legs" as the part to be destroyed.

[0103] As mentioned above, the multiple destructible parts of the enemy character E1 fought in the battle event corresponding to the second object O2 do not have information regarding their positions. Therefore, the game system 1 assigns parts close to the current position of each user U1 to U4 as parts to be destroyed to each user U1 to U4 based on the drawing information of the second object O2 (the appearance of the enemy character on the map screen) and the position of each user U1 to U4 when the multiplayer play started.

[0104] Information indicating the parts to be destroyed by each of the users U1 to U4 (that is, information indicating which parts are assigned to which users) is managed by the data management unit 202 of the server device 20, for example.

[0105] In this way, the parts to be destroyed are assigned based on each user's position relative to the location where the battle event occurs (second object O2) when multiplayer play begins. This, for example, can motivate a user who wants a reward for destroying a specific part to move (walk) to a location where the specific part is likely to be assigned as the part to be destroyed.

[0106] As shown in FIG. 12, when a multiplayer game starts and multiple users are located close to each other, the game system 1 may assign similar body parts (or the same body parts) to the multiple users located close to each other as the body parts to be destroyed. In the example shown in FIG. 12, when a multiplayer game starts, users U1 and U4 are both located in the upper right corner of the figure as seen from the second object O2 (i.e., near the head of the enemy character E1), and the users U1 and U4 are assigned the "head" as the body part to be destroyed (see FIGS. 12(a) and 12(b)). The game system 1 determines that the multiple users are located close to each other when the positional relationship between the multiple users is determined in advance (for example, when the distance between the multiple users is less than a predetermined distance).

[0107] An example of the battle screen 600 will now be described with reference to Fig. 13. The example shown in Fig. 13 illustrates the battle screen 600 displayed on the user terminal 10 of user U1, who has been assigned the "head" as the body part responsible for destruction.

[0108] 13, the battle screen 600 displays at least the character C1 used by the user U1, the enemy character E1 that the user U1 is fighting, and a message informing the user U1 of the body part that the user U1 is responsible for destroying. Here, it is assumed that the user U1 is assigned the "head" as the body part that the user U1 is responsible for destroying, and therefore the battle screen 600 displays a message informing the user U1 of the body part that the user is responsible for destroying, saying, "Your body part that you are responsible for destroying is 'head'." This allows the user U1 to know (recognize) the body part that the user U1 is assigned to destroy.

[0109] If the user U1 performs an attack operation on the battle screen 600 and the attack is successful, the user U1 can inflict damage on the head, which is the body part that the user U1 is responsible for destroying. The game system 1 controls the attack so that the durability value of the head, which is the body part that the user U1 is responsible for destroying, is reduced regardless of which body part of the enemy character E1 the attack by the user U1 hits.

[0110] According to this control, by allocating different parts to multiple users as parts responsible for destruction, as shown in Fig. 11, even if the attacks of the multiple users hit the same part of the enemy character, the parts affected by the attacks of the multiple users (parts whose durability value is reduced) can be made different. Also, according to the control described above, by allocating similar parts to multiple users as parts responsible for destruction, as shown in Fig. 12, for example, to users U1 and U4, regardless of which part of the enemy character the attacks of the multiple users hit, the parts affected by the attacks of the multiple users (parts whose durability value is reduced) can be made similar (the same).

[0111] This type of control is possible precisely because the multiple destructible parts of the enemy character do not have information about their positions. With this type of control, each user does not need to travel to a specific location to destroy the part assigned to them, as would be the case if the multiple destructible parts of the enemy character had information about their positions. In other words, this type of control can increase the interest of each user playing a location-based game.

[0112] Furthermore, in general, in games in which players battle enemy characters that have multiple destructible body parts, destroying a specific body part often requires the user to have a certain level of skill (player skill), such as hitting a specific body part with an attack.However, by using the control described above, no matter which body part of the enemy character the attack hits, the attack will be considered to have hit the specific body part assigned to the user, so even users who are not good at games can destroy the specific body part assigned to them.

[0113] In addition, when a body part assigned to a specific user is destroyed by the specific user (i.e., as the battle event progresses), the game system 1 executes a process of assigning another body part that has not yet been destroyed (i.e., a body part that has not yet affected the progress of the battle event) to the specific user as a new body part to be destroyed.

[0114] At this time, the game system 1 may assign to the specified user a part that was assigned to another user who was located near the specified user when the multiplayer mode started as a new part to be destroyed, or may assign to the specified user a part (i.e., the main body) that satisfies the end condition of the battle event as a new part to be destroyed.

[0115] In Figure 11, we have explained a case in which the game system 1 allocates multiple destructible parts of the enemy character E1 that will be fought in the battle event to the users U1 to U4 participating in the battle event according to the position of each user U1 to U4 when the multiplayer play begins.However, as shown in Figure 14, the game system 1 may also randomly allocate multiple destructible parts of the enemy character E1 to each user U1 to U4.

[0116] In the example shown in Figure 14, user U1, who is located near the head of enemy character E1, is assigned the "tail" as the part to be destroyed, user U2, who is located near the tail of enemy character E1, is assigned the "front legs" as the part to be destroyed, user U3, who is located near the hind legs of enemy character E1, is assigned the "head" as the part to be destroyed, and user U4, who is located near the front legs of enemy character E1, is assigned the "hind legs" as the part to be destroyed (see Figures 14(a) and (b)).

[0117] In this way, since the parts to be destroyed are assigned regardless of each user's position when the multiplayer game begins, each user cannot predict the part to be destroyed that will be assigned to them based on their own position on the map screen (first object O1) and the appearance of the enemy character (second object O2), and they cannot know which part has been assigned to them until the battle event begins, which gives users a sense of anticipation (excitement) as to "which part will be assigned to them next."

[0118] The game system 1 according to the present embodiment may allocate multiple destructible body parts included in an enemy character to be fought in a battle event in accordance with requests from multiple users participating in the battle event. Here, an example of a request setting screen 700 will be described with reference to FIG. 15 .

[0119] 15, the desire setting screen 700 displays the user name, rank, the body part that the user wants to destroy when the enemy character fought in the battle event is a predetermined enemy character, the reward that the user wants to obtain when fighting that enemy character, and the number of times the enemy character has been defeated in the past (number of kills). In the example shown in FIG. 15, "player P1" is displayed as the user name, "1000" is displayed as the rank, "head" is displayed as the body part that the user wants to destroy when fighting "enemy character E1," "item a1" that can be obtained by destroying the head and "item a4" that can be obtained by destroying the tail are displayed as rewards that the user wants to obtain when fighting "enemy character E1," and "50" is displayed as the number of kills.

[0120] Each user can set the body part they want to destroy and the reward they want to obtain for each enemy character they will fight in the battle event (i.e., they can set their desires regarding the body part they are responsible for destroying) on ​​the desire setting screen 700. The desires set by each user are managed as the user data of each user in, for example, the data management unit 202 of the server device 20.

[0121] When starting a multiplayer game, the game system 1 refers to the user data of each user and allocates to each user a plurality of destructible parts included in a predetermined enemy character in accordance with the requests of each user when fighting the predetermined enemy character.

[0122] In addition, if multiple users have the same desire to destroy a certain part (or requests regarding that part), the game system 1 may allocate the desired parts to the multiple users (i.e., the same part may be allocated to multiple users).

[0123] Alternatively, the game system 1 may determine which user's request should be prioritized. In this case, users whose requests are prioritized are allocated the body parts they requested, while users whose requests are not prioritized are allocated body parts different from their requests. The user's request to be prioritized may be determined, for example, based on the rank or number of kills described above, or based on each user's previous multiplayer history. For example, the higher the rank or number of kills, the higher the request of the user. Alternatively, the request of a user who was not allocated the body part they requested in the previous multiplayer game may be prioritized. Note that each user's multiplayer history is managed as user data for each user, for example, by the data management unit 202 of the server device 20.

[0124] For a user whose request is not prioritized, the game system 1 may assign, as the body part to be destroyed, a body part that corresponds to the reward set by the user in "reward to be obtained" and that can earn a reward different from the reward corresponding to the body part that the user wants to destroy. In this way, even a user whose request is not prioritized can be assigned a body part that is thought to be a second choice as the body part to be destroyed.

[0125] This method of allocating parts to be destroyed according to user requests is particularly useful in games in which rewards corresponding to destroyed parts are awarded only to the user who destroyed those parts.

[0126] The game system 1 according to this embodiment may vary the number of parts allocated to each user depending on the number of destructible parts (excluding the main body) included in the enemy character to be fought in the battle event and the number of users participating in the battle event.

[0127] For example, if the number of users participating in a battle event is smaller than the number of destructible parts included in enemy characters to be fought in the battle event, the game system 1 assigns multiple parts as parts to be destroyed to at least one of the users participating in the battle event. Also, if the number of users participating in a battle event is greater than the number of destructible parts included in enemy characters to be fought in the battle event, the game system 1 assigns the same parts as parts to be destroyed to at least two of the users participating in the battle event.

[0128] As shown in Figure 16, when three users U1 to U3 participate in a battle event in which they fight against an enemy character E1 that has four destructible parts other than its main body, the game system 1 assigns two parts to at least one of the users U1 to U3 as parts to be destroyed. In the example shown in Figure 16, user U1, who is located near the head of the enemy character E1 and closer to the front legs of the enemy character E1 than the other users, is assigned the "head" and "front legs" as parts to be destroyed, user U2, who is located near the tail of the enemy character E1, is assigned the "tail" as part to be destroyed, and user U3, who is located near the hind legs of the enemy character E1, is assigned the "hind legs" as part to be destroyed (see Figures 16(a) and (b)).

[0129] As shown in Fig. 17, when five users U1 to U5 participate in a battle event in which they fight against an enemy character E1 that has four destructible parts other than its main body, the game system 1 assigns the same part to at least two of the users U1 to U5 as the part to be destroyed. In the example shown in Fig. 17, users U1 and U5 who are located near the head of the enemy character E1 are assigned the "head" as the part to be destroyed, user U2 who is located near the tail of the enemy character E1 is assigned the "tail" as the part to be destroyed, user U3 who is located near the hind legs of the enemy character E1 is assigned the "hind legs" as the part to be destroyed, and user U4 who is located near the front legs of the enemy character E1 is assigned the "front legs" as the part to be destroyed (see Figs. 17(a) and (b)).

[0130] The game system 1 according to this embodiment may allocate multiple destructible body parts included in enemy characters fought in a battle event according to the multiplay history of multiple users participating in the battle event. The multiplay history of each user is managed as user data of each user, for example, in the data management unit 202 of the server device 20.

[0131] For example, when starting a multiplayer game, the game system 1 may refer to the user data of each user and assign each user the same body part to be destroyed as in the previous multiplayer game (or the same body part to be destroyed). This method of assigning body parts to be destroyed is particularly useful when continuing to battle the same enemy character as in the previous multiplayer game (for example, in a battle event in which the previous battle event ends with the enemy character fleeing and a battle with that enemy character is to be held again). When continuing to battle the same enemy character as in the previous multiplayer game, the durability value of each body part included in the enemy character may be inherited from the value at the end of the previous battle event. This makes it possible to realize a game in which one user destroys one body part across multiple battle events.

[0132] Furthermore, when starting a multiplayer game, the game system 1 may refer to the user data of each user and assign each user a body part to be destroyed that is different from the body part to be destroyed in the previous multiplayer game. This allows each user to be assigned a different body part to be destroyed each time, which prevents the user from getting bored of the game by being assigned the same body part as in the previous multiplayer game.

[0133] The game system 1 according to the present embodiment may allocate multiple destructible parts included in an enemy character fought in a battle event according to the ability value of the enemy character (for example, a weak weapon or weak attribute set for each part) and the ability value of each user participating in the battle event (for example, a favored weapon or favored attribute set as user data). This allows, for example, a part of the multiple destructible parts included in an enemy character that is weak to a bow to be allocated to a user who is favored to a bow. In other words, it is possible to allocate multiple destructible parts included in an enemy character in a way that enables them to be efficiently destroyed.

[0134] The destruction parts assigned to each user participating in the battle event as described above may be exchanged when an agreement is reached between multiple users.

[0135] Here, for example, assume that user X1 requests user X2 to exchange destruction-responsible parts. In this case, when the game system 1 receives an exchange request from the user terminal 10 used by user X1 indicating that user X1 wishes to exchange destruction-responsible parts with user X2, the game system 1 notifies user X2 that user X1 has requested to exchange destruction-responsible parts. When the game system 1 receives an operation from the user terminal 10 used by user X2 indicating that user X2 accepts the exchange of destruction-responsible parts, the game system 1 exchanges and allocates the destruction-responsible part assigned to user X1 with another destruction-responsible part assigned to user X2 (in other words, the destruction-responsible part of user X1 is exchanged with the destruction-responsible part of user X2).

[0136] The durability value of each part included in the enemy character may be inherited from the value before the exchange. In other words, the exchange of the destruction-responsible part may be performed in a state where damage inflicted by user X1 and user X2 has accumulated before the exchange. Alternatively, the durability value of each part included in the enemy character may not be inherited from the value before the exchange. In other words, the exchange of the destruction-responsible part may be performed in a state where damage inflicted by user X1 and user X2 has been reset before the exchange.

[0137] The above-mentioned exchange request is transmitted, for example, after the user X1 recognizes the destruction-responsible portion assigned to him / her. As an example, if the user X1 can recognize the destruction-responsible portion assigned to him / her after the transition to the battle screen, the above-mentioned exchange request is transmitted during the battle event. Alternatively, if the user X1 can recognize the destruction-responsible portion assigned to him / her during the transition from the preparation screen to the battle screen, the above-mentioned exchange request is transmitted during the transition from the preparation screen to the battle screen or during the battle event.

[0138] Furthermore, the exchange request can be sent after user X1 recognizes the destruction-responsible body part assigned to him / her as described above, but is not limited to this and may be sent when user X1 satisfies a predetermined condition. Examples of the predetermined condition include that it is within a certain time since the start of the battle event, that the durability value of the body part to be exchanged (i.e., the durability value of the destruction-responsible body part assigned to user X2) remains at a certain value or more, that the durability value of the destruction-responsible body part assigned to user X2 has decreased by a certain value or more, etc.

[0139] Such an exchange of destruction-responsible parts can improve each user's satisfaction with the game.

[0140] The positions of the users (first user and second user) and the occurrence position of the battle event described in this embodiment are assumed to be positions in real space or virtual space positions related to positions in real space, but the user positions and the occurrence position of the battle event may be expressed in absolute position coordinates using latitude and longitude, or in relative position coordinates based on a predetermined position. Furthermore, the user positions and the occurrence position of the battle event may be positions defined on a map based on, for example, the Mercator projection or the Mollweide projection, or may be positions based on other coordinate systems.

[0141] In addition, in this embodiment, it is assumed that the positions of the users (first user and second user) are acquired using, for example, GPS, but the positions of the users may be positions identified based on a predetermined building or object, or may be positions detected by various sensors (infrared sensor, LiDAR, etc.). Furthermore, the positions of the users may be positions identified based on the communication range and communication strength of the user terminal 10, the position of a base station connected to the user terminal 10, etc.

[0142] Furthermore, the positions of the users (first user and second user) and the location where the battle event occurs in this embodiment may be information about the variation of position coordinates that realize the game or metaverse, etc. In this case, the virtual space may be constructed across, for example, multiple games or metaverses.

[0143] As described above, the game system 1 according to this embodiment generates an event (battle event) that can be progressed in multiplayer by multiple users in a virtual space associated with real space, and allocates elements that affect the progress of the event (for example, destructible parts included in an enemy character fought in a battle event) to each user depending on the start of the multiplayer play.

[0144] This makes it possible to increase the interest of users who participate in the event.

[0145] In this embodiment, the case where a user plays a location-based game has been mainly described, but the system according to this embodiment can be applied to any case where a user moves to a location where an event occurs and plays multiplayer games with other users, and may be applied to systems other than game systems. Specifically, this embodiment may be applied to, for example, running or fitness activities.

[0146] The present invention is not limited to the above-described embodiments, and the components can be modified and embodied in practice without departing from the spirit of the invention. Furthermore, various inventions can be created by appropriately combining multiple components disclosed in the above-described embodiments. For example, some components may be omitted from all the components shown in the embodiments. Furthermore, components from different embodiments may be appropriately combined.

[0147] "Addendum" Some of the features of the present invention are summarized below. "assignment" For example, the purpose is to increase the interest of the user. "Solution" (1) Computer, a control means for generating an event that can be progressed in a multiplay by a plurality of users in a virtual space associated with a real space, and allocating elements that affect the progress of the event to each user in response to the start of the multiplay; A program that functions as a (2) The event includes a plurality of factors that affect the progress of the event; the control means places an object indicating the occurrence of the event at a position where the event occurs; (1) The program described in (1). (3) the control means allocates each element according to the position of each user relative to the object when the multiplay is started; (2) The program described in (2). (4) when the multiplayer play is started and a plurality of users are at predetermined positions relative to the object, the control means allocates the same element to the plurality of users at the predetermined positions; (3) The program described in (3). (5) The similar elements are influenced by multiple users at the predetermined location. (4) The program described in (4). (6) The control means randomly allocates each element. (2) The program described in (2). (7) The control means allocates each element in accordance with requests from each user. (2) The program described in (2). (8) the control means allocates the predetermined elements to the plurality of users when the plurality of users have set allocations of the predetermined elements; (7) The program described in (7). (9) the control means, when a plurality of users have set allocations of predetermined elements, allocates the predetermined element to one user and allocates an element other than the predetermined element to another user in accordance with play histories of the plurality of users; (7) The program described in (7). (10) the control means allocates each element according to the multiplay history of each user; (2) The program described in (2). (11) the control means assigns the same elements to each user as in the previous multiplayer game; (10) The program described in (10). (12) the control means assigns to each user an element different from that of the previous multiplayer game; (10) The program described in (10). (13) The number of elements allocated to each user varies depending on the number of users participating in the multiplayer game. A program according to any one of (3), (6), (7), and (10). (14) The number of elements allocated to each user increases as the number of users participating in the multiplay decreases, and decreases as the number of users participating in the multiplay increases. (13) The program described in (13). (15) when a predetermined condition for a predetermined element allocated to a predetermined user is satisfied and the event progresses, the control means allocates an element other than the predetermined element to the predetermined user; A program according to any one of (3), (6), (7), and (10). (16) The other element is an element that is assigned to another user who is located near the predetermined user when the multiplay is started, and does not affect the progress of the event. (15) The program described in (15). (17) the other element is an element for ending the event. (15) The program described in (15). (18) the control means, in response to a request from a predetermined user, exchanges the predetermined element allocated to the predetermined user with another element of another user different from the predetermined user and allocates the exchanged element; (2) The program described in (2). (19) The location of the event includes information about the location; Each of the elements does not include information about location. (2) The program described in (2). The solution constituted by the above program may be appropriately applied to the fields of devices, systems, methods, and media. "effect" According to the configurations (1) to (19), for example, an event that can be progressed in multiplayer by multiple users can be generated in a virtual space associated with real space, and elements that affect the progress of the event can be assigned to each user depending on the start of multiplayer, thereby achieving the effect of increasing interest for users. [Explanation of symbols]

[0148] 1...game system, 10...user terminal, 11...non-volatile memory, 12...CPU, 13...main memory, 13A...game program, 14...wireless communication device, 15...display, 16...touch panel, 20...server device, 21...non-volatile memory, 22...CPU, 23...main memory, 23A...game program, 24...wireless communication device, 101...operation reception unit, 102...control unit, 103...display processing unit, 104...storage unit, 201...storage unit, 202...data management unit, 203...control unit.

Claims

1. Computer, a control means for generating an event that can be progressed in a multiplay by a plurality of users in a virtual space associated with a real space, and allocating elements that affect the progress of the event to each user in response to the start of the multiplay; A program that functions as a

2. The event includes a plurality of factors that affect the progress of the event; the control means places an object indicating the occurrence of the event at a position where the event occurs; The program according to claim 1.

3. the control means allocates each element according to the position of each user relative to the object when the multiplay is started; The program according to claim 2.

4. when the multiplayer play is started and a plurality of users are at predetermined positions relative to the object, the control means allocates the same element to the plurality of users at the predetermined positions; The program according to claim 3.

5. The similar elements are influenced by multiple users at the predetermined location. The program according to claim 4.

6. The control means randomly allocates each element. The program according to claim 2.

7. The control means allocates each element in accordance with requests from each user. The program according to claim 2.

8. the control means allocates the predetermined elements to the plurality of users when the plurality of users have set allocations of the predetermined elements; The program according to claim 7.

9. the control means, when a plurality of users have set allocations of predetermined elements, allocates the predetermined element to one user and allocates an element other than the predetermined element to another user in accordance with play histories of the plurality of users; The program according to claim 7.

10. the control means allocates each element according to the multiplay history of each user; The program according to claim 2.

11. the control means assigns the same elements to each user as in the previous multiplayer game; The program according to claim 10.

12. the control means assigns to each user an element different from that of the previous multiplayer game; The program according to claim 10.

13. The number of elements allocated to each user varies depending on the number of users participating in the multiplayer game. The program according to any one of claims 3, 6, 7 and 10.

14. the number of elements allocated to each user increases as the number of users participating in the multiplay decreases, and decreases as the number of users participating in the multiplay increases; The program according to claim 13.

15. when a predetermined condition for a predetermined element allocated to a predetermined user is satisfied and the event progresses, the control means allocates an element other than the predetermined element to the predetermined user; The program according to any one of claims 3, 6, 7 and 10.

16. The other element is an element that is assigned to another user who is located near the predetermined user when the multiplay is started, and does not affect the progress of the event. The program according to claim 15.

17. the other element is an element for ending the event. The program according to claim 15.

18. the control means, in response to a request from a predetermined user, exchanges the predetermined element allocated to the predetermined user with another element of another user different from the predetermined user and allocates the exchanged element; The program according to claim 2.

19. The location of the event includes information about the location; Each element does not contain any information about the location. The program according to claim 2.

20. A system comprising a control means for generating an event that can be progressed in multiplayer by multiple users in a virtual space associated with a real space, and allocating elements that affect the progress of the event to each user upon the start of the multiplayer.

Images