JP7723271B2 - Information processing system and program - Google Patents

Description

This disclosure relates to an information processing system and a program.

Conventionally, information processing devices that run games have been known to allow users to participate in various events. For example, Patent Document 1 discloses a game in which players can participate in quest events, lottery events, raid battle events, etc. by using virtual items they possess.

Japanese Patent Application Laid-Open No. 2020-130843

However, in previous versions, users were unable to select the events to be held in advance, which could result in a lack of interest.

In consideration of the above circumstances, this disclosure aims to provide an information processing system and program that enables the realization of highly entertaining games.

According to one aspect of the present disclosure, an information processing system is provided. The information processing system includes a control unit. The control unit is configured to execute the following steps: In the game control step, progress of a game including an event to be held is controlled. In the first reception step, a designation for at least one of a plurality of candidate events that are candidate events in the game is received from each of a plurality of users. In the execution step, when the execution conditions for a first event, which is at least one of the plurality of candidate events, are satisfied by the designation, the first event is executed as an executed event for a specific user of the multiple users. The specific user is the user who designated the first event from the candidate events in the first reception step.

This disclosure makes it possible to create highly entertaining games.

1 is a block diagram showing a hardware configuration of an information processing system 1 according to an embodiment of the present invention. FIG. 2 is a block diagram showing a functional configuration of an information processing device 2 according to the present embodiment. FIG. 2 is an activity diagram showing the flow of information processing executed by the information processing system 1. 10 is a flowchart showing the flow of a raid event. FIG. 4 is an image diagram showing an example of a voting screen 400 visually recognized by a player. FIG. 4 is an image diagram showing an example of a voting screen 400 visually recognized by a player. FIG. 4 is an image diagram showing an example of an event details screen 410 visually recognized by the player. FIG. 4 is an image diagram showing an example of a solicitation screen 420 visible to the player. FIG. 5 is an image diagram showing an example of a request display screen 500 that is visible to other players. FIG. 4 is an image diagram showing an example of an event list screen 430 visually recognized by the player. FIG. 4 is an image diagram showing an example of a quest result screen 440 visually recognized by the player. FIG. 4 is an image diagram showing an example of a ranking screen 450 visually recognized by a player.

[Embodiment]
Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. Various features shown in the following embodiments can be combined with each other.

The program for realizing the software featured in this embodiment may be provided as a non-transitory computer-readable recording medium, may be provided as a downloadable medium from an external server, or may be provided so that the program is launched on an external computer and its functions are realized on a client terminal (so-called cloud computing).

In this embodiment, the term "unit" can also include, for example, hardware resources implemented by circuits in the broad sense, and software information processing that can be specifically realized by these hardware resources. This embodiment handles a variety of information, which can be represented, for example, by physical signal values representing voltage and current, high and low signal values as a collection of binary bits consisting of 0 or 1, or quantum superposition (so-called quantum bits), and communication and calculations can be performed on circuits in the broad sense.

In a broad sense, a circuit is a circuit realized by at least an appropriate combination of a circuit, circuitry, processor, memory, etc. In other words, it includes application-specific integrated circuits (ASICs), programmable logic devices (e.g., simple programmable logic devices (SPLDs), complex programmable logic devices (CPLDs), and field programmable gate arrays (FPGAs)), etc.

1. Description of the Game Fig. 1 is a block diagram showing the hardware configuration of an information processing system 1 according to this embodiment. In the information processing system 1 shown in Fig. 1, an information processing device 2 and a plurality of game devices 3 are communicably connected to each other via a communication network 11, and a game is executed on the game devices 3.

The game according to this embodiment is an online game executed by the information processing system 1. In this game, a user of the game device 3 controls one or more player characters to act in a virtual game space, and pits the player characters against enemy characters, which are non-player characters. A character is also an example of an object.

The above-described games are played using a game device 3, which may be a home game console such as a PlayStation (registered trademark), a portable game console such as a Nintendo Switch (registered trademark), or an electronic device such as a personal computer, smartphone, or tablet device.

2. Overview of Information Processing System 1 As shown in FIG. 1 , the information processing system 1 is composed of an information processing device 2 and multiple game devices 3. The information processing device 2 stores game programs and game data, and manages the game data of the game devices 3 (for each account information described below). The information processing device 2 is composed of, for example, a server. Each of the multiple game devices 3 has the same configuration. Note that in this embodiment, a system is composed of one or more devices or components. Therefore, for example, the information processing device 2 or game device 3 described below alone can also be an example of the information processing system 1.

The game device 3 executes a predetermined game based on user operations. To do so, the game device 3 receives (specifically, downloads and installs) a game program and game data from the information processing device 2 via the communications network 11. Each user is assigned account information, including identification information and a password, that is associated with the game device 3. This account information is transmitted from the game device 3 to the information processing device 2 at login and is used for user authentication on the information processing device 2.

After user authentication, the information processing device 2 and game device 3 become able to communicate with each other. After logging in, the game device 3 receives data necessary for game progress (data related to the game progress status) from the information processing device 2, and then progresses the game while outputting game images and sounds to the display 4a and speaker 4b based on user operations.

2.1 Hardware Configuration Hereinafter, each hardware configuration of the information processing system 1 will be described with reference to FIG.

<Information processing device 2>
1, the information processing device 2 includes a communication unit 21, a storage unit 22, and a control unit 23. The communication unit 21 and the storage unit 22 are electrically connected to the control unit 23 via a communication bus 20.

The communication unit 21 is a so-called network interface that is communicatively connected to each game device 3 via a communication network 11 such as the Internet or a LAN. Main information received by the information processing device 2 via the communication unit 21 includes game program download request information, gacha lottery requests in response to user operations, quest execution requests, autoplay execution/end requests, account information, game data, etc. Main information transmitted by the information processing device 2 via the communication unit 21 includes information confirming that the game program has been received by the game device 3, information related to game media obtained through gacha, etc.

The storage unit 22 is composed of a hard disk drive (HDD), random access memory (RAM), read-only memory (ROM), and a solid state drive (SSD). The storage unit 22 stores various programs, including part of the game program according to this embodiment, as well as various game-related data.

Specifically, for example, the storage unit 22 stores a user DB and a lottery list. The user DB stores, for each identification number of a user playing the game, information such as the user name, user rank, status information related to the player character operated by the user, the amount of consumable media usable in the virtual game space, and information related to parameters, all associated with the user. The lottery list is used for a lottery process commonly known as gacha, and includes multiple pieces of information related to game media to be selected. The lottery list associates information related to the game media (such as name, ability parameters, rarity, and level) with the selection rate in the lottery. Furthermore, the ability parameters include, for example, combat power, HP, attack power, defense power, intelligence, and speed if the game media is a player character.

The control unit 23 is composed of a microcomputer including a CPU and semiconductor memory, and controls the operation of its own device, the information processing device 2. In particular, the control unit 23 realizes various functions related to its own device, the information processing device 2, by reading out predetermined programs stored in the storage unit 22. In other words, information processing by software stored in the storage unit 22 is specifically realized by the control unit 23, which is an example of hardware, and each of the functional units described below can be executed. Note that the control unit 23 is not limited to being single, and implementation may include multiple control units 23 for each function. A combination of these may also be used.

Examples of information processing executed by the control unit 23 include payment settlement processing, user account authentication processing, and gacha lottery selection processing. Payment settlement processing is executed, for example, based on a request for payment necessary to restore a predetermined amount of in-game parameters. User account authentication processing is executed, for example, using user identification information received from the game device 3. Gacha lottery selection processing is processing in which, in response to a gacha lottery request, one or more game media are selected by lottery from a lottery list based on the selection probability for each game medium. According to the gacha lottery selection processing, information about the selected game media and the identification information of the user who performed the operation that sent the lottery request are associated in the user DB, and the user is thereby awarded the game media that they won as a result of their own gacha draw.

To further expand on the above, "game media" refers to electronic data representing elements related to a game, such as the name of the character used as the player character and items (weapons, armor, tools) used by the player character in the virtual game space. Users can obtain game media through direct purchase, completing quests, or through a lottery system known as gacha. Obtained game media is stored and managed in a user DB in association with the identification information of the user who has acquired the game media. Furthermore, "gacha" is a method in which an information processing device 2 randomly selects game media from a lottery list based on a predetermined selection rate. The selected game media is then granted to the user's game device 3. "Granting game media selected through gacha to a user/owning the user" is synonymous with "associating/being associated with the game media selected through the lottery process with identification information identifying the user."

<Game Device 3>
A display 4a, a speaker 4b, and an input device 4c are externally connected or built into the game device 3. The game device 3 also has a communication unit 31, a storage unit 32, a control unit 33, a graphics processing unit 34a, an audio processing unit 34b, and an operation unit 34c. The communication unit 31, the storage unit 32, the graphics processing unit 34a, the audio processing unit 34b, and the operation unit 34c are electrically connected to the control unit 33 via a communication bus 30.

The communication unit 31 is a so-called network interface that is communicatively connected to the communication network 11 in order to send and receive various data between the game device 3 and the information processing device 2. Main information received by the game device 3 via the communication unit 31 includes account information, download request information for new game data, a gacha execution request, a quest execution request, etc. Main information transmitted by the game device 3 via the communication unit 31 includes new game data sent from the information processing device 2 in response to download request information, information regarding game media selected by lottery processing, etc.

The storage unit 32 is composed of an HDD, SSD, RAM, ROM, etc. The storage unit 32 stores game data downloaded from the information processing device 2, various programs including part of the game program, account information for the game device 3 itself, user information, etc. The user information is at least a portion of the information in the user DB stored in the storage unit 22 of the information processing device 2. The user DB manages a master of the user information, and the storage unit 32 of the game device 3 stores at least a portion of this master information distributed from the information processing device 2.

The control unit 33 is composed of a microcomputer including a CPU and semiconductor memory, and controls the operation of the game device 3 itself. In particular, the control unit 33 realizes various functions related to the game device 3 itself by reading out predetermined programs stored in the storage unit 32. In other words, information processing by software stored in the storage unit 32 is specifically realized by the control unit 33, which is an example of hardware, and each of the functional units described below can be executed. Note that the control unit 33 is not limited to being single, and implementation may include multiple control units 33 for each function. A combination of these may also be used.

In particular, the control unit 33 is configured to execute the game in accordance with the operation of the input device 4c by the user of the game device 3, which is the device itself. Specifically, the control unit 33 reads data such as virtual game space objects and textures included in the game data from the storage unit 32, or generates two-dimensional or three-dimensional game image information using data received from the information processing device 2. The game image information is processed by the graphics processing unit 34a, and the processed game images are sequentially displayed on the display 4a. In other words, the control unit 33 is configured to control the display of the display 4a and the audio output of the speaker 4b in accordance with the operation of the user of the game device 3, which is the device itself, when executing the game.

The graphics processing unit 34a renders game images, including characters and various objects related to the virtual game space, in animated format in accordance with game image information output from the control unit 33. The graphics processing unit 34a is connected to the display 4a, which may be, for example, an LCD, and the game images rendered in animated format are displayed on the display 4a as a game screen. The audio processing unit 34b is connected to the speaker 4b and plays and synthesizes game audio in accordance with instructions from the control unit 33, outputting this from the speaker 4b. The operation unit 34c is connected to the input device 4c and transmits and receives data related to operation inputs to and from the input device 4c. The user inputs operation signals to the game apparatus 3 by operating the input device 4c. The input device 4c is a general term for a touch panel integrated with the display 4a, an external game pad, a mouse, a keyboard, etc.

2.2 Functional Configuration Next, the functional configuration of the information processing device 2 of the information processing system 1 will be described with reference to FIG.

Figure 2 is a block diagram showing the functional configuration of the information processing device 2 according to this embodiment. As shown in Figure 2, the control unit 23 executes various programs stored in the memory unit 22, thereby functioning as a game control unit 230, a reception unit 231, an execution unit 232, an adjustment unit 233, a display control unit 234, a notification unit 235, and a specific determination unit 236. In other words, information processing by the software stored in the memory unit 22 is specifically realized by the control unit 23, which is an example of hardware, and can be executed as each functional unit included in the control unit 23.

The game control unit 230 is configured to control the progress of the game. As one example, the game control unit 230 controls the progress of the game, including events that are held. As another example, the game control unit 230 controls the progress of a fighting game in which a player character controlled by a user fights against an enemy character. In one aspect, the fighting game may be executed as a quest with specific achievement conditions, such as "defeating a specific enemy character."

The reception unit 231 is configured to receive various data. For example, the reception unit 231 receives user account information, game data, input from the user, etc. from the storage unit 22 of the information processing device 2 or the game device 3. In this embodiment, the various information received by the reception unit 231 is described as being stored in the storage unit 22.

The execution unit 232 is configured to execute multiple game categories (e.g., events, item shops, gacha, etc.) for users. An event may be, for example, an event held permanently or for a limited time by a game developer or the like that hosts the game. Unless otherwise specified, the following description will assume that an event is a limited-time event. An event may be executed for all users or for some users. An event may also include, for example, multiple quests or stories that can only be played by users who have executed the event. In parallel with a limited-time event, the execution unit 232 may also execute an item shop that sells special game content associated with the event, or a gacha in which special game content can be won. Note that, hereinafter, "executing an event" and "hosting an event" are used interchangeably.

The adjustment unit 233 is configured to adjust various parameters used in the progression of the game. As an example, the adjustment unit 233 adjusts reward information or difficulty level information for an event based on various data received by the reception unit 231.

The display control unit 234 displays various information stored in the memory unit 32 or screens containing such information on the display 4a of the game device 3 in a visible manner. Specifically, the display control unit 234 may generate visual information itself, such as screens, images (e.g., still images or videos), icons, text, etc., generated in a manner visible to humans, or may generate rendering information for displaying the visual information on the display 4a and transmit this, for example.

The notification unit 235 is configured to execute various notifications to the user. The notification method is not particularly limited; for example, the notification unit 235 may cause the display control unit 234 to display a notification on the display 4a of the game device 3, may emit a sound from the speaker 4b, or may vibrate the input device 4c. Notifications by the notification unit 235 may be continuously sent to some users, or may be canceled by input from the user via the input device 4c.

The identification determination unit 236 is configured to identify various information in the game whose progress is controlled by the game control unit 230, determine various states in the game, and so on. In particular, the identification determination unit 236 determines whether the execution conditions for a candidate event have been met.

3. Operational Flow of Information Processing System 1 This section describes the operational flow of the information processing system 1 described above. Incidentally, a game provided by the information processing system 1 includes an in-game, which is the main part played by the player, and an out-game, which is a part in which the player prepares and waits for the in-game to be played. Below, a competitive game will be taken as an example of an in-game, and a game part other than the competitive game will be taken as an example of an out-game. In the out-game, the player can use in-game currency to make purchases and train a player character. Furthermore, the player controls the trained player character to battle enemy characters in the in-game, aiming to complete quests.

Furthermore, in the following explanation, candidate events that may be held in the game will be referred to as candidate events, and an event that is determined to be executed from among the candidate events will be referred to as an executed event. Also, in the following explanation, the main player will be referred to simply as the player (an example of a specific user), and other players will be referred to as other players (an example of other users).

3.1 Overview of Information Processing First, an overview of the information processing executed by the information processing system 1 will be explained, mainly focusing on the flow up to the start of an execution event (see FIG. 3) and the flow up to the end of an execution event (see FIG. 4).

<From voting to holding the execution event>
FIG. 3 is an activity diagram showing the flow of information processing executed by the information processing system 1, mainly up to the holding of an execution event.

First, the game control unit 230 in the control unit 23 of the information processing device 2 starts a voting period for multiple candidate events (activity A001). Note that candidate events include past events that have been held in the past. Past events are events that were executed without accepting votes (designations) in activity A005, described below, and that have already ended. Past events are typically events that were held for all users.

Next, the display control unit 234 causes the display 4a of the game device 3 to display multiple candidate events in a manner that is visible to the player (activity A002). Specifically, the display control unit 234 causes the display 4a to display a voting screen for the candidate events in response to input by the player via the input device 4c of the game device 3.

Next, the player inputs a designation for at least one of the multiple candidate events (activity A003). Specifically, the player inputs a vote for a specific candidate event via the input device 4c. In the following, it is assumed that the player voted for the first event as the specific candidate event.

Next, the player inputs an invitation to other players (activity A004). Specifically, for example, a request (hereinafter referred to as a voting request) is sent to the other players requesting them to vote for the same candidate event as the candidate event for which the player voted. In other words, the request includes content requesting the other players to specify the first event. For example, the notification unit 235 sends the voting request in response to input by the player via the input device 4c. Here, the other player refers to, for example, at least one of the player's friends, or at least one member belonging to the same guild or team.

Next, as a first reception step, the reception unit 231 receives from the player a designation for at least one of the multiple candidate events. Specifically, the reception unit 231 receives the vote from the player entered in activity A003 via the communication network 11 and the communication unit 21 (activity A005).

In parallel with activity A005, the notification unit 235 notifies other players via the communication network 11 and the communication unit 21 that a request has been made by the player (activity A006).

Next, the identification determination unit 236 determines whether the execution conditions for the candidate event are met (activity A007). Below, we will first explain the processing when the execution conditions are not met.

If the specific determination unit 236 determines that the execution conditions have not been met, the specific determination unit 236 further determines whether the voting period has ended (activity A008). If the specific determination unit 236 determines that the voting period has not ended, the processing returns to activity A005 and activity A006. In other words, the reception unit 231 receives votes and vote requests from various players at any time during the voting period. On the other hand, if the specific determination unit 236 determines that the voting period has ended, information processing ends. In other words, in this case, since the execution conditions have not been met and the voting period has ended, it has been determined that none of the candidate events will be executed.

On the other hand, if the identification determination unit 236 determines that the execution conditions for the candidate events are met in activity A007, one of the candidate events is determined to be the executed event (activity A009). For example, if the first event for which the player voted in activity A005 meets the execution conditions, the identification determination unit 236 identifies information that the first event of the candidate events has been determined to be the executed event. Note that if the first event is a past event, a past event that was previously held has been determined to be the executed event. Such an event related to a re-run is referred to as a revival of a past event.

Next, the display control unit 234 displays on the display 4a of the game device 3 in a manner visible to the player that the first event has been determined as the event to be executed (activity A010). Specifically, it displays text or the like on the voting screen indicating that the event to be executed has been determined.

Next, the game control unit 230 ends the voting period for multiple candidate events (activity A011).

Next, the adjustment unit 233 adjusts the reward information and difficulty level information for the first event (activity A012). Reward information is information about rewards granted to players who participate in the event. Specifically, for example, rewards include game content and in-game currency granted to players as the game progresses, and reward information includes the details of rewards such as event rewards and quest rewards, and the conditions for granting rewards to players. Difficulty level information is information about the difficulty level of the event. Specifically, for example, difficulty level information includes information about enemy characters (e.g., stamina, attack power, defense power, techniques used, attributes, weaknesses, etc.), and the conditions for completing quests included in the event (e.g., battle time and number of turns, conditions for usable player characters and techniques, etc.). In this way, by adjusting the execution event determined by voting so that it differs from normally held events, it is possible to realize an aspect that allows players to enjoy the game more.

Next, the execution unit 232 hosts the first event for players who voted for the first event (activity A013). That is, the execution unit 232 executes the first event as an execution event for players who voted for the first event. In particular, if the first event is a past event, the execution unit 232 executes the execution event based on the event information of the past event. Event information is information about the elements that make up the event. Specifically, for example, event information includes the content of the story, still image and video data, information about appearing characters (e.g., enemy characters, boss characters, ally non-player characters, player characters, etc.), data for constructing the virtual space, reward information, difficulty level information, etc. By reviving past events based on the event information of past events, it is possible to hold execution events without increasing the burden on event organizers such as game makers.

Next, the display control unit 234 displays the first event, which is the execution event, on the display 4a of the game device 3 in a manner that is visible to the player (activity A014). Specifically, the display control unit 234 displays the first event on an event screen that is displayed in response to input by the player via the input device 4c of the game device 3. The player can then play a game related to the first event.

<From the start to the end of the event>
Next, the flow from the start to the end of an execution event will be outlined. Here, as an example, the execution event will be described as an event (raid event) related to a fighting game called a raid battle. A fighting game called a raid battle is a game in which multiple player characters, each controlled by multiple players participating in the execution event, fight a common enemy character. There are no particular restrictions on the type of fighting game, but for example, a turn-based battle is adopted. If a player can defeat the raid boss within the limited number of turns or the limited time, the defeat is considered successful. On the other hand, if a player cannot defeat the raid boss within the limited number of turns, or if the player characters' stamina is reduced to zero by the raid boss's attack and they are all annihilated, the defeat is considered unsuccessful.

Figure 4 is a flowchart showing the flow of information processing executed by information processing system 1, primarily focusing on the flow of a raid event. Raid battles include synchronous cooperative battles, in which multiple matched players fight together simultaneously, and asynchronous cooperative battles, in which multiple players individually fight a raid boss and the damage they inflict is added together. The following explanation assumes that asynchronous cooperative battles are used.

Players who participate in a raid event can play quests (hereinafter referred to as normal quests) in which they battle normal enemy characters. The game control unit 230 starts the normal quest in response to input from the player via the input device 4c (step S101). Then, in response to the start of the normal quest, the game control unit 230 causes the battle between the player character and the enemy character to progress. After each normal quest is completed, the display control unit 234 displays the result of the quest (step S102), and the player is given a quest reward depending on whether the quest was successful or not.

Next, the game control unit 230 causes the next normal quest to appear (step S103), and then determines whether or not to cause a raid battle to appear (step S104). In normal quests, the process of completing one quest and then becoming able to challenge the next quest is repeated, and each time a normal quest is completed, a determination is made as to whether or not to cause a raid battle based on predetermined conditions. For example, after a normal quest ends, the game control unit 230 performs a lottery based on a predetermined probability to determine whether or not to cause a raid battle to appear. The predetermined probability may be set based on the user's game play status, such as the amount of stamina consumed, game information, such as the degree of progress in the game, and user information, such as the user rank.

If the next normal quest is to be played, the process returns to the initial processing, and the game control unit 230 starts the next normal quest in response to input from the player via the input device 4c (step S101). On the other hand, if a raid battle has appeared, the game control unit 230 starts the raid battle in response to input from the player via the input device 4c (step S105). The flow of turn-based battles in raid battles is the same as for normal quests.

The identification determination unit 236 determines whether the player succeeded in defeating the raid boss (step S107). If it is determined that the defeat was unsuccessful, the process returns to step S101. If it is determined that the defeat was successful, the game control unit 230 creates a ranking and awards the player a reward for successful defeat. Then, in response to input by the player via the input device 4c, the display control unit 234 displays the current ranking, and information processing ends (step S108).

<Summary of information processing>
To summarize the above, the information processing system 1 according to this embodiment includes the following components: The game control unit 230 controls the progress of a game including an event to be held. The reception unit 231 receives, as a first reception step, a designation of at least one of a plurality of candidate events that are candidates for an event in the game from each of a plurality of users. The execution unit 232 executes the first event as an executed event for a specific user of the multiple users when an execution condition for a first event that is at least one of the plurality of candidate events is satisfied by the designation. The specific user is the user who specified the first event from the candidate events in the first reception unit.

This type of implementation makes it possible to create a highly entertaining game. In particular, when a past event is re-run, new players who have just started playing the game recently and players who were unable to participate in past events can be given the opportunity to take part in that event, making the game more user-friendly. Furthermore, when the event being held is a raid event, due to the nature of the event in which multiple players work together to defeat a raid boss, it is preferable to have as many players as possible. Using voting as described above can prevent a situation in which the number of players participating in the raid event decreases and it becomes stale.

3.2 Details of Information Processing The details of the information processing outlined above will be explained using figures.

<Voting screen>
5 and 6 are image diagrams showing an example of a voting screen 400 visible to the player. Here, an example screen is shown in a state where the player has not yet voted for any candidate events. As shown in FIG. 5, the voting period display 401 displays the remaining period (e.g., the number of remaining days, the remaining time, etc.) until the voting period ends. The voting period here is the voting period started by the game control unit 230 in activity A001.

In the example of FIG. 5, the voting screen 400 displays multiple candidate event banners 402 indicating candidate events. In activity A002, the multiple candidate events displayed by the display control unit 234 are, for example, multiple candidate event banners 402. In response to the reception unit 231 receiving input from the player, such as a tap operation, on the candidate event banner 402, the display control unit 234 displays the event details screen 410 (see FIG. 7).

In the example of Figure 5, the adjustment display 403 for the candidate event "Basilisk, the Emissary from the Underworld" indicates that if it is decided to hold this event, players will be given twice the amount of rewards as when the event was held in the past. In other words, as a first display step, the display control unit 234 displays multiple candidate events along with information indicating that reward information or difficulty information will be adjusted. This configuration can increase players' motivation to participate in past events. It can also encourage players to vote for candidate events recommended by the event organizer.

As in the above example, the reward information or difficulty information for the running event is adjusted based on the event information for the current event or past event. A current event is an event that is run without accepting designation and that has not yet ended. In other words, a current event includes an event that is currently running or an event that will be held in the future, as long as it has not yet ended. Note that current and past events are events that all users can participate in, typically without requiring any special conditions for participation (apart from having progressed through the game to a minimum level, such as having completed the tutorial). In particular, if the running event is a past event, the difficulty of the event may be relatively different from when it was held in the past due to the appearance of new characters, new special attacks, etc. Even in such cases, by adjusting the reward information and difficulty information, it is possible to achieve a mode in which the game can be enjoyed even if the running event is a re-run of a past event.

The condition for executing a candidate event is, for example, collecting a certain number of votes from players. The required number display 406 on the voting screen 400 displays the number of votes required to decide on a candidate event as an executed event. In this embodiment, each player can only cast one vote, and the number of votes is the same as the number of players who voted. The vote number display 405 displays the current number of votes for each candidate event. In the example of Figure 5, the candidate event "Basilisk, Emissary from the Underground" will be decided to be held if 5,000 votes are collected. It also shows that at the moment, this candidate event has collected 3,000 votes.

The acceptance unit 231 accepts a vote from a player in response to receiving an input such as a tap operation from the player on the voting button 404 (first acceptance step). In the example of FIG. 5, the voting button 404 displays a message that voting can be performed by consuming tickets, which are items. For example, in order for a player to vote for the candidate event "Basilisk, the Messenger from the Underworld," the player must consume two tickets. That is, as the first acceptance step, the acceptance unit 231 accepts a designation in response to the player's consumption of items.

In one aspect, the display control unit 234 displays information indicating that a candidate event has been decided to be held. In the example of Figure 5, the candidate event "Resurrected Ancient Dragon Red Dragon" satisfies the conditions for holding the event, so the event decision display 407 is displayed.

If a designation for the first event is accepted after the execution conditions for the first event have been met, the item consumption conditions will be worse than if the designation is accepted before the execution conditions are met. In the example of Figure 5, the candidate event "Resurrected Ancient Dragon Red Dragon," which has already been confirmed to be held, is set to require a larger number of tickets to vote than the other candidate events. This provides an incentive for players to vote early, preventing candidate events from slowly gathering votes and resulting in the popularity poll itself becoming stagnant.

Figure 6 shows an example screen after the player has voted for the candidate event "Basilisk, the Messenger from the Underground," with the number of votes indicated by the vote count display 405 increasing by one from the state in Figure 5 to 3,001. In response to the player's vote, the display control unit 234 changes the voting button 404 for "Basilisk, the Messenger from the Underground" in Figure 6 to display a solicitation screen display button 408, and changes the voting buttons 404 for the other two candidate events to display a change button 409.

The reception unit 231 receives a change of betting destination from the player in response to receiving an input such as a tap operation from the player on the change button 409. In other words, as a second reception step, the reception unit 231 receives a change of designation to a second event included in the candidate events from the player before the execution event is executed. In this manner, the player can change their betting destination to a candidate event that is expected to receive a large number of votes and is likely to be held. This makes it possible to gather more players who are likely to participate before the event is held, and to prevent a decrease in the number of participants in the execution event.

In the second reception step, the reception unit 231 accepts a change in the designation in accordance with the player's consumption of items. Specifically, for example, the reception unit 231 accepts a change in the candidate event to be voted for in accordance with the player's consumption of tickets. When accepting a change in designation, the item consumption conditions become worse than when accepting a designation. The example in Figure 5 shows that three tickets must be consumed to vote for the candidate event "Resurrection of the Ancient Dragon, Red Dragon." On the other hand, in the example in Figure 6, the player must consume four tickets to change their vote to the same event, which is a greater number of tickets than when voting initially. This increases the importance of the choice of which candidate event to vote for first, improving the strategic nature of the game.

<Event details screen>
FIG. 7 is an image diagram showing an example of an event details screen 410 visible to the player. The event details screen 410 may include, for example, a candidate event name 411 and a description display area 412. The candidate event name 411 displays the name of the event corresponding to the candidate event banner 402. The description display area 412 displays detailed information about the candidate event, such as the conditions for participating in the event, rules, a description of the boss (a special enemy character), an introduction to recommended player characters who can advance the event advantageously, an introduction to a gacha held simultaneously with the event, and an explanation of rewards that can be obtained by participating in the event. If the event has already been scheduled, the event period is also displayed. If the event has been held in the past, the rankings from when the event was held are also displayed. As shown in the description display area 412 in FIG. 7 , the condition for participating in the running event is to complete voting for the event within the voting period.

The event details screen 410 displays that the reward information and difficulty information for the executed event will be adjusted to favor the use of specific player characters. The example in Figure 7 shows that for the candidate event "Resurrected Ancient Dragon Red Dragon," player characters "Ice Devil" and "Snow Fairy" will be favored in terms of the amount of damage they inflict on enemy characters. Player characters that are set to give an advantage in game progression during an event are called event special effect characters.

In other words, the adjustment unit 233 adjusts the reward information or difficulty level information for the executed event based on user information and event information for past events. User information is information that includes information about the game media owned by the player. Specifically, for example, user information includes the player's registration information, level, game play history, login frequency, remaining stamina, or information about the game media owned, in-game currency, or defeat points (described below).

Event-specific characters are, for example, old player characters that appeared in past events. Another example is using player characters available in a limited gacha held simultaneously with a current event or an ongoing event, giving players an advantage in the other event.

By adjusting the difficulty information of the running event so that event-specific characters are favored, the game's strategic element can be enhanced, making it more interesting. Furthermore, by adjusting the player characters available in either the current event or the running event so that they have the event-specific effects of the other event, a synergistic effect can be created between the current event and the running event, motivating players to participate in both events.

The example in Figure 7 also shows that if a player is ranked within the top 200, they can obtain an event reward such as a "5-star red dragon egg." Here, "stars" are indicators of the player character's ability value. By showing players that they can obtain luxurious rewards by ranking highly, it is possible to increase the player's motivation to actively participate in the event.

<Solicitation screen>
8 is an image diagram showing an example of the solicitation screen 420 visually recognized by the player. For example, in response to the reception unit 231 receiving an input from the player, such as a tap operation on the solicitation screen display button 408, the display control unit 234 displays the solicitation screen 420 on the display 4 a.

The invitation screen 420 includes multiple player name display areas 421. The player name display areas 421 display, for example, the usernames of other players, a status display 424, an invitation button 423, etc. In the example of Figure 8, the invitation screen 420 displays the names of players B, C, and D, who are the player's friends, as well as players E, F, and G, who belong to the same guild as the player.

The status display 424 shows information about other players, such as whether other players have cleared the event and whether they have the tickets necessary to vote, as shown in Figure 8. In the example of Figure 8, it is displayed that player B has not yet cleared the candidate event "Basilisk, the Messenger from the Underworld," and that he has the tickets necessary to vote.

The notification unit 235 sends a voting request in response to the reception unit 231 receiving an input from the player, such as a tap operation, on the invitation button 423. In response to the transmission of the voting request, the display control unit 234 changes the display of the invitation button 423 to the invitation completed display 422. The example in Figure 8 shows that voting requests have already been sent to player B and player C.

Then, in response to the transmission of the voting request, the notification unit 235 notifies other players associated with the player, such as friends or guild members, that a request has been made by the player. In this manner, the player can inform their friends or members of the same guild about the candidate event for which they voted, and can invite their friends to participate in that event. This allows players to share the experience of playing the same event with their friends, making the game more enjoyable.

<Request display screen>
In the first reception step, the reception unit 231 receives a designation for a first event in response to the consumption of an item by another player. Specifically, for example, the reception unit 231 receives a vote for one of a plurality of candidate events in response to the consumption of a ticket by another player.

On the other hand, other players can also vote for candidate events for which they have been asked to vote, in response to a voting request from the player. Figure 9 is an image diagram showing an example of a request display screen 500 visible to other players. For example, the display control unit 234 causes the request display screen 500 to be displayed on the display 4a of the game device 3 of the other player. Specifically, the request display screen 500 is displayed in response to the reception unit 231 receiving an input such as a tap operation from the player in response to a display indicating that a notification has been received.

In the example of Figure 9, the request display screen 500 includes a candidate event banner 501, a voting button 502, a vote count display 504, and a required number display 505. Explanation of these is omitted as they are similar to the candidate event banner 402, voting button 404, vote count display 405, and required number display 406 on the voting screen 400 shown in Figure 5.

When accepting a designation based on a voting request, ticket consumption conditions are more favorable than when accepting a designation not based on a voting request. For example, by voting using the voting button 502 on the request display screen 500, fewer tickets will be consumed than with a normal vote. In the example of Figure 9, the display control unit 234 displays preferential treatment in terms of ticket consumption using the preferential treatment display 503 on the voting button 502. This creates an incentive for friends and guild members to vote for the same candidate events, preventing the event from losing momentum.

<Event list screen>
10 is an image diagram showing an example of an event list screen 430 visible to a player. For example, in activity A014, the event list screen 430 is displayed on the display 4a of the player's game device 3. FIG. 10 shows an example of a screen in which the player has voted for "Resurrected Ancient Dragon, Red Dragon" and this event has been executed for the player. For example, by accepting an input such as a tap operation on the event banner 431 by the player, the player's participation in the executed event is accepted.

In the example of Figure 10, the remaining time display 432 shows the time remaining until the end of the execution event period. Note that in the example of Figure 10, the remaining time display 432 is not displayed for the "Character Acquisition Quest," indicating that it is a permanent event that is held on a regular basis.

Also, for example, the event banner 431 includes an event type display 433 that indicates the type of event. In the example of Figure 10, a raid event, which is an ongoing event, and story events, team battle events, and permanent events, which are current events, are being held. In this way, past events that are replayed are selected to be of a different type from the current events. This helps to eliminate bias in the types of events and prevent players from becoming bored.

<Quest Results Screen>
11 is an image diagram showing an example of a quest result screen 440 visually recognized by the player. For example, in step S106, the display control unit 234 displays the quest result screen 440 on the display 4a of the player's game device 3. The example of FIG. 11 shows the quest result screen 440 when the raid boss is successfully defeated.

The quest result screen 440 includes an enemy character name 441, a result display area 442, and a ranking display button 443. The enemy character name 441 displays the name of the enemy character that was defeated. In the example of Figure 11, it displays that the raid boss "Red Dragon (Level 2)" was successfully defeated.

The condition for a successful defeat is that the total damage dealt to the raid boss exceeds its stamina. Typically, a raid boss's stamina is set to a value far greater than the stamina of a normal enemy character in a normal quest, which a single user defeats in a single battle. Even if the defeat fails, the raid boss's stamina is carried over to other users when they battle after the battle ends, so multiple players can repeatedly challenge the same raid boss in raid battles in the hopes of defeating it. In response to the determination of successful defeat by the identification determination unit 236, a reward is awarded to the player who fought against the defeated raid boss.

The result display area 442 displays information about the results of the quest, such as the total damage dealt to the raid boss, any bonuses or penalties awarded by the player character used, the defeat points and rewards earned, the success or failure of the quest, and the cumulative number of defeat points earned to date. For example, as a reward for successfully defeating a raid boss, each player is awarded defeat points based on the total amount of damage dealt to the raid boss, i.e., their contribution in the raid battle. In the example of Figure 11, the display shows that the total damage dealt by the player is 8,000, which is equivalent to 6,000 defeat points. The display also shows that the cumulative defeat points earned by the player up to this point is 10,000 points.

Bonuses or penalties are added to subjugation points depending on factors such as the use of specific player characters. The example in Figure 11 shows that subjugation points have been adjusted because the player used the event-specific character "Ice Devil" and the new character "Siren." Specifically, a coefficient of 1.5 applies to damage dealt by "Ice Devil," and a coefficient of 0.5 applies to damage dealt by "Siren." As a result, the total damage of 8000 is multiplied by the coefficients above to calculate subjugation points of 6000, which are awarded to the player.

In this way, when a player plays a quest in an event using a specific player character, the difficulty information for the event may be adjusted so that the amount of damage done to enemy characters is reduced. In games that have been released for some time, newer player characters are often set with higher abilities than older player characters that appeared in the past. For example, by favoring newer player characters, it is possible to adapt them to the difficulty of revived past events and adjust the game balance.

<Ranking screen>
There are no particular restrictions on the rankings created after defeating a raid boss as long as they are related to the raid battle, but they may be rankings based on, for example, the cumulative number of defeat points, the cumulative amount of damage inflicted on the raid boss, the number of raid bosses defeated, etc. Then, after the event ends, players are given rewards based on their final ranking at the end of the execution event.

Figure 12 is an image diagram showing an example of a ranking screen 450 that is visible to the player. For example, in step S108, the display control unit 234 displays the ranking screen 450. Specifically, in response to the reception unit 231 receiving input from the player, such as a tap operation, on the ranking display button 443, the display control unit 234 displays the ranking screen 450 on the display 4a.

In a second display step, the display control unit 234 displays rewards awarded to players who participated in the game based on the game results as a current ranking 451 and a past ranking 453. Specifically, for example, the ranking screen 450 includes a current ranking 451 and a past ranking 453. The current ranking 451 and the past ranking 453 are rankings of the cumulative defeat points earned by players during the event period. The current ranking 451 indicates the ranking as of the executed event, and the past ranking 453 indicates the ranking corresponding to the time when the event was held as a past event. The ranking display 452 is displayed in a manner that highlights the player's ranking so that it is easy for the player to see.

In the example of Figure 12, a player with the username Player A has accumulated 10,000 points, placing him or her in 100th place at the moment. On the other hand, if Player A had earned the same number of points during a past event, he or she would have been in 55th place. For example, the current ranking 451 and past ranking 453 are displayed with the same elapsed time since the start of the event. In the example of Figure 12, both rankings are shown as of the third day after the start of the event.

Displaying the current ranking 451 allows the player to understand their ranking among other players, motivating them to aim for a higher ranking. Also, displaying the past ranking 453 allows even players who did not participate in past events to know their ranking at the time of the past event, making it possible to further enjoy the revived event.

[others]
The information processing system 1 according to the above-described embodiment may be configured as follows.

In the above embodiment, an example was described in which each player could cast one vote, but it is also possible for each player to cast two or more votes. In that case, a player may cast two or more votes for the same candidate event, or may vote for two or more candidate events.

In the above embodiment, an example was described in which a player invites other players, but the invitation may be performed at the player's discretion. In that case, activity A004 and activity A006 may be omitted.

In the above embodiment, we have described a situation in which other players are given preferential treatment in terms of item consumption when they vote in response to a player's request, but the degree of preferential treatment may also be adjusted depending on the relationship between the player and the other player. Specifically, for example, responding to a guild member's request may be given preferential treatment in terms of item consumption required for voting compared to responding to a friend's request. Furthermore, responding to a request from a close friend, such as one with whom you have played together many times in multiplayer games, may be given preferential treatment in terms of item consumption required for voting compared to responding to a regular friend's request.

In the above embodiment, the voting screen 400 displays information indicating that a candidate event has been decided to be held, but the notification unit 235 may also notify the player of information including, for example, that an event has been decided to be held, the event schedule, etc.

In the above embodiment, we have described a mode in which the reward information and difficulty level information of a revived execution event are adjusted, but of course the execution event may be held without these being adjusted. Also, it is possible for either the reward information or the difficulty level information to be adjusted.

In the above embodiment, we have described a mode in which the difficulty information of the execution event is adjusted based on the difficulty information of the current event or a past event. Preferably, the current event is an event that is held close to the execution event. In this case, the adjustment unit 233 adjusts the reward information and difficulty information of the execution event so that there is no large difference in rewards or difficulty between events held close to each other. This adjusts the game balance between the current event that is held close to the execution event and the revived execution event, allowing players to enjoy both events. In another mode, the adjustment unit 233 may execute preferential treatment, such as increasing the rewards or lowering the difficulty of the current event, if the player participates in the execution event. This can add benefits to participating in the revived execution event even for players who have already cleared the past event.

In the above embodiment, only players who voted for the candidate event were described as being able to participate in the running event, but players who did not vote may also be able to participate. In this case, players who did not vote may be able to participate in the running event by consuming in-game currency or items. Furthermore, participating in the running event without voting may require consuming more in-game currency or items than if they were to vote.

In the above embodiment, the quest (e.g., normal battle or raid battle) is a turn-based fighting game, but this is not limiting. For example, the quest may be an action game in which a player character controlled by the player fights enemy characters in a virtual space, or a shooting game (e.g., an FPS (First Person Shooting Game), a TPS (Third Person Shooting Game), etc.). As another example, the quest may be a quiz game in which the player fights by answering questions posed by enemy characters, or a strategy simulation game in which the player fights enemy troops.

In the above embodiment, a description was given of a mode in which the ranking results are displayed when the raid boss is successfully defeated, but the ranking may also be displayed when the raid boss is unsuccessful. Furthermore, the display control unit 234 may display the ranking in response to input from the player, for example, from the home screen or the top page of an event.

In this embodiment, the game control unit 230, reception unit 231, execution unit 232, adjustment unit 233, display control unit 234, notification unit 235, and specific determination unit 236 are described as functional units realized by the control unit 23 of the information processing device 2, but at least some of these may be implemented as functional units realized by the control unit 33 of the game device 3.

Aspects of the above-described embodiments may be an information processing method. The information processing method includes the components of the information processing system 1. Aspects of the above-described embodiments may also be a program. The program causes a computer to execute the steps of the information processing system 1.

Furthermore, it may be provided in the following aspects.
In the information processing system, the candidate events include past events that have been held in the past, where the past events are events that were executed without accepting the designation and have already ended, and in the execution step, the executed event is executed based on event information of the past events, where the event information is information regarding the elements that make up the event.
In the information processing system, further, in the adjustment step, reward information or difficulty information of the executing event is adjusted based on the event information of the current event or the past event, wherein the current event is an event that is executed without accepting the designation and that has not yet ended, the reward information is event information regarding rewards to be granted to users who participate in the event, and the difficulty information is event information regarding the difficulty of the event.
In the information processing system, further, in the adjustment step, reward information or difficulty information of the executed event is adjusted based on user information and the event information of the past event, wherein the user information includes information regarding the game medium owned by the user, the reward information is event information regarding rewards to be granted to users who participate in the event, and the difficulty information is event information regarding the difficulty of the event.
In the information processing system, the first display step further displays the plurality of candidate events together with information indicating that the reward information or the difficulty level information will be adjusted.
In the information processing system, further, in a second display step, rewards given to specific users who participated in the game based on the results of the game are displayed as current rankings and past rankings, wherein the current rankings indicate the rankings as the executed event, and the past rankings indicate the rankings corresponding to the time when the past event was held.
In the game program, the game control step controls the progress of a fighting game included in the execution event, and the fighting game is a game in which multiple player characters, each operated by multiple specific users participating in the execution event, fight against a common enemy character.
In the information processing system, the notification step further includes notifying other users associated with the specific user that a request has been made by the specific user, wherein the request includes content requesting the other users to make the designation for the first event.
In the information processing system, in the first reception step, the designation for the first event is accepted in accordance with the consumption of an item by the other user, and when the designation based on the request is accepted, the conditions for the consumption amount of the item are more favorable than when the designation not based on the request is accepted.
In the information processing system, in the first receiving step, the designation is received in response to consumption of an item by the specific user, and if the designation for the first event is received after the execution condition of the first event has been met, the condition for the amount of item consumed becomes worse than if the designation is received before the execution condition has been met.
In the information processing system, further, in a second receiving step, a change of the designation to a second event included in the candidate events is received from the specific user before the execution event is executed.
In the information processing system, the second reception step receives a change to the designation in accordance with the consumption of an item by the specific user, and if the change to the designation is received, the conditions for the consumption amount of the item become worse than if the designation were received.
A program that causes a computer to execute each of the steps described above.
Of course, this is not the case.

Finally, while various embodiments of the present disclosure have been described, these are presented as examples and are not intended to limit the scope of the disclosure. The novel embodiments may be embodied in a variety of other forms, and various omissions, substitutions, and modifications may be made without departing from the spirit of the disclosure. Such embodiments and their variations are intended to fall within the scope and spirit of the disclosure, as well as the disclosure and its equivalents as set forth in the claims.

1: Information processing system 11: Communication network 2: Information processing device 20: Communication bus 21: Communication unit 22: Memory unit 23: Control unit 230: Game control unit 231: Reception unit 232: Execution unit 233: Adjustment unit 234: Display control unit 235: Notification unit 236: Identification determination unit 3: Game device 30: Communication bus 31: Communication unit 32: Memory unit 33: Control unit 34a: Graphic processing unit 34b: Audio processing unit 34c: Operation unit 4a: Display 4b: Speaker 4c: Input device 400: Voting screen 401: Voting period display 402: Candidate event banner 403: Adjustment display 404: Voting button 405: Number of votes display 406: Number of required votes display 407: Event decision display 408: Solicitation screen display button 409: Change button 410 : Event details screen 411 : Candidate event name 412 : Explanation display area 420 : Solicitation screen 421 : Player name display area 422 : Solicited display 423 : Solicit button 424 : Status display 430 : Event list screen 431 : Event banner 432 : Period display 433 : Event type display 440 : Quest result screen 441 : Enemy character name 442 : Result display area 443 : Ranking display button 450 : Ranking screen 451 : Current ranking 452 : Ranking display 453 : Past ranking 500 : Request display screen 501 : Candidate event banner 502 : Voting button 503 : Preferential treatment display 504 : Number of votes displayed 505 : Number required displayed

Claims (12)

An information processing system,
A control unit is provided,
The control unit is configured to perform the following steps:
In the game control step, the progress of the game including the events to be held is controlled.
In the first receiving step, a designation of at least one of a plurality of candidate events that are candidates for the event is received from each of a plurality of users in the game, wherein the candidate events are set by an administrator who manages progress of the game;
In the execution step, if the execution conditions of a first event, which is at least one of the plurality of candidate events, are satisfied by the designation, the first event is executed as an execution event for a specific user of the plurality of users, wherein the specific user is the user who designated the first event among the candidate events in the first reception step. 2. The information processing system according to claim 1,
The candidate events include past events that have been held in the past, where the past events are events that were carried out without receiving the designation and have already ended;
In the execution step, the execution event is executed based on event information of the past event, where the event information is information relating to elements that constitute the event. An information processing system,
A control unit is provided,
The control unit is configured to perform the following steps:
In the game control step, the progress of the game including the events to be held is controlled.
In the first receiving step, a designation of at least one of a plurality of candidate events that are candidates for the event is received from each of a plurality of users in the game;
in the execution step, when an execution condition of a first event, which is at least one of the plurality of candidate events, is satisfied by the designation, the first event is executed as an execution event for a specific user of the plurality of users, wherein the specific user is a user who designated the first event among the candidate events in the first reception step;
The candidate events include past events that have been held in the past, where the past events are events that were carried out without receiving the designation and have already ended;
the executing step executes the execution event based on event information of the past event, wherein the event information is information relating to elements that constitute the event;
in the game control step, progress of a fighting game included in the execution event is controlled, and the fighting game is a game in which a plurality of player characters, each operated by a plurality of specific users participating in the execution event, fight against a common enemy character;
in the game control step, reward information or difficulty level information of the execution event is set based on user information and the event information of the past event, wherein the user information includes information about a game medium owned by the user who plays the game ;
The reward information is event information regarding rewards to be given to users who participate in the event, and the difficulty level information is event information regarding the difficulty level of the event. An information processing system,
A control unit is provided,
The control unit is configured to perform the following steps:
In the game control step, the progress of the game including the events to be held is controlled.
In the first receiving step, a designation of at least one of a plurality of candidate events that are candidates for the event is received from each of a plurality of users in the game;
in the execution step, when an execution condition of a first event, which is at least one of the plurality of candidate events, is satisfied by the designation, the first event is executed as an execution event for a specific user of the plurality of users, wherein the specific user is a user who designated the first event among the candidate events in the first reception step;
The candidate events include past events that have been held in the past, where the past events are events that were carried out without receiving the designation and have already ended;
the executing step executes the execution event based on event information of the past event, wherein the event information is information relating to elements that constitute the event;
Furthermore, in the second display step, rewards given to specific users who participated in the game based on the results of the game are displayed as current rankings and past rankings, where the current rankings indicate the rankings as the executed event, and the past rankings indicate the rankings corresponding to the time when the past event was held. An information processing system,
A control unit is provided,
The control unit is configured to perform the following steps:
In the game control step, the progress of the game including the events to be held is controlled.
In the first receiving step, a designation of at least one of a plurality of candidate events that are candidates for the event is received from each of a plurality of users in the game;
in the execution step, when an execution condition of a first event, which is at least one of the plurality of candidate events, is satisfied by the designation, the first event is executed as an execution event for a specific user of the plurality of users, wherein the specific user is a user who designated the first event among the candidate events in the first reception step;
In the notification step, other users associated with the specific user are notified that there has been a request from the specific user, and the request includes content requesting the other users to make the designation for the first event. An information processing system,
A control unit is provided,
The control unit is configured to perform the following steps:
In the game control step, the progress of the game including the events to be held is controlled.
In the first receiving step, a designation of at least one of a plurality of candidate events that are candidates for the event is received from each of a plurality of users in the game;
in the execution step, when an execution condition of a first event, which is at least one of the plurality of candidate events, is satisfied by the designation, the first event is executed as an execution event for a specific user of the plurality of users, wherein the specific user is a user who designated the first event among the candidate events in the first reception step;
In the first receiving step, the designation is received in response to consumption of an item by the specific user, and if the designation for the first event is received after the execution condition for the first event has been met, the condition for the amount of item consumed becomes worse than if the designation is received before the execution condition is met. An information processing system,
A control unit is provided,
The control unit is configured to perform the following steps:
In the game control step, the progress of the game including the events to be held is controlled.
In the first receiving step, a designation of at least one of a plurality of candidate events that are candidates for the event is received from each of a plurality of users in the game;
in the execution step, when an execution condition of a first event, which is at least one of the plurality of candidate events, is satisfied by the designation, the first event is executed as an execution event for a specific user of the plurality of users, wherein the specific user is a user who designated the first event among the candidate events in the first reception step;
Furthermore, in the second accepting step, a change of the designation to a second event included in the candidate events is accepted from the specific user before the execution event is executed;
In the second receiving step, a change in the designation is accepted in accordance with the consumption of the item by the specific user, and if the change in the designation is accepted here, the conditions for the consumption amount of the item become worse than when the designation is accepted. In the information processing system according to any one of claims 2 to 4 ,
the game control step controls progress of a fighting game included in the execution event, wherein the fighting game is a game in which a plurality of player characters, each operated by a plurality of specific users participating in the execution event, fight against a common enemy character;
In the game control step, reward information or difficulty level information of the execution event is set based on the event information of a current event or the past event, wherein the current event is an event that is executed without receiving the designation and has not yet ended;
The reward information is event information regarding rewards to be given to users who participate in the event, and the difficulty level information is event information regarding the difficulty level of the event. In the information processing system according to claim 3 or claim 8 ,
Furthermore, in the first display step, the candidate events are displayed together with information indicating that the reward information or the difficulty level information is set for a plurality of the candidate events. In the game program according to any one of claims 1 , 2, and 4 to 7 ,
The game control step controls the progress of a fighting game included in the execution event, wherein the fighting game is a game in which multiple player characters, each operated by multiple specific users participating in the execution event, fight against a common enemy character. 6. The information processing system according to claim 5 ,
In the first receiving step, the designation for the first event is accepted in accordance with the consumption of an item by the other user, and when the designation based on the request is accepted, the conditions for the consumption amount of the item are more favorable than when the designation not based on the request is accepted. A program,
A method for causing a computer to execute each step according to any one of claims 1 to 11 .