Information processing program, information processing method and information processing system

Abstract

To improve a game property.SOLUTION: An information processing program causes a computer to perform processing of: activating a first utility on the basis of a first operation input by a first player; validating predetermined standby information on the basis of the input of the first operation or the activation of the first utility; determining a special utility as an activateable utility on the basis of a predetermined operation input by a second player when the standby information is validated; invalidating the standby information on the basis of the input of the predetermined operation or the determination of the special utility; allowing the second player to select one of a plurality of operations including at least an activation operation for activating the determined special utility and a discard operation for discarding the determined special utility; activating the special utility on the basis of the input of an activation operation by the second player; and discarding the special utility on the basis of the input of the discard operation by the second player.SELECTED DRAWING: Figure 10

Description

[Technical field]

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

[0002] For example, Patent Document 1 discloses a system that realizes a multiplayer game in which a plurality of players cooperate to fight against an enemy character. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2023-24016 A Summary of the Invention [Problem to be solved by the invention]

[0004] In the above multiplayer game, multiple players each progress through the game. Each player can activate a special utility in addition to a normal attack. In this case, the utility activated by another player may also be applied to the player himself / herself. However, whether or not the utility activated by another player is applied to the player himself / herself is left to chance, which reduces the playability of the game.

[0005] An object of the present invention is to provide an information processing program, an information processing method, and an information processing system that can improve game playability. [Means for solving the problem]

[0006] In order to solve the above problem, an information processing program includes: A process for activating a first utility based on a first operation input by a first player in a multiplayer game in which a plurality of players can participate; A process of validating predetermined standby information based on the input of the first operation or the activation of the first utility; a process of determining, when the standby information is enabled, a special utility obtained by adding a predetermined utility to a second utility that has been previously provided or a special utility that has been changed from the second utility, as an exercisable utility, based on a predetermined operation input by a second player; a process of invalidating the standby information based on the input of the predetermined operation or the determination of the special utility; a process of allowing the second player to select one of a plurality of operations including at least an activation operation for activating the determined special utility and a discard operation for discarding the determined special utility; a process of activating the special utility based on the input of the activation operation by the second player; a process of discarding the special utility based on an input of the discard operation by the second player; The computer is made to carry out the above steps.

[0007] The information processing program The plurality of operations selectable by the second player may include an operation for progressing the multiplayer game while suspending activation of the special effect.

[0008] The predetermined operation is The operation may be an operation of selecting the second utility to be activated in the multiplayer game from among a plurality of the second utilities.

[0009] The information processing program a process of displaying a first image corresponding to the first effect and a second image corresponding to the second effect based on activation of the special effect; may further be performed by a computer.

[0010] The process of validating the waiting information includes: a process of linking the waiting information to the multiplayer game, The process of invalidating the waiting information includes: A process of discarding the waiting information associated with the multiplayer game, The process of determining the special utility includes: a process of linking the waiting information or information corresponding to the waiting information to the second player; The process of activating the special utility and the process of discarding the special utility include: The method may include a process of discarding the waiting information linked to the second player or information corresponding to the waiting information.

[0011] In order to solve the above problem, an information processing method includes: One or more computers A process for activating a first utility based on a first operation input by a first player in a multiplayer game in which a plurality of players can participate; A process of validating predetermined standby information based on the input of the first operation or the activation of the first utility; a process of determining, when the standby information is enabled, a special utility obtained by adding a predetermined utility to a second utility that has been previously provided or a special utility that has been changed from the second utility, as an exercisable utility, based on a predetermined operation input by a second player; a process of invalidating the standby information based on the input of the predetermined operation or the determination of the special utility; a process of allowing the second player to select one of a plurality of operations including at least an activation operation for activating the determined special utility and a discard operation for discarding the determined special utility; a process of activating the special utility based on the input of the activation operation by the second player; a process of discarding the special utility based on an input of the discard operation by the second player; Carry out the following.

[0012] In order to solve the above problem, an information processing system includes: One or more computers; The computer, A process for activating a first utility based on a first operation input by a first player in a multiplayer game in which a plurality of players can participate; A process of validating predetermined standby information based on the input of the first operation or the activation of the first utility; a process of determining, when the standby information is enabled, a special utility obtained by adding a predetermined utility to a second utility that has been previously provided or a special utility that has been changed from the second utility, as an exercisable utility, based on a predetermined operation input by a second player; a process of invalidating the standby information based on the input of the predetermined operation or the determination of the special utility; a process of allowing the second player to select one of a plurality of operations including at least an activation operation for activating the determined special utility and a discard operation for discarding the determined special utility; a process of activating the special utility based on the input of the activation operation by the second player; a process of discarding the special utility based on an input of the discard operation by the second player; Carry out the following. Effect of the Invention

[0013] According to the present invention, it is possible to improve the entertainment value of the game. [Brief description of the drawings]

[0014] [Figure 1] FIG. 1 is an explanatory diagram showing a schematic configuration of an information processing system. [Diagram 2] Fig. 2A is a diagram illustrating the hardware configuration of a player terminal, and Fig. 2B is a diagram illustrating the hardware configuration of a server. [Diagram 3] Fig. 3A is a diagram showing an example of a My Page screen, and Fig. 3B is a diagram showing an example of a quest list screen. [Figure 4]Fig. 4A is a diagram showing an example of a rescue request list screen, Fig. 4B is a diagram showing an example of a multi-battle list screen, and Fig. 4C is a diagram showing an example of a multi-battle selection screen. [Diagram 5] Fig. 5A shows an example of a My Page screen when a rescue request is received from another player. Fig. 5B shows an example of a quest list screen when a rescue request is received from another player. Fig. 5C shows an example of a rescue request list screen when a rescue request is received from another player. [Figure 6] Fig. 6A is a diagram showing an example of a rescue request screen, Fig. 6B is a diagram showing an example of a rescue request completion screen, Fig. 6C is a diagram showing an example of a battle screen, and Fig. 6D is a diagram showing an example of an action screen. [Figure 7] FIG. 7A is a diagram illustrating an example of an ability selection frame. FIG. 7B is a diagram illustrating an example of an animation when an ability is used. FIG. 7C is a diagram illustrating a state when an ability action has ended. FIG. 7D is a diagram illustrating an example of an animation when a reserved ability action is started. [Figure 8] FIG. 8 is a diagram illustrating an example of a summoning item. [Figure 9] 9A and 9B are diagrams illustrating an example of a summoning item selection frame when fusion is not possible, and FIG. 9B is a diagram illustrating an example of a summoning information dialog box when fusion is not possible. [Figure 10] Fig. 10A is a diagram illustrating an example of a summon item selection frame when fusion is possible, and Fig. 10B is a diagram illustrating an example of a summon information dialogue when fusion is possible. [Figure 11] Fig. 11A is a first diagram illustrating an example of a presentation when a summoning action is executed. Fig. 11B is a second diagram illustrating an example of a presentation when a summoning action is executed. Fig. 11C is a third diagram illustrating an example of a presentation when a summoning action is executed. [Figure 12] FIG. 12 is a first diagram showing operation inputs by a plurality of players in time series. [Figure 13] FIG. 13 is a second diagram showing operation inputs by a plurality of players in time series. [Figure 14] FIG. 14 is a functional block diagram of the player terminal. [Figure 15] FIG. 15 is a functional block diagram of the server. [Figure 16] FIG. 16 is a sequence diagram illustrating the processing of the player terminal and the server. [Figure 17] FIG. 17 is a first flowchart illustrating the server-side battle execution process. [Figure 18] FIG. 18 is a second flowchart illustrating the server-side battle execution process. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] An embodiment of the present invention will be described in detail below with reference to the accompanying drawings. The numerical values ​​and the like shown in the embodiment are merely examples for easy understanding and do not limit the present invention unless otherwise specified. In this specification and drawings, elements having substantially the same functions and configurations are given the same reference numerals to avoid duplicated explanations, and elements not directly related to the present invention are not shown.

[0016] (Overall configuration of information processing system S) 1 is an explanatory diagram showing a schematic configuration of an information processing system S. The information processing system S is a so-called client-server system including a player terminal 1, a server 100, and a communication network N having a communication base station Na. The information processing program is a variety of programs executed in the information processing system S.

[0017] The player terminal 1 can establish communication with the server 100 via the communication network N. The player terminal 1 broadly includes electronic devices capable of wireless or wired communication connection with the server 100. Examples of the player terminal 1 include smartphones, mobile phones, tablet devices, personal computers, game devices, and the like. In this embodiment, a case where a smartphone is used as the player terminal 1 will be described.

[0018] The server 100 is communicatively connected to a plurality of player terminals 1. The server 100 manages the game and accumulates various information (player information) for each player playing the game. The server 100 also updates the accumulated information and controls the progress of the game based on operations input from the player terminals 1.

[0019] The communication base station Na is connected to the communication network N. The communication base station Na wirelessly transmits and receives information to and from the player terminal 1. The server 100 is connected to the communication network N. The communication network N is composed of a mobile phone network, an Internet network, a LAN (Local Area Network), a dedicated line, etc. The communication network N realizes a wireless or wired communication connection between the player terminal 1 and the server 100.

[0020] In the information processing system S of this embodiment, the player terminal 1 and the server 100 function as a game device G. The player terminal 1 and the server 100 are assigned roles for controlling the progress of the game, and the game can progress through cooperation between the player terminal 1 and the server 100.

[0021] A game realized by the information processing system S is, for example, a browser game. In a browser game, the player terminal 1 transmits information based on an input operation of the player to the server 100. The server 100 controls the progress of the game based on the received information, and causes the player terminal 1 to receive screen information according to the progress of the game. The player terminal 1 displays a game screen on a display based on the received screen information. Note that the game realized by the information processing system S is not limited to a browser game, and may be an application game in which at least a part of the progress control of the game is executed by the player terminal 1.

[0022] (Hardware configuration of the player terminal 1 and the server 100) Fig. 2A is a diagram for explaining the hardware configuration of the player terminal 1. Fig. 2B is a diagram for explaining the hardware configuration of the server 100. As shown in Fig. 2A, the player terminal 1 includes one or more CPUs (Central Processing Units) 10, a storage device 12, a bus 14, an input / output interface 16, a storage unit 18, a communication unit 20, an input unit 22, and an output unit 24.

[0023] As shown in FIG. 2B, the server 100 includes one or more CPUs 110, a storage device 112, a bus 114, an input / output interface 116, a storage unit 118, a communication unit 120, an input unit 122, and an output unit 124.

[0024] The configurations and functions of the CPU 110, storage device 112, bus 114, input / output interface 116, storage unit 118, communication unit 120, input unit 122, and output unit 124 of the server 100 are substantially the same as those of the CPU 10, storage device 12, bus 14, input / output interface 16, storage unit 18, communication unit 20, input unit 22, and output unit 24 of the player terminal 1. Therefore, in the following, the hardware configuration of the player terminal 1 will be described, and a description of the server 100 will be omitted.

[0025] The CPU 10 runs a program stored in a storage device 12 to control the progress of the game. The storage device 12 is composed of a ROM (Read Only Memory) or a RAM (Random Access Memory), and stores programs and various data required for controlling the progress of the game. The storage device 12 is connected to the CPU 10 via a bus 14.

[0026] An input / output interface 16 is connected to the bus 14. To the input / output interface 16, a storage unit 18, a communication unit 20, an input unit 22, and an output unit 24 are connected.

[0027] The storage unit 18 is configured with a ROM or RAM, and stores various programs and data. In the player terminal 1, the programs or data stored in the storage unit 18 are loaded by the CPU 10 into the storage device 12 (RAM).

[0028] The communication unit 20 is wirelessly connected to the communication base station Na for communication, and transmits and receives information such as various data and programs to and from the server 100 via the communication network N. In the player terminal 1, the program or data received from the server 100 is stored in the storage device 12 or the storage unit 18.

[0029] The input unit 22 is composed of, for example, a touch panel, a button, a keyboard, a mouse, a cross key, an analog controller, etc., into which the player's operation is input (which accepts the operation). The input unit 22 may also be a dedicated controller provided in the player terminal 1 or connected (externally) to the player terminal 1. Furthermore, the input unit 22 may be composed of an acceleration sensor that detects the inclination or movement of the player terminal 1, or a microphone that detects the voice of the player. In other words, the input unit 22 broadly includes devices that can input the player's intention in an identifiable manner.

[0030] The output unit 24 includes a display device and a speaker. The output unit 24 may be a device connected (externally attached) to the player terminal 1. In this embodiment, the player terminal 1 includes a display 26 as the output unit 24, and a touch panel superimposed on the display 26 as the input unit 22.

[0031] (Game Contents) Next, the content of the game provided by the information processing system S (game device G) of this embodiment will be described using an example. The game of this embodiment is a so-called online RPG (Role-Playing Game), and multiple players can play the game simultaneously in one game world via a communication network N. A main character is given to the player by the operator. In addition to the main character, the player can also acquire multiple sub-characters by lottery or the like and make them his or her allies. Hereinafter, the main character and the sub-characters that have been made his or her allies are called ally characters.

[0032] Various quests are prepared for the game. The game progresses as the player accepts quests. A quest involves a battle between an enemy character according to the content of the quest and the player's ally character. The quest is cleared by winning the battle. Note that the number of enemy characters in one battle is not limited to one, and may be multiple. The game content of this embodiment will be described in detail below.

[0033] FIG. 3A is a diagram showing an example of a My Page screen. FIG. 3B is a diagram showing an example of a quest list screen. When the player terminal 1 accesses the server 100 and enters a logged-in state, the game starts. When the game starts, the My Page screen shown in FIG. 3A is displayed on the display 26 of the player terminal 1. The My Page screen is provided with a plurality of operation units such as tabs that can be operated by the player. Note that operation units that can be operated by the player are also provided on various screens other than the My Page screen, which will be described later.

[0034] As shown in Fig. 3A, on the My Page screen, a frame bar 30 is displayed at the bottom of the display 26. The frame bar 30 is also displayed when the screen displayed on the display 26 changes to a screen other than the My Page screen. The frame bar 30 is provided with a My Page tab 30a marked "My Page," a reload tab 30b marked "Reload," and a back tab 30c marked "Back."

[0035] When the My Page tab 30a is operated, the My Page screen is displayed, and it is possible to return to the My Page screen from a screen other than the My Page screen. When the Reload tab 30b is operated, the screen being displayed on the display 26 is reloaded, and the displayed screen is updated. When the Back tab 30c is operated, it is possible to return to the screen that was displayed immediately before the screen being displayed on the display 26.

[0036] As shown in Fig. 3A, a menu tab 31a labeled "Menu" is displayed on the upper right of the My Page screen. When the menu tab 31a is operated, a menu screen (not shown) is displayed. The player can configure various settings related to the game on the menu screen.

[0037] As shown in FIG. 3A, the My Page screen displays a formation tab 32a labeled "Formation," a strengthening tab 32b labeled "Strengthening," a gacha tab 32c labeled "Gacha," and a quest tab 32d labeled "Quest."

[0038] When the formation tab 32a is operated, a formation screen (not shown) is displayed. On the formation screen, a party to be used in a quest battle can be formed. A party is formed with main members who are starting members in a battle, and sub-members who are substitutes. The main members are formed with a total of four characters, the main character and three sub-characters. The sub-members are formed with two sub-characters. In a battle, if any of the main member characters becomes unable to fight, a sub-character will be added to the battle from the sub-members.

[0039] Hereinafter, the main member and the sub-member will be collectively referred to as the member. Furthermore, on the organization screen, the player can equip the members with equipment such as weapons. Furthermore, the player can use items in quests. On the organization screen, it is possible to set items that can be used in quests. That is, on the organization screen, the player can set party information including information about the members and information about the members' equipment. Note that the information that can be set on the organization screen is not limited to this, and can be designed as appropriate.

[0040] When the strengthen tab 32b is operated, a strengthening screen (not shown) is displayed. On the strengthening screen, the player can strengthen the weapon he or she possesses according to a predetermined rule.

[0041] When the gacha tab 32c is operated, a gacha screen (not shown) is displayed. On the gacha screen, a weapon can be acquired by lottery by consuming in-game currency. In addition, when a specific type of weapon is acquired for the first time, a sub-character corresponding to the specific type of weapon can be acquired. The acquired sub-character can be organized into a party.

[0042] As will be described later, one type of quest is a multi-battle quest (hereafter referred to as a multi-battle) as a multiplayer game. One multi-battle is associated (linked) with one content ID. The content ID is identification information provided for each quest, i.e., for each type of multi-battle. The content ID differs for each quest, and further for each class and difficulty level of each quest. Note that, here, different content IDs are linked to the same quests of different difficulty levels (quests with common settings other than difficulty).

[0043] However, a common content ID may be associated with the same quest with different difficulty levels. In a multi-battle, multiple players can cooperate to battle against one enemy character. In other words, a multi-battle is a multi-play game in which multiple players can participate. For example, a first player executes a multi-battle and starts (launches) a new multi-battle. The first player can request help from another player (second player).

[0044] The second player can receive a rescue request from the first player and later join the multi-battle started by the first player. The player who starts a new multi-battle is sometimes called the discoverer, and the player who joins later is sometimes called the rescuer. The number of players who can join together in a multi-battle (discoverer + rescuer) is limited to a certain number (for example, 30 people).

[0045] As shown in FIG. 3A, AP (Active Points) and BP (Battle Points) are displayed near the Quest tab 32d. AP is the points required to execute a quest, and a player consumes AP to execute a quest. For example, AP is consumed when executing a multi-battle as a discoverer. BP is the points required to participate in a multi-battle, and a player can consume BP to participate as a rescuer in a multi-battle started by another player. AP and BP are recovered over time or by consuming a specified item.

[0046] When the quest tab 32d is operated, a quest list screen shown in Fig. 3B is displayed. The quest list screen displays a quest selection tab 33. The quest selection tab 33 displays information related to executable quests.

[0047] Quests include main quests related to the progress of the main story, arbitrarily set free quests, the above-mentioned multi-battles, etc. A quest selection tab 33 is displayed for each executable quest. If there are multiple executable quests, they are displayed side by side at the bottom of the quest list screen. If there are many quests, all of the quests can be displayed by scrolling the quest list screen downwards.

[0048] 3B, a quest selection tab 33a corresponding to a multi-battle is displayed with "Multi Battle" written in the banner. When any quest selection tab 33 is operated, the quest corresponding to the operated quest selection tab 33 is executed. For example, when the quest selection tab 33a corresponding to a multi-battle is operated, a multi-battle is executed as the discoverer.

[0049] 3B, a multi-battle tab 34 labeled "multi-battle" is displayed on the quest list screen. The multi-battle tab 34 is located, for example, above the top quest selection tab 33 on the screen.

[0050] Fig. 4A is a diagram showing an example of a rescue request list screen. Fig. 4B is a diagram showing an example of a multi-battle list screen. Fig. 4C is a diagram showing an example of a multi-battle selection screen. When the multi-battle tab 34 in Fig. 3B is operated, the rescue request list screen shown in Fig. 4A is displayed.

[0051] The rescue request list screen is provided with a new arrivals tab 35a and a rescue search tab 35b. The new arrivals tab 35a and the rescue search tab 35b function as operation units that accept operations by the player. When the new arrivals tab 35a is selected, the rescue request list screen shown in FIG. 4A is displayed. When the rescue search tab 35b is operated while the rescue request list screen is displayed, a rescue search screen, which will be described later, is displayed.

[0052] On the rescue request list screen, a game information display area 35c is provided below a new arrival tab 35a and a rescue search tab 35b. A multi-battle tab 35c1 and an event tab 35c2 are provided above the game information display area 35c.

[0053] In the game information display area 35c, game information is displayed that indicates a multi-battle that another player has started and in which the player can participate. The game information includes various information related to the multi-battle. In the example of FIG. 4A, no game information is displayed in the game information display area 35c, indicating that there is no multi-battle in which the player can participate.

[0054] Multi-battles are broadly divided into normal multi-battles that players can play at any time, and event multi-battles that are only provided during an event period. When the multi-battle tab 35c1 is operated, game information corresponding to the normal multi-battle is displayed in the game information display area 35c. When the event tab 35c2 is operated, game information corresponding to the event multi-battle is displayed in the game information display area 35c. In the game information display area 35c, game information corresponding to the latest multi-battle among the multi-battles in which the player can participate as a rescuer is displayed.

[0055] In addition, on the rescue request list screen, the new arrivals tab 35a is highlighted more than the rescue search tab 35b, so that it is possible to identify that the new arrivals tab 35a is selected. In addition, while the rescue request list screen is being displayed, the currently selected tab is highlighted out of the multi-battle tab 35c1 and the event tab 35c2.

[0056] 4A, an ID input button 35d is provided on the rescue request list screen. When the ID input button 35d is operated, an ID input screen (not shown) is displayed. When any player initiates a multi-battle and then issues a rescue request, a multi-battle ID associated with the initiated multi-battle is acquired. Each player can also participate in a multi-battle by directly inputting a multi-battle ID into the ID input screen.

[0057] Also, as shown in Fig. 4A, a multi-battle list button 35e is displayed on the rescue request list screen. When the multi-battle list button 35e is operated, the multi-battle list screen shown in Fig. 4B is displayed. As shown in Fig. 4B, the multi-battle list screen displays a normal selection tab 36b marked "NORMAL" and a high level selection tab 36c marked "HIGH LEVEL."

[0058] When the normal selection tab 36b is operated, a difficulty level selection tab 36d for multi-battles classified as the normal class is displayed. On the other hand, when the high level selection tab 36c is operated, a difficulty level selection tab 36d for multi-battles classified as the high level class is displayed. In the example of FIG. 4B, the difficulty level selection tab 36d for the normal class is displayed. In the high level class, enemy characters are set stronger than in the normal class. The difficulty level of the difficulty selection tabs 36d is indicated by the number of stars, and multiple tabs are displayed according to difficulty level. The higher the difficulty level, the stronger the enemy characters are set.

[0059] When the difficulty level selection tab 36d is operated, a multi-battle selection screen shown in Fig. 4C is displayed. The multi-battle selection screen is displayed with content corresponding to the difficulty level selected in the operated difficulty level selection tab 36d.

[0060] As shown in FIG. 4C, the multi-battle selection screen displays a multi-battle selection tab 37a. The multi-battle selection tab 37a is displayed for each type of multi-battle. In addition, the multi-battle selection screen displays a multi-battle challenge tab 37b marked "Challenge" for each multi-battle selection tab 37a. When the multi-battle challenge tab 37b is operated, the multi-battle corresponding to the multi-battle challenge tab 37b is executed as the discoverer. In addition, the multi-battle selection screen displays a cancel tab 37c marked "Close." When the cancel tab 37c is operated, the user can return to the multi-battle list screen.

[0061] In addition, on the multi-battle selection screen, information in the multi-battle selection tab 37a of a multi-battle that cannot be executed (not yet released) may be made undisclosed. Also, on the multi-battle selection screen, operations on the multi-battle challenge tab 37b of a multi-battle that cannot be executed (not yet released) may be disabled.

[0062] Fig. 5A shows an example of a My Page screen when a rescue request is received from another player. Fig. 5B shows an example of a quest list screen when a rescue request is received from another player. Fig. 5C shows an example of a rescue request list screen when a rescue request is received from another player.

[0063] As shown in FIG. 5A, when a rescue request is received from another player, a multi-battle rescue reception tab 38 labeled "Multi Battle" is additionally displayed on the My Page screen.

[0064] Also, as shown in FIG. 5B, when there is a request for help from another player, the frame of the multi-battle tab 34 marked "multi-battle" is highlighted on the quest list screen so as to be distinguishable from when there is no request for help.

[0065] When the multi-battle rescue reception tab 38 shown in FIG. 5A is operated, or when the highlighted multi-battle tab 34 shown in FIG. 5B is operated, a rescue request list screen is displayed as shown in FIG. 5C. When there is a rescue request from another player, a multi-battle participation tab 39 is displayed in the game information display area 35c. The multi-battle participation tab 39 displays game information related to the multi-battle. In other words, the rescue request includes game information.

[0066] Here, as game information, an image indicating the type of multi-battle, the class, the difficulty level, the name of the multi-battle, i.e., the quest name, the remaining HP of the enemy character at the time of the rescue request, and the BP required for participation are displayed in the multi-battle participation tab 39. Note that the game information displayed in the multi-battle participation tab 39 is not limited to this. For example, the game information may include information about the player participating in the multi-battle, and information about the ally character or enemy character. Also, for example, the remaining HP of the enemy character may be displayed variably in real time in the multi-battle participation tab 39.

[0067] When the multi-battle participation tab 39 is operated, the player can participate as a rescuer in the multi-battle of another player who has issued a rescue request. Although a detailed explanation is omitted, when the multi-battle participation tab 39 is operated, a party formation screen is displayed. After forming a party on the party formation screen, the player can participate in the multi-battle using the formed party. Next, an example of a case where a multi-battle is executed as the discoverer will be described.

[0068] FIG. 6A is a diagram showing an example of a rescue request screen. FIG. 6B is a diagram showing an example of a rescue request completion screen. FIG. 6C is a diagram showing an example of a battle screen. FIG. 6D is a diagram showing an example of an action screen. When the quest selection tab 33a showing the multi-battle in the quest list screen shown in FIG. 3B is operated, or the multi-battle challenge tab 37b in the multi-battle selection screen shown in FIG. 4C is operated, the battle screen shown in FIG. 6C is displayed. When the battle screen is displayed, it is immediately switched to the rescue request screen shown in FIG. 6A. In the rescue request screen, the player can set the range of players who will issue a rescue request.

[0069] 6A, the rescue request screen displays a general selection checkbox 50a marked "Everyone," a friend selection checkbox 50b marked "Friends," and a guild selection checkbox 50c marked "Guild." The rescue request screen also displays a rescue request sending tab 50d marked "Rescue request" and a cancel tab 50e marked "Cancel."

[0070] A friend is a player who has registered a certain number of friends with the player among other players in the game. A player can register up to a certain number of friends that correspond to his / her rank. A player's rank can be increased by clearing quests. The certain number of people that can be registered as friends increases as the rank increases. A guild is a group made up of multiple players in the game. By joining a guild, a player can cooperate with other players in the guild to challenge quests.

[0071] When the overall selection check box 50a is operated, the overall selection check can be switched between on and off. When the rescue request transmission tab 50d is operated while the overall selection check box 50a is in the on state, a player for whom a search condition including a content ID linked to the started multi-battle is set is randomly selected from all players. Then, a rescue request is sent to the selected player. In this case, the randomly selected player can participate in the started multi-battle.

[0072] As another example, the player to whom the rescue request is to be sent may be extracted regardless of the search conditions set by each player. In this case, when communication is established between the player terminal 1 of the player set as the destination of the rescue request and the server 100, it may be determined whether the rescue request matches the search conditions. Then, the server 100 may allow only players determined to match the search conditions to receive the rescue request.

[0073] When the friend selection check box 50b is operated, the friend selection check can be switched on and off. When the rescue request transmission tab 50d is operated while the friend selection check box 50b is in the on state, a rescue request is transmitted to the player's friends. In this case, the player who transmitted the rescue request and the players who are registered as friends can participate in the started multi-battle.

[0074] In addition, here, when a friend is selected as the destination of the rescue request, the rescue request is sent regardless of the search condition settings of the player who is registered as a friend. In other words, each player may receive a rescue request from a player who is registered as a friend that does not match the search condition that the player has set. If the received rescue request does not match the search condition of the player, the rescue request may be displayed on the rescue list screen shown in FIG. 5C. However, the rescue request may be sent only to players who are registered as friends and who have search conditions set that include the content ID linked to the started multi-battle.

[0075] When the guild selection check box 50c is operated, the guild selection check can be switched on and off. When the rescue request sending tab 50d is operated while the guild selection check box 50c is in the on state, a rescue request is sent to players in the guild to which the player belongs. In this case, players in the guild to which the player who sent the rescue request belongs can participate in the multi-battle of the player who sent the rescue request.

[0076] In addition, here, when a guild is selected as the destination of the rescue request, the rescue request is sent regardless of the search conditions set by the players in the guild. In other words, each player may receive a rescue request from a player in the same guild that does not match the search conditions set by the player. If the received rescue request does not match the search conditions of the player, the rescue request may be displayed on the rescue list screen shown in FIG. 5C as described above. However, the rescue request may be sent only to players in the same guild who have search conditions set that include the content ID linked to the started multi-battle.

[0077] The rescue request tab 50d may be operated with the all selection checkbox 50a, the friend selection checkbox 50b, and the guild selection checkbox 50c all in an on state. In this case, a rescue request is sent to each of a player randomly selected from all players, a player registered as a friend, and a player in the guild to which the player belongs.

[0078] When the rescue request is completed by operating the rescue request sending tab 50d shown in Fig. 6A, the rescue request completion screen shown in Fig. 6B is displayed. When the OK tab 50f marked "OK" is operated on the rescue request completion screen, the screen is switched to the battle screen shown in Fig. 6C.

[0079] Also, when the cancel tab 50e shown in Fig. 6A is operated, a rescue request is not made, and the screen switches to the battle screen shown in Fig. 6C, allowing the player to fight alone. Note that if a battle is started without a rescue request being made and a predetermined time has passed, or if a rescue request is made but no rescuer is available even after a predetermined time has passed, the rescue request screen may be displayed again when the predetermined time has passed.

[0080] As shown in FIG. 6A, an SNS tab 50g is provided on the rescue request screen. When the SNS tab 50g is operated, a posting screen (not shown) is displayed and information that can be posted to a social network service (SNS) is generated. The information generated at this time includes, for example, a multi-battle ID. On the posting screen, the player can transmit the multi-battle ID of the started multi-battle to the outside via the SNS.

[0081] In this case, the SNS tab 50g is provided separately from the rescue request sending tab 50d. That is, the player can select whether to send a rescue request to other players within the game system or to send a rescue request to other players using an SNS outside the game. However, the SNS tab 50g is not essential. For example, when the rescue request sending tab 50d is operated, a rescue request may be sent via an SNS at the same time.

[0082] Furthermore, the method of sending a rescue request to other players using the SNS is not particularly limited, and any known technology can be applied. For example, the posted information may be sent directly to the SNS server by the game application. Also, for example, when a player switches the game application to an application for the SNS on the player terminal 1 and then performs a posting operation on the SNS application, the posted information may be sent to the SNS server.

[0083] As shown in Fig. 6C, in the upper half of the battle screen, ally characters 51a and enemy characters 51b are displayed. At the start of a battle, main members of the party are displayed as ally characters 51a. Fig. 6C also illustrates a case where there is one enemy character 51b.

[0084] Each enemy character 51b and each ally character 51a is set with a parameter value (e.g., HP value) related to life (or physical strength) (specifically, HP (hit points)). When the HP value of the enemy character 51b decreases and reaches a predetermined limit value (e.g., 0), the enemy character 51b disappears (is removed from the screen).

[0085] When all enemy characters 51b on the battle screen are eliminated, the battle is won and the quest is cleared. By clearing the quest, the player is given a reward. Also, when the HP value of any character among the ally characters 51a reaches a predetermined limit value (for example, 0), that character becomes unable to fight. The character that is unable to fight is removed from the battle screen, and if there is a sub-member, the sub-member appears on the battle screen.

[0086] The survival or disappearance of the enemy character 51b may be determined not only based on the HP value but also based on, for example, an HP ratio (parameter ratio) indicating the ratio of the remaining HP value to the maximum HP value. The HP ratio indicates the ratio of the remaining HP and may be expressed as a percentage. For example, when the HP ratio of the enemy character 51b decreases and reaches a ratio corresponding to a limit value (for example, 0%), the enemy character 51b may be disappeared.

[0087] Furthermore, the parameter relating to the life of the enemy character 51b is not limited to HP, and may be, for example, damage received by the enemy character 51b. In this case, the survival or disappearance of the enemy character 51b may be determined based on a total damage value obtained by accumulating the damage received. For example, when the total damage value of the enemy character 51b increases and reaches a predetermined limit value (for example, a value corresponding to the maximum value of HP), the enemy character 51b may be disappeared.

[0088] Furthermore, the survival or disappearance of the enemy character 51b may be determined based on a total damage ratio indicating the ratio of the total damage value to the maximum value of HP. The total damage ratio may be expressed as a percentage. For example, when the total damage ratio of the enemy character 51b increases and reaches a ratio corresponding to a limit value (e.g., 100%), the enemy character 51b may disappear.

[0089] 6C, a normal attack tab 52 marked "attack" is displayed on the battle screen. The normal attack tab 52 is located, for example, below the screen of the ally character 51a. The normal attack tab 52 accepts an input indicating an action (for example, an attack) of the player.

[0090] Basically, the multi-battle is turn-based. When the normal attack tab 52 is operated, the ally character 51a attacks the enemy character 51b, and then the enemy character 51b takes action, and one turn passes. When the ally character 51a attacks the enemy character 51b, the HP value of the enemy character 51b changes based on the attack.

[0091] When the enemy character 51b attacks the ally character 51a, the HP value of the ally character 51a changes based on the attack. After that, no turn passes until the normal attack tab 52 is next operated, and the enemy character 51b does not perform any action during that time.

[0092] Additionally, an ability selection tab 53a, a summon item selection tab 53b, a recovery tab 53c labeled "Recovery" are displayed in the lower half of the battle screen. An ability selection tab 53a is displayed for each ally character 51a displayed in the upper half of the screen. When the ability selection tab 53a is operated to determine the type of ability to be activated, the ally character 51a activates the determined ability.

[0093] Although details of abilities are omitted, when an ability is activated, a special effect due to the activated ability is given to the enemy character 51b or the ally character 51a. The number of turns from when an ability is activated until when it can be activated again is set for the ability.

[0094] When the summon item selection tab 53b is operated, the type of summon item to be used can be selected. As described above, the player can set party information on the organization screen. Here, summon items are included in the items that can be used in the multi-battle. As will be described in detail later, the party information that the player can set includes six types of summon items. When the summon item to be used in the multi-battle is determined, a summon action is executed. In the summon action, a summon character, which is a character linked to the determined summon item, is summoned, and an attack by the summon character is made to the enemy character 51b. Note that the summon action can be executed only once per turn.

[0095] When the recovery tab 53c is operated and the type of recovery item to be used is determined, the HP value of the ally character 51a is recovered by the determined recovery item.

[0096] Note that a turn does not end with the activation of an ability, the use of a summoned item, or the use of a recovery item. Each turn ends with an attack being executed by operating the normal attack tab 52. In other words, the player can activate an ability, use a summoned item, or use a recovery item before operating the normal attack tab 52. This allows the player to activate an ability, use a summoned item, or use a recovery item in addition to a normal attack during one turn.

[0097] Below the recovery tab 53c on the screen, a contribution display area 54 is formed. In the contribution display area 54, contribution information such as the contribution or ranking among one or more players in the multi-battle is displayed. When the player in the multi-battle is the only player (e.g., PY1), only the contribution information of the player in the multi-battle is displayed. When there are multiple players in the battle, the contribution information of the player in the multi-battle and the contribution information of the top two players among the other players in the multi-battle are displayed.

[0098] As shown in FIG. 6C, an HP gauge 55 of the enemy character 51b is displayed at the top of the battle screen. The HP gauge 55 is an image showing the HP ratio of the enemy character 51b. The HP gauge 55 is displayed in a bar shape extending in the left-right direction of the screen. The HP gauge 55 is displayed in a predetermined color. The predetermined color is, for example, red, but can be set to any color. The left end of the HP gauge 55 on the screen corresponds to the HP ratio corresponding to the limit value (for example, 0%). In FIG. 6C, the HP gauge 55 is displayed when the HP ratio is 100%. As the HP ratio decreases, the right end of the HP gauge 55 on the screen moves to the left side of the screen, and the length of the HP gauge 55 is shortened. By displaying the HP gauge on the battle screen, the player can easily recognize the state of the HP of the enemy character 51b.

[0099] The actions of the enemy character 51b are broadly divided into normal actions and special actions. Actions other than the special actions are all considered to be normal actions. The special actions have characteristics such as being stronger than the normal actions, having a wider attack range, or having a larger number of attacks.

[0100] The special action is managed in association with the parameter value (e.g., HP value) or parameter ratio (a ratio based on the maximum parameter value, e.g., HP ratio) of the enemy character 51b. The special action is executed based on the satisfaction of a specific condition. The specific condition may be, for example, that the normal attack tab 52 is operated and the parameter value or parameter ratio of the enemy character 51b reaches a preset specific value.

[0101] Although not shown in the figures, let us assume that a second player (PY2) joins a multi-battle in response to a rescue request from a first player (PY1). In this case, a pop-up such as "PY2 has joined the battle" is displayed on the battle screen of the player terminal 1 to inform the player that a rescuer has been added.

[0102] Furthermore, when the normal attack tab 52 is operated on the player terminal 1 of the second player, the ally character 51a of the second player attacks the enemy character 51b, and the HP value of the enemy character 51b changes. Then, on the player terminal 1 of the first player, even if the first player does not input an attack, the HP gauge 55 of the enemy character 51b changes in real time based on the attack input of the second player.

[0103] Also, in a multi-battle, when any player activates an ability, all players may enjoy the effect of that ability. For example, suppose that the second player (PY2) activates an ability that weakens the enemy character 51b. In this case, a pop-up explaining the effect of the activated ability is displayed on the battle screen of the other players (e.g., the first player) in the battle. Then, not only the second player but also the other players (e.g., the first player) in the battle can proceed with the battle with the enemy character 51b in a weakened state.

[0104] The game content of the multi-battle and the method of displaying the game screen are merely examples. In any case, as long as multiple players can participate, the game content is not particularly limited. The content of the battle game in the multi-battle will be described in detail below.

[0105] 6D is a diagram showing an example of an action screen. A multi-battle battle game can be broadly divided into a manual mode and an auto mode, and can be switched between these modes. The manual mode is a mode in which the player manually selects the actions of the ally character 51a, and the auto mode is a mode in which the CPU 110 automatically selects at least some of the actions of the ally character 51a. Here, the battle game in the manual mode will be described, and a description of the battle game in the auto mode will be omitted.

[0106] In the battle game in manual mode, the player can manually select an action of the ally character 51a. The actions that the player can select are broadly divided into two actions: normal actions and special actions. The normal actions are, for example, normal attack actions. The normal attack actions are executed manually by the player operating the normal attack tab 52, or automatically by the CPU 110. The special actions are, for example, ability actions, item use actions, and summon actions. The ability actions are executed manually by the player operating the ability selection tab 53a, or automatically by the CPU 110. The item use actions are executed manually by the player operating the recovery tab 53c. The summon actions are executed manually by the player selecting the summon item selection tab 53b, or automatically by the CPU 110.

[0107] When the normal attack tab 52 is operated, a normal attack action is started, and the four ally characters 51a perform normal attack actions against the enemy character 51b in a predetermined order (for example, the order set in the party formation). In the normal attack action, the ally characters 51a attack the enemy character 51b, thereby causing damage to the enemy character 51b. When the normal attack action is performed, as shown in FIG. 6D, an action image (normal attack animation) in which the ally character 51a attacks the enemy character 51b is displayed in order for each ally character 51a.

[0108] Here, as a normal attack animation, an animation of the ally character 51a attacking the enemy character 51b and the damage value inflicted on the enemy character 51b are displayed on the action screen. The damage value inflicted on the enemy character 51b is subtracted from the remaining HP of the enemy character 51b, and an animation of the HP gauge 55 of the enemy character 51b decreasing is also displayed.

[0109] When the normal attack actions of all four ally characters 51a are completed, the enemy character 51b then performs a counterattack action. The counterattack action of the enemy character 51b includes, for example, a normal attack action that attacks the ally character 51a and inflicts damage, and a special attack action that limits the action of the ally character 51a. When the enemy character 51b performs a counterattack action, an animation corresponding to the determined counterattack action is displayed on the action screen.

[0110] The ability selection tab 53a displays the HP of each ally character 51a in the party organized by the player. When a damage value is inflicted on an ally character 51a by a counterattack action of an enemy character 51b, an animation is displayed in which the HP of the ally character 51a displayed on the ability selection tab 53a decreases.

[0111] As described above, the player can cause the ally character 51a to execute a normal attack action by tapping the normal attack tab 52. When the normal attack action is executed, the ally character 51a executes the normal attack action four times first, and then the enemy character 51b executes a counterattack action.

[0112] In this embodiment, the battle game is broadly divided into three sections: a special action section, a normal action section, and a counterattack action section. The special action section is a section in which the player selects and executes an ability action, an item use action, and a summon action. The normal action section is a section in which the above-mentioned normal attack action, that is, the normal attack action of the ally character 51a, is performed. The counterattack action section is a section in which the enemy character 51b performs a counterattack action.

[0113] In the following, the two sections, the special action section where the ally character 51a can mainly perform actions and the normal action section, are collectively referred to as the player's turn. The counterattack action section where the enemy character 51b can mainly perform actions is referred to as the enemy turn. When the player's turn ends, the game moves to the enemy turn, and when the enemy turn ends, the game moves to the player's turn. Two consecutive turns, the player's turn and the enemy turn, are collectively referred to as one turn.

[0114] The battle game progresses by repeating this turn. At the start of a turn, there is first a special action section for the player's turn. Then, as the player's character begins a normal attack action, the special action section ends and a normal action section begins. When the normal action section ends, the player's turn ends and the enemy's turn begins. When the enemy's turn begins, a counterattack action section begins, and when the counterattack action section ends, the enemy's turn ends. This ends one turn of the battle game.

[0115] Then, when the HP of the enemy character 51b becomes 0 during one repeated turn of the battle game, the end condition of the battle game is met, and the battle game ends with the player's victory.

[0116] Here, abilities as special abilities are preset for each ally character 51a. The abilities include, for example, abilities that affect the ally character 51a, abilities that affect the enemy character 51b, and abilities that affect both the ally character 51a and the enemy character 51b.

[0117] The abilities that affect the ally character 51a include abilities that provide advantageous effects to the ally character 51a, such as a strengthening ability that increases the attack power or defense power of the ally character 51a, and a recovery ability that restores the HP of the ally character 51a.

[0118] Abilities that affect the enemy character 51b include abilities that impart detrimental effects to the enemy character 51b, damage abilities that impart damage values ​​to the enemy character 51b, etc. An example of an ability that imparts detrimental effects to the enemy character 51b is a weakening ability that reduces the attack power or defense power of the enemy character 51b. The weakening abilities also include abnormal status abilities that impart abnormal statuses to the enemy character 51b (for example, restricting the actions of the enemy character 51b).

[0119] An ability that affects both the ally character 51a and the enemy character 51b is, for example, a field effect ability that exerts an effect on the entire field in which the ally character 51a and the enemy character 51b are placed. The field effect ability exerts, for example, an effect of increasing the attack power of both the ally character 51a and the enemy character 51b.

[0120] In the special action section, the player can activate the available abilities any number of times. However, each ability has a usage limit condition set, and the player can only select abilities that do not have a usage limit. For example, some abilities have a usage limit condition that limits the number of times they can be used in one battle game, some abilities have a usage limit until a certain activation condition is met, and some abilities have a number of turns until they can be used again.

[0121] In addition, in the special action section, the player can use a recovery item by tapping the recovery tab 53c. When this recovery item is used, the player can recover the HP value of the ally character 51a, and can otherwise gain an advantage in the battle game, just like when an ability is used.

[0122] Furthermore, in the special action section, the player can activate a summoning effect by a summoning action by tapping the summoning item selection tab 53b. The ally character 51a can be equipped with a summoning item as equipment in addition to a weapon. A predetermined summoning activation condition is set for the summoning item. When the summoning activation condition set for the summoning item is satisfied, the summoning item equipped to the ally character 51a is operated by the player, and a predetermined utility (effect) is activated. When the utility is activated, a beneficial effect is given to the ally character 51a, a detrimental effect is given to the enemy character 51b, or a damage value is given to the enemy character 51b. This allows the player to advantageously proceed through the battle game.

[0123] Fig. 7A is a diagram illustrating an example of an ability selection frame 56. When the ability selection tab 53a of any of the ally characters 51a is tapped during a special action section, the ability selection frame 56 is displayed on the display 26, as shown in Fig. 7A. The ability selection frame 56 is provided with an ability icon 56a and an ability explanation area 56b. The ability explanation area 56b is displayed to the right of the ability selection frame 56. The ability explanation area 56b displays the ability icon 56a and an explanation of the ability.

[0124] An ability icon 56a is provided for each ability set for each ally character 51a. If the ally character 51a has multiple abilities, multiple ability icons 56a are displayed in the ability explanation area 56b. The number of ability icons 56a varies depending on the type of ally character 51a, the level of ally character 51a, etc.

[0125] Fig. 7B is a diagram illustrating an example of an animation when an ability is used. When the ability icon 56a in the ability selection frame 56 shown in Fig. 7A is tapped, the reservation action display section 57 is displayed at the top of the display 26 as shown in Fig. 7B. At this time, the reservation action display section 57 displays the tapped ability icon 56a.

[0126] Meanwhile, in the ability selection frame 56, the display mode of the ability icon 56a displayed in the reserved action display section 57 is changed from a usable mode to a use restricted mode (here, a cross is superimposed on the ability icon 56a). Note that when the use restriction of the ability icon 56a is lifted and it becomes usable again, the ability icon 56a is changed from the use restricted mode to the usable mode.

[0127] A maximum of five ability icons 56a are displayed in the reserved action display section 57. The ability icons 56a are arranged in order from the top to the bottom of the reserved action display section 57 in the order in which they are tapped. Also, in the special action section, the ability actions corresponding to the ability icons 56a displayed in the reserved action display section 57 are executed in order from the top to the bottom of the reserved action display section 57.

[0128] In this way, the ability actions are executed in the special action section in the order that the ability icons 56a are tapped (i.e., from the top to the bottom of the reserved action display section 57). The ability actions change the values ​​of various parameters (parameter values) used in the battle game, such as the HP and attack power of the ally character 51a or enemy character 51b. In addition, an action image (ability animation) corresponding to the ability action is displayed on the display 26, as shown in FIG. 7B.

[0129] FIG. 7C is a diagram illustrating a state in which an ability action has ended. FIG. 7D is a diagram illustrating an example of an animation when a reserved ability action is started. When the display of the ability animation ends, as shown in FIG. 7C, the ability icon 56a displayed at the top of the reserved action display section 57 is erased, and the other ability icons 56a displayed below it move upward. In other words, the ability icon 56a corresponding to the used ability is erased as the ability animation ends.

[0130] Then, the ability action corresponding to the ability icon 56a that has moved to the top of the reserved action display section 57 is started. In this case, various parameters used in the battle game are changed in the same manner as above. Also, as shown in FIG. 7D, an ability animation corresponding to the ability action is displayed.

[0131] Furthermore, if the next ability has not been reserved when the ability action ends, in other words, if the next ability icon 56a is not displayed in the reserved action display section 57, the reserved action display section 57 will be hidden as the ability animation ends.

[0132] In this way, the player can manually select and execute an ability of the ally character 51a in the special action section of the manual mode. When the selected ability is executed, an ability animation corresponding to the ability is displayed. Also, in the special action section, abilities can be executed consecutively by reserving multiple ability actions in the reserved action display section 57. However, even if the ability icon 56a is tapped while the ability animation is being displayed, the ability action of the tapped ability icon 56a cannot be started immediately. In this case, the execution of the next ability action is put on hold until the display of the ability animation ends.

[0133] Here, the case where the ability icon 56a is tapped and an ability action is selected, reserved, and executed has been described, but when the recovery tab 53c is tapped and the recovery item to be used is determined, an item use action is selected, reserved, and executed in the same manner as described above. In this case, an item icon (not shown) corresponding to the recovery item selected by the player is displayed in the reserved action display section 57. When the item use action is executed, an item use animation is displayed.

[0134] Similarly, when the summoning item selection tab 53b is tapped and then the summoning item is confirmed, the summoning action is selected, reserved, and executed. In this case, the reserved action display section 57 displays a summoning item icon (not shown) corresponding to the summoning item selected by the player. When the summoning action is executed, a summoning animation is displayed.

[0135] In this embodiment, up to five ability actions, item use actions, and summon actions can be reserved. The reserved action display unit 57 can be said to inform the player of the abilities, items, or summon items that are reserved for use.

[0136] Furthermore, when the ability icon 56a, item icon, or summon item icon displayed in the reserved action display section 57 is tapped, the icon is removed from the reserved action display section 57. In other words, the player can cancel the reserved ability action, item use action, or summon action by tapping the ability icon 56a, item icon, or summon item icon displayed in the reserved action display section 57.

[0137] In addition, the player may use some or all of the available abilities, items, and summoning items during the special action section, or may not use any of them. When the desired abilities, items, and summoning items have been used, or when there is no need to use abilities, items, or summoning items, the player can end the special action section by tapping the normal attack tab 52.

[0138] Although detailed explanation is omitted, the player can tap the normal attack tab 52 during an ability action, an item use action, a summon action, or even when the use of an ability, an item, or a summon item is reserved. In this case, an icon corresponding to the normal attack action is displayed in the reserved action display section 57, and the normal attack action is reserved. Then, the start of the normal attack action enters the normal action section, and the special action section ends. As described above, in the normal action section, the ally character 51a performs a normal attack action, followed by the enemy character 51b performing a counterattack action, but during this time, it is not possible to reserve an ability, an item, or a summon item.

[0139] In this embodiment, the player can set in advance a mode in which the use of abilities, items, and summoned items can be reserved (reservation permitted state) and a mode in which the use of abilities, items, and summoned items cannot be reserved (reservation unavailable state) in the special action section. When the reservation unavailable state is set, for example, if the ability icon 56a displayed in the ability selection frame 56 is tapped, the ability action is immediately started, but the reserved action display section 57 is not displayed. Also, while the action images (normal attack animation, ability animation, item use animation, summon animation) are displayed, tapping the ability icon 56a in the ability selection frame 56 is disabled.

[0140] During the battle game, a predetermined meter value (hereinafter, also referred to as a special technique gauge value) accumulates for each ally character 51a. This meter value increases by a predetermined value each time a normal attack action is performed, or increases by the use of abilities or items. As shown in FIG. 6D, a special technique activation selection tab 53d is displayed in the lower half of the screen of the display 26.

[0141] The secret technique activation selection tab 53d is configured to be switchable between an ON state and an OFF state by being operated by the player. When the meter value of the ally character 51a reaches the maximum value, the secret technique activation condition for activating the secret technique attack action of the ally character 51a is met. On the other hand, when the meter value of the ally character 51a does not reach the maximum value, the secret technique activation condition is not met, and the secret technique attack action cannot be activated.

[0142] When the special attack selection tab 53d is set to the ON state, it allows the ally character 51a whose special attack condition is satisfied to perform a special attack action, and when it is set to the OFF state, it restricts the ally character 51a whose special attack condition is satisfied from performing a special attack action. In the manual mode, when the special attack selection tab 53d is set to the ON state and the special attack condition of any of the ally characters 51a is satisfied, the attack action of the ally character 51a whose special attack condition is satisfied becomes a special attack action instead of a normal attack action.

[0143] This special attack action gives more damage to the enemy character 51b than the normal attack action. On the other hand, when the special attack selection tab 53d is in the OFF state and the normal attack tab 52 is tapped while the special attack condition of any of the ally characters 51a is satisfied, the attack action of the ally character 51a whose special attack condition is satisfied remains the normal attack action, and the special attack action is not activated. In other words, when the special attack selection tab 53d is in the OFF state, the special attack action of the ally character 51a is preserved, and the meter value that has reached the maximum value is maintained. After the special attack action is activated, the meter value is reset to 0.

[0144] The special attack action can be activated for each ally character 51a individually, but can also be activated for multiple ally characters 51a simultaneously. For example, when the normal attack tab 52 is tapped when the meter values ​​of all four ally characters 51a reach their maximum values, a special special action is activated. This special special action inflicts much more damage on the enemy character 51b than a single special attack action.

[0145] Here, as described above, when a summoning item is used, a summoning action is executed. A utility such as causing great damage to the enemy character 51b is linked to the summoning item. Therefore, by selecting a summoning item, the player can activate the utility linked to the selected summoning item. In addition, in this embodiment, when a player executes a summoning action, in addition to the utility linked to the summoning item selected by the player, a utility activated by another player may be additionally activated. The utility activated by the use of a summoning item will be described in detail below.

[0146] FIG. 8 is a diagram for explaining an example of a summoning item. In this embodiment, multiple types of summoning items are provided. A player can possess summoning items acquired by gacha or the like. A player can set six summoning items that can be used in a multi-battle on the organization screen. Specifically, a player can select and set five types of summoning items from among the summoning items that the player possesses. In addition, a player can rent and set one of the summoning items possessed by another player.

[0147] As shown in FIG. 8, a summoning item is linked to a summoning item ID. One summoning item is always linked to one summoning item ID. The summoning item ID is information for identifying the type of summoning item. A utility ID is also linked to a summoning item. The utility ID is linked to a utility that is activated when the summoning item is used, that is, a summoning action. The summoning action is executed based on the utility ID or summoning item ID linked to the summoning item selected by the player.

[0148] As described above, in a multi-battle, the game progresses simultaneously in parallel on the player terminals 1 of multiple players. When a player executes a summoning action using a summoning item, information on the summoning item used or the utility activated, and the player ID of the player who used the redeemable item are sequentially accumulated in the server 100. Therefore, the server 100 can grasp the summoning item last used or the utility last activated in the multi-battle.

[0149] When a player uses a summoning item, in addition to the utility associated with the summoning item used, the utility associated with the most recent (last) summoning item used by other players during the multi-battle may be activated. In other words, the use of one summoning item may simultaneously activate a utility associated with the summoning item being used and a utility associated with another summoning item. In this way, the activation of two types of utility by the use of one summoning item is called the fusion of summoning items or utilities. In the following, for ease of understanding, it will be described as summoning items being fused.

[0150] Specifically, summoning items are combined with two summoning items: one that was used relatively earlier and one that was used relatively later. In other words, utility is combined with two utilities: one that was activated relatively earlier and one that was activated relatively later. Thus, a summoning item may be combined with another summoning item that was used earlier, or may be combined with another summoning item that was used later. A summoning item that has been used goes into a standby state for combination, waiting to be combined with another summoning item that will be used later. When another summoning item is used while another summoning item is in standby state for combination, the utility associated with the summoning item in standby state for combination and the utility associated with the summoning item that was used are activated.

[0151] However, summoning items include summoning items that can be combined and summoning items that cannot be combined. As shown in FIG. 8, each summoning item is associated with combination standby permission information. The combination standby permission information is information that identifies whether or not an item can be placed in a combination standby state, waiting to be combined with a summoning item that will be used later. In other words, the combination standby permission information is information that identifies whether or not an item can be combined with a summoning item that will be used later, i.e., whether or not it can be a combination source.

[0152] In the example shown in FIG. 8, summon items A, C, D, and F can be the source of a fusion for a summon item used later, but summon items B and E cannot be the source of a fusion. In addition, fusion is performed with two types of summon items, but each summon item is set with summon items that can be fused with it. For example, summon item A can be fused with summon items C and F, but cannot be fused with summon items A, B, D, and E. Therefore, for example, if another player recently used summon item C, and summon item C was in a standby state for fusion, and then a player uses summon item A, the use of summon item A will activate two utilities associated with summon items A and C, respectively.

[0153] On the other hand, suppose that summoning item D was used most recently, and then summoning item A was used after summoning item D was put into a fusion standby state. Summoning item A is set so that it cannot be fused with summoning item D. In other words, summoning item D is not suitable as a fusion source for summoning item A. Therefore, in this case, the use of summoning item A will activate one utility linked to summoning item A.

[0154] Furthermore, summon items whose fusion standby permission information is set to "not allowed" cannot be in a fusion standby state in the first place. For example, when a player executes a summon action using summon item B, information about summon item B or the activated utility is not stored in the server 100. Since information about summon item B is not stored in the server 100, summon item B cannot become a fusion source.

[0155] FIG. 9A is a diagram illustrating an example of a summoning item selection frame 70 when fusion is not possible. FIG. 9B is a diagram illustrating an example of a summoning information dialogue 71 when fusion is not possible. When the summoning item selection tab 53b is operated on the battle screen shown in FIG. 6C, the summoning item selection frame 70 is displayed as shown in FIG. 9A. Six summoning item images are displayed in the summoning item selection frame 70. The summoning item images correspond to the six summoning items previously set by the player.

[0156] Here, the six summon item images are called summon item images 70a, 70b, 70c, 70d, 70e, and 70f. The player can select the summon item to be used by operating the summon item images 70a, 70b, 70c, 70d, 70e, and 70f displayed in the summon item selection frame 70.

[0157] As described above, summoning conditions are set for each summoning item. Summoning item images corresponding to summoning items that do not satisfy the summoning conditions are displayed grayed out, as shown by cross-hatching in FIG. 9A. Operational inputs to summoning item images that are displayed grayed out are invalid. The summoning conditions include the number of turns required from the start of the multi-battle or from the last time the item was used. Summoning item images corresponding to summoning items that do not satisfy the summoning conditions display the number of turns remaining until the summoning item can be used.

[0158] In contrast, summoning item images corresponding to summoning items that satisfy the summoning conditions are displayed more emphasized than summoning item images corresponding to summoning items that do not satisfy the summoning conditions. In the example shown in Fig. 9A, the summoning items corresponding to summoning item images 70a, 70c, and 70f satisfy the summoning conditions, and the summoning items corresponding to summoning item images 70b, 70d, and 70e do not satisfy the summoning conditions. When a summoning item image corresponding to a summoning item that satisfies the summoning conditions is operated, a summoning information dialog 71 shown in Fig. 9B is displayed.

[0159] The summoning information dialogue 71 is provided with a summoning information display field 71a. The summoning information display field 71a displays summoning information, which is information about the summoning item selected by the player. The summoning information includes, for example, the name of the summoning item and an explanation of the effect that is activated by using the summoning item. Note that the contents of the summoning information displayed in the summoning information dialogue 71 are merely an example.

[0160] In addition, a cancel button 71b and an activate button 71c are provided at the bottom of the summoning information dialog 71. When the cancel button 71b is operated, the use of the summoning item selected in the summoning item selection frame 70 is canceled. In this case, the summoning information dialog 71 is closed, and the battle screen shown in FIG. 9A is displayed.

[0161] On the other hand, when the activation button 71c is operated, the summoning item selected by the player is used and the summoning action is executed. In this case, the summoning information dialogue 71 is closed, and the battle screen shown in FIG. 6C is displayed. Also, when the activation button 71c is operated, if the summoning action is not executed immediately, the summoning action is reserved. In this case, a summoning item icon is displayed in the reserved action display section 57 shown in FIG. 7C.

[0162] FIG. 10A is a diagram illustrating an example of the summoning item selection frame 70 when fusion is possible. FIG. 10B is a diagram illustrating an example of the summoning information dialog 71 when fusion is possible. As described above, when the summoning item selection tab 53b is operated on the battle screen shown in FIG. 6C, the summoning item selection frame 70 is displayed. When the summoning item selection frame 70 is displayed, the server 100 checks whether or not there is fusion waiting information.

[0163] At this time, if there is fusion waiting information, for each summoning item that satisfies the summoning activation condition, it is determined whether or not fusion with the previously used summoning item as the fusion source is possible. If it is determined that fusion is possible, the player acquires the right to combine the summoning item with the fusion source (hereinafter referred to as the fusion right). In this way, by acquiring the fusion right, the player is able to combine the summoning item with the fusion source. Note that, as will be described in detail later, once a player acquires the fusion right for one fusion source, other players cannot acquire the same fusion right. In other words, the fusion right for one fusion source is granted to any one player only once.

[0164] When the player acquires the right to combine, a suggestion image 72 with the word "CHANCE" written on it is superimposed on the summon item image corresponding to the summon item that can be combined, as shown in Fig. 10A. In other words, in the summon item selection frame 70, the suggestion image 72 makes it possible to identify the summon items that can be combined.

[0165] As described above, when a summoning item that satisfies the summoning activation conditions is selected in the summoning item selection frame 70, the summoning information dialogue 71 is displayed. At this time, when a summoning item that can be combined is selected, a combination information display field 71d and a combination cancellation button 71e are provided in the summoning information dialogue 71, as shown in Fig. 10B. Note that, when a summoning item that cannot be combined is selected in Fig. 10A, a summoning information dialogue 71 without the combination information display field 71d and the combination cancellation button 71e is displayed, as shown in Fig. 9B.

[0166] The fusion information display field 71d displays information about fusion. The fusion information includes, for example, information about the additional utility that is activated by the fusion of summoned items, i.e., the utility of the items to be fused. In this way, the player can check all the utilities that are activated when the summoned items are fused by using the selected summoned item in the summoning information dialogue 71. In the following, all the utilities that are activated when the summoned items are fused may be collectively referred to as special utilities.

[0167] Then, when the activate button 71c of the summoning information dialogue 71 is operated with a summoning item that can be combined selected, a summoning action is executed. The summoning action executed at this time activates the utility linked to the summoning item selected by the player and the utility linked to the summoning item to be combined. The combination right is extinguished by using the summoning item, i.e., by executing the summoning action. Each player can only hold one combination right at a time. In other words, each player cannot acquire a new combination right while possessing a combination right. Therefore, a player can acquire a new combination right by using a summoning item to use the combination right. However, a player may be able to hold multiple combination rights at a time.

[0168] Furthermore, when the combination cancellation button 71e is operated, the combination right acquired by the player is discarded. In this case, the summoning information dialogue 71 switches from the state shown in FIG. 10B to the state shown in FIG. 9B. When the activation button 71c is operated after the summoning information dialogue 71 switches, the summoning action is executed. However, in this case, since the combination right has already been discarded, the utility linked to the summoning item that was the source of the combination is not activated. By discarding the combination right, the player can acquire a new combination right.

[0169] Here, the fusion right once acquired will only be lost when it is destroyed by use, discarded, or the multi-battle ends as described above. Therefore, if the cancel button 71b is operated in the state shown in Figure 10B, the fusion right already acquired will not be lost. In this case, the summon information dialog 71 is closed with the fusion right reserved, and the battle screen shown in Figure 10A is displayed.

[0170] As described above, the player's turn does not end until the normal attack tab 52 is operated, and it is possible to activate an ability multiple times during one turn. Therefore, the player can execute other actions, such as activating an ability, while possessing the fusion right. In addition, the fusion right is reserved across turns. Therefore, if the current turn ends with the fusion right reserved, the player can use the fusion right from the next turn onward.

[0171] In addition, a summoning item that does not satisfy the summoning condition when the fusion right is acquired may satisfy the summoning condition in the next turn or later. For example, in FIG. 10A, the summoning item corresponding to the summoning item image 70d satisfies the summoning condition in the next turn. When the current turn ends with the fusion right reserved, the summoning item corresponding to the summoning item image 70d becomes available in the next turn.

[0172] At this time, it is assumed that the summoned item corresponding to the summoned item image 70d can be combined with the combination source. In this case, when the summoned item corresponding to the summoned item image 70d is selected in the next turn, the combination right is used. In this way, the player can reserve the combination right, and while reserving the combination right, the player can select another action to proceed with the game.

[0173] In addition, the reserved fusion right can be discarded in the next turn after the turn in which the fusion right was acquired. Even in the next turn, the player can discard the fusion right he holds by displaying the summon information dialogue 71 once and operating the fusion cancellation button 71e.

[0174] 11A is a first diagram illustrating an example of a presentation when a summoning action is executed. For example, assume that a summoning action is executed by using a summoning item A. In this case, as shown in FIG. 11A, a game image 80 corresponding to the summoning item A and the utility activated by using the summoning item A is displayed. The game image 80 includes an object such as a summoned character linked to the summoning item A.

[0175] 11B is a second diagram illustrating an example of a presentation when a summoning action is executed. For example, assume that a summoning action is executed by using summoning item B. In this case, as shown in FIG. 11B, a game image 81 corresponding to summoning item B and the utility activated by using summoning item B is displayed. The game image 81 includes an object such as a summoned character linked to summoning item B.

[0176] FIG. 11C is a third diagram for explaining an example of the presentation when the summon action is executed. For example, suppose that the use of the summon item A results in the use of the fusion right with the summon item B as the fusion source. In this case, the execution of the summon action results in the display of game images 80 and 81, as shown in FIG. 11C. When the fusion right is used, the utility (first utility) activated by the other player is added to the utility (second utility) linked to the summon item selected by the player. Based on the activation of the first utility and the second utility, the game image 81 (first game display) corresponding to the first utility and the game image 80 (second game display) corresponding to the second utility are displayed. This allows the player to easily understand that the fusion right has been used.

[0177] In addition, for example, the name of the summoning item and the name of the summoning character linked to the summoning item are displayed in text at the top of the game images 80 and 81. When the fusion right is used, a special name that combines the names corresponding to the two summoning items is displayed. This makes it possible for the player to have a special feeling, and increases the interest of the game.

[0178] Next, the flow of acquiring and using the combined right will be specifically described using an example.

[0179] FIG. 12 is a first diagram showing operation inputs of multiple players in a chronological order. FIG. 13 is a second diagram showing operation inputs of multiple players in a chronological order. A cache having multiple (N) memory areas is provided in the server 100. The number (N) of memory areas provided in the cache is not particularly limited, but it is desirable that the number (N) of memory areas is, for example, equal to or greater than the number of summoned items expected to be used in one multi-battle. Here, information is stored in the memory areas in the order of a first memory area M1 to an Nth memory area MN.

[0180] Each storage area is provided with a waiting information storage section and a completion information storage section. The waiting information storage section stores waiting information. The waiting information is information corresponding to the summoning item used or the utility activated. Here, it is described that the waiting information is stored as information corresponding to the utility activated in the multi-battle. Specifically, the waiting information storage section stores a utility ID linked to the activated utility. However, the waiting information stored in the waiting information storage section may be, for example, a summoning item ID linked to the summoning item used. Alternatively, the waiting information may include both the utility ID and the summoning item ID. The waiting information may also be other information linked to the summoning item. In any case, the waiting information may be information that can identify the summoning item used or the utility activated, and the content of the waiting information is not particularly limited.

[0181] The completion information storage unit stores completion information. The completion information is information indicating whether or not a fusion right using the used summoning item as the fusion source has been acquired by any player. In other words, the completion information is information for locking the fusion right acquired by any player and preventing other players from acquiring it. Here, two types of flags, "0" and "1", are set as the completion information. The completion information "0" indicates that the fusion right has not been acquired, and the completion information "1" indicates that the fusion right has already been acquired.

[0182] 12 and 13, tn (n=1 to 13) indicates the time elapsed from the start of the multi-battle, and the smaller n is, the shorter the elapsed time is. At t1 in FIG. 12, the player (PY1) inputs a selection operation to select summoning item A in the summoning item selection frame 70 shown in FIG. 9A. Then, at t2, the player (PY1) inputs an operation on the summoning information display field 71a of the summoning information dialogue 71 (hereinafter, referred to as an activation operation).

[0183] By inputting the activation operation, a utility with utility ID=1000 is activated on the player terminal 1 of the player (PY1). At this time, the utility ID (1000) of the activated utility is stored in the waiting information storage section of the first storage area M1. Also, "0" is stored in the completion information storage section of the first storage area M1.

[0184] Then, at t3, the player (PY2) inputs a selection operation to select the summoned item C in the summoned item selection frame 70 shown in FIG. 10A. At this time, waiting information indicating the most recently activated utility is stored in the first memory area M1. In addition, the completion information storage section of the first memory area M1 stores "0", indicating that the fusion right has not yet been acquired. In this way, if the fusion right using the most recently activated utility as the fusion source has not yet been acquired, this unacquired fusion right is acquired at the time of selecting the summoned item.

[0185] Therefore, as shown by the dashed line at t3 in the figure, the utility ID stored in the first storage area M1 is linked to the player ID of the player (PY2) as a fusion right. By linking the utility ID, i.e., the waiting information, to the player ID, the fusion right is acquired. At this time, the flag in the completion information storage section of the first storage area M1 is updated from "0" to "1". As a result, the fusion right of the utility stored in the first storage area M1 has been acquired.

[0186] Then, at t4, the player (PY2) inputs an activation operation. At this time, the player (PY2) possesses a fusion right with a utility ID of 1000. Therefore, the utility with the utility ID of 1002 linked to the summoned item C and the utility with the utility ID of the fusion source of 1000 are activated. As a result, the player (PY2) has used the fusion right, and the fusion right is extinguished. At this time, the standby information storage unit of the second storage area M2 stores the utility ID of 1002 linked to the summoned item selected by the player (PY2). The completion information storage unit of the second storage area M2 stores the flag "0".

[0187] After that, at t5, the player (PY3) inputs a selection operation to select the summon item D in the summon item selection frame 70 shown in FIG. 10A. At this time, standby information indicating the most recently activated utility is stored in the second memory area M2. In addition, the completion information storage section of the second memory area M2 stores "0", which indicates that the right to combine has not yet been acquired.

[0188] Therefore, as shown by the dashed line at t5 in the figure, the utility ID stored in the second storage area M2 is linked to the player ID of the player (PY3) as a fusion right. By linking the utility ID, i.e., the waiting information, to the player ID, the fusion right is acquired. At this time, the flag in the completion information storage section of the second storage area M2 is updated from "0" to "1". As a result, the fusion right of the utility stored in the second storage area M2 has been acquired.

[0189] Then, at t6, the player (PY3) inputs an activation operation. At this time, the player (PY3) has a fusion right with a utility ID of 1002. Therefore, the utility with the utility ID of 1003 linked to the summoned item D and the utility with the utility ID of the fusion source of 1002 are activated. As a result, the player (PY3) has used the fusion right, and the fusion right is extinguished. At this time, the standby information storage unit of the third storage area M3 stores the utility ID of 1003 linked to the summoned item selected by the player (PY3). The completion information storage unit of the third storage area M3 stores the flag "0".

[0190] Then, at t7, the player (PY4) inputs a selection operation to select the summoned item E in the summoned item selection frame 70. At this time, standby information indicating the most recently activated utility is stored in the third memory area M3. In addition, the completion information storage section of the third memory area M3 stores "0", indicating that the fusion right has not yet been acquired. Therefore, at the time of t7, each player can acquire the fusion right of the utility ID=1003 stored in the third memory area M3, that is, the fusion right with the summoned item D as the fusion source.

[0191] However, the summon item E is set to be unable to be combined with the summon item D as the source of the combination. Therefore, as shown by the dashed line at t7 in the figure, the utility ID stored in the third memory area M3 is not linked to the player ID of the player (PY4). In other words, the player (PY4) cannot acquire the right to combine. Since the right to combine is not granted, the information in the third memory area M3 is retained as it is.

[0192] After that, at t8, it is assumed that the player (PY4) inputs an activation operation. At this time, the player (PY4) does not have a fusion right. Therefore, the utility of utility ID=1004 linked to the summoned item E is activated. Here, the fusion standby permission information of the summoned item E is set to "not allowed", and the summoned item E cannot be a fusion source. In this way, when a summoned item with the fusion standby permission information set to "not allowed" is used, the standby information is not stored in the server 100. Therefore, at t8, no new standby information is stored in the fourth memory area M4, and the information in the first memory area M1 to the third memory area M3 is maintained as it is.

[0193] Then, at t9, the player (PY1) inputs a selection operation to select summon item A in the summon item selection frame 70. At this time, standby information indicating the most recently activated utility is stored in the third memory area M3. In addition, the completion information storage section of the third memory area M3 stores "0", indicating that the fusion right has not yet been acquired. Therefore, at the time of t9, each player can acquire the fusion right of utility ID=1003 stored in the third memory area M3, that is, the fusion right with summon item D as the fusion source.

[0194] However, summon item A is set to be unable to be combined with summon item D as the source of the combination. Therefore, as shown by the dashed line at t9 in the figure, the utility ID stored in the third memory area M3 is not linked to the player ID of the player (PY1). In other words, the player (PY1) cannot acquire the right to combine. Since the right to combine is not granted, the information in the third memory area M3 is retained as is.

[0195] Then, at t10, the player (PY1) inputs an activation operation. At this time, the player (PY1) does not have the right to combine. Therefore, the utility with the utility ID=1000 linked to the summoned item A is activated. Note that the combination waiting permission information of the summoned item A is set to "Yes", and it can be the source of the combination. Therefore, at t10, the waiting information storage section of the fourth storage area M4 stores the utility ID=1000 linked to the summoned item selected by the player (PY1). Also, the completion information storage section of the fourth storage area M4 stores the flag "0".

[0196] After that, at t11, the player (PY2) inputs a selection operation to select the summoning item F. At this time, standby information indicating the most recently activated utility is stored in the fourth memory area M4. In addition, the completion information storage section of the fourth memory area M4 stores "0", indicating that the right to combine has not yet been acquired.

[0197] Therefore, as shown by the dashed line at t11 ​​in the figure, the utility ID stored in the fourth storage area M4 is linked to the player ID of the player (PY2) as a fusion right. At this time, the flag in the completion information storage section of the fourth storage area M4 is updated from "0" to "1". As a result, the fusion right of the utility stored in the fourth storage area M4 is acquired.

[0198] Then, before the player (PY2) inputs the activation operation, at t12, the player (PY5) inputs a selection operation to select the summoning item F. At this time, standby information indicating the most recently activated utility is stored in the fourth storage area M4. However, the completion information storage section of the fourth storage area M4 stores "1" indicating that the fusion right has been acquired. In other words, the most recently activated utility, that is, the fusion right for the most recently used summoning item, has already been acquired by another player. In this case, as shown by the dashed line at t12 in the figure, the utility ID stored in the fourth storage area M4 is not linked to the player ID of the player (PY2). In other words, the player (PY2) cannot acquire the fusion right.

[0199] In this embodiment, when the selection operation is input, if the combination right for the most recently activated utility has already been acquired by another player, the player cannot acquire any combination right. However, in the example shown in FIG. 13, waiting information for which the combination right has not been acquired exists in the third storage area M3. In this way, if the combination right for the most recently activated utility has been acquired and the combination right for the utility activated before that has not been acquired, any of the unacquired combination rights may be granted to the player.

[0200] After that, before the player (PY5) inputs the activation operation, at t13, the player (PY2) inputs the activation operation to use the summoning item F. At this time, the player (PY2) has a fusion right with a utility ID of 1000. Therefore, the utility with the utility ID of 1005 linked to the summoning item F and the utility with the utility ID of the fusion source of 1000 are activated. As a result, the player (PY2) uses the fusion right, and the fusion right is extinguished. At this time, the standby information storage unit of the fifth storage area M5 stores the utility ID of 1005 linked to the summoning item selected by the player (PY2). In addition, the completion information storage unit of the fifth storage area M5 stores the flag "0".

[0201] As described above, according to this embodiment, in a multi-battle in which multiple players can participate, a first utility is activated based on the input of an activation operation (first operation) by a first player. Furthermore, based on the input of the first operation or the activation of the first utility, predetermined standby information is enabled. When the standby information is enabled, a special utility consisting of a predefined second utility and a first utility is determined as an activateable utility based on the input of a selection operation by a second player. Furthermore, based on the input of a selection operation by the second player or the determination of the special utility, the standby information is disabled. Then, the second player can select one of a plurality of operations including at least an activation operation for activating the determined special utility and a discard operation for discarding the determined special utility. The special utility is activated based on the input of an activation operation by the second player, and the special utility is discarded based on the input of a discard operation.

[0202] In this way, the player can choose to use or discard the combination right, improving the game's appeal. Also, by discarding the combination right, a new combination right can be acquired, improving the game's strategic appeal.

[0203] Furthermore, the multiple operations that the second player can select include an operation for progressing through the multi-battle while reserving the activation of special effects, which further enhances the strategic nature of the game.

[0204] In addition, the second player can acquire the fusion right by performing a selection operation to select a second utility to be activated in the multi-battle from among a plurality of second utilities. In this way, the content of the special utility can be understood at the time of inputting the selection operation, so that the second player can easily select whether to use or discard the fusion right.

[0205] The following describes the processes of the player terminal 1 and the server 100 for implementing the above game, and the functional units that execute these processes. Note that the following describes the processes related to summon items in the multi-battle, and omits descriptions of other processes.

[0206] (Functional parts of player terminal 1) 14 is a functional block diagram of the player terminal 1. A program storage area 12a and a data storage area 12b are provided in the storage device 12 of the player terminal 1. When the game starts or the browser is launched, the CPU 10 stores a program (module) for controlling the browser in the program storage area 12a.

[0207] The programs that control the browser include a communication control program 90 and a multi-battle control program 91. Note that the programs listed in Fig. 14 are just examples, and many other programs are provided as programs that control the browser.

[0208] The CPU 10 runs each program stored in the program storage area 12a and updates data in each storage unit in the data storage area 12b. The CPU 10 runs each program stored in the program storage area 12a, causing the player terminal 1 (computer) to function as a terminal control unit 1A. That is, the player terminal 1 is an information processing device equipped with a terminal control unit 1A that executes the processing of various information processing programs. The terminal control unit 1A includes a communication control unit 90a and a multi-battle control unit 91a.

[0209] Specifically, the CPU 10 runs a communication control program 90, causing the computer to function as a communication control unit 90a. Similarly, the CPU 10 runs a multi-battle control program 91, causing the computer to function as a multi-battle control unit 91a.

[0210] The data storage area 12b is provided with a player information storage unit 80 as a storage unit for storing data. Note that the above-mentioned storage units are merely examples, and the data storage area 12b is provided with many other storage units.

[0211] The player information storage unit 80 stores various pieces of information related to the player, such as the player ID.

[0212] The communication control unit 90a transmits and receives information to and from the server 100. For example, the communication control unit 90a transmits predetermined operation information based on an operation by a player to the server 100, and receives information from the server 100 in response to the transmitted operation information.

[0213] The multi-battle control unit 91a cooperates with the server 100 to control the execution of the multi-battle in response to the player's operation or the progress of the game. For example, the multi-battle control unit 91a displays an image based on information received from the server 100 on the display 26. In other words, the multi-battle control unit 91a executes a multiplayer game of a content ID selected by a player.

[0214] (Functional part of server 100) Fig. 15 is a functional block diagram of the server 100. The storage device 112 of the server 100 is provided with a program storage area 112a and a data storage area 112b. The program storage area 112a stores a game execution control program 130 and a communication control program 131. Note that the programs listed in Fig. 15 are merely examples, and many other programs are stored in the program storage area 112a.

[0215] The CPU 110 runs each program stored in the program storage area 112a and updates data in each storage unit in the data storage area 112b. The CPU 110 runs each program stored in the program storage area 112a, causing the server 100 (computer) to function as a server control unit 100A. That is, the server 100 is an information processing device equipped with a server control unit 100A that executes the processing of various information processing programs. The server control unit 100A includes a game execution control unit 130a and a communication control unit 131a.

[0216] Specifically, the CPU 110 runs a game execution control program 130 and causes the computer to function as a game execution control unit 130a. Similarly, the CPU 110 runs a communication control program 131 and causes the computer to function as a communication control unit 131a.

[0217] The data storage area 112b is provided with a game information storage unit 180 and a player information storage unit 181 as storage units for storing data. Note that the above-mentioned storage units are merely examples, and the data storage area 112b is provided with many other storage units.

[0218] In the game information storage unit 180, various information related to the progress of the game, such as the progress status of the game, is stored for each multi-battle. In addition, the game information storage unit 180 is provided with a plurality of storage areas each including a waiting information storage unit and a completion information storage unit. Each storage area is assigned to each multi-battle. A multi-battle ID is assigned to each multi-battle. Therefore, the storage area of ​​the game information storage unit 180 is linked to the multi-battle ID. In addition, the game information storage unit 180 is provided with a storage unit for storing the utility ID of the combination source, which is waiting information, for each player. This storage unit is linked to the player ID of the player participating in the multi-battle.

[0219] In the player information storage unit 181, various pieces of information related to the player are stored for each player (player ID). It is remembered.

[0220] The game execution control unit 130a controls the progress of the entire game. For example, the game execution control unit 130a updates the game information of the entire game based on reception of various information indicating the input operation of the player to the player terminal 1. Furthermore, when the game information of the entire game is updated, the game execution control unit 130a generates display information based on the updated game information and causes the player terminal 1 to receive the display information via the communication control unit 131a.

[0221] Furthermore, the game execution control unit 130a controls the execution of the multi-battle in cooperation with the multi-battle control unit 91a of the player terminal 1. For example, the game execution control unit 130a allows the player to participate in a multi-player game corresponding to game information selected by the player from among game information acquired by the player.

[0222] The communication control unit 131a transmits and receives information to and from the player terminal 1. For example, the communication control unit 131a receives, from the player terminal 1, predetermined request information based on an operation of a player, and causes the player terminal 1 to receive display information generated based on the received information.

[0223] (Communication processing between player terminal 1 and server 100) Among the communication processes between the player terminals 1 and the server 100, the processes relating to the above-mentioned multi-battle will be described below.

[0224] 16 is a sequence diagram for explaining the processing of the player terminal 1 and the server 100. In the following explanation, the processing in the player terminal 1 is indicated as Pn (n is an arbitrary integer), and the processing in the server 100 is indicated as Sn (n is an arbitrary integer).

[0225] 16, when a multi-battle start operation is input, the communication control unit 90a of the player terminal 1 transmits multi-battle start request information to the server 100 (P1). The multi-battle start request information includes player identification information, content identification information, multi-battle type identification information, etc.

[0226] When the game execution control unit 130a of the server 100 receives the multi-battle start request information via the communication control unit 131a, it executes a start setting process for making various start settings related to the multi-battle (S1). For example, the game execution control unit 130a performs settings for the enemy character 51b in the multi-battle specified by the content identification information in the multi-battle start request information, initial settings for the HP value of the enemy character 51b, settings for special actions of the enemy character 51b, and the like.

[0227] Next, the game execution control unit 130a executes a battle screen information generation process to generate battle screen information for displaying a battle screen (S2). Here, the game execution control unit 130a causes the player terminal 1 to receive the generated battle screen information via the communication control unit 131a.

[0228] The game information display unit 74a of the player terminal 1 performs a battle screen display process to display a battle screen on the display 26 based on the battle screen information received via the communication control unit 90a (P2). After that, the multi-battle control unit 91a of the player terminal 1 performs a terminal-side battle execution process to execute a multi-battle by communicating with the server 100 based on the player's input operation on the battle screen (P3).

[0229] In addition, the game execution control unit 130a of the server 100 performs a server-side battle execution process for executing a multi-battle based on the operation information received from the player terminal 1 (S10). This server-side battle execution process will be described later. Although a detailed explanation will be omitted, during the terminal-side battle execution process and the server-side battle execution process, the server 100 performs a process for allowing other players to participate in the multi-battle in response to requests from other players.

[0230] Then, when the end condition of the multi-battle is met, the game execution control unit 130a of the server 100 performs a battle game end process to end the multi-battle (S11). At this time, the game execution control unit 130a causes the player terminal 1 to receive battle game end information to end the multi-battle via the communication control unit 131a. The game execution control unit 130a also updates the player information based on the game result information of the ended multi-battle. The multi-battle control unit 91a of the player terminal 1 performs a battle game end process to end the multi-battle based on the battle game end information received via the communication control unit 131a (P4).

[0231] FIG. 17 is a first flowchart for explaining the server-side battle execution process. FIG. 18 is a second flowchart for explaining the server-side battle execution process. The game execution control unit 130a judges whether operation information corresponding to the operation of the summoning item selection tab 53b has been received from the player terminal 1 (S10-1). That is, the game execution control unit 130a judges whether the summoning item selection tab 53b has been operated. If the summoning item selection tab 53b has been operated (YES in S10-1), the game execution control unit 130a checks the waiting information and completion information stored in the storage area of ​​the game information storage unit 180 (S10-2).

[0232] Then, the game execution control unit 130a judges whether or not the summoning condition is satisfied for each summoning item (S10-3). Here, the game execution control unit 130a also judges whether or not the summoning item that satisfies the summoning condition can be combined with the most recent waiting information stored in the storage area of ​​the game information storage unit 180 as the combination source for the summoning item. Based on the judgment result of S10-3, the game execution control unit 130a generates a summoning item selection frame 70 to be displayed on the battle screen, and has the player terminal 1 receive it (S10-4). As a result, the summoning item selection frame 70 is displayed on the player terminal 1.

[0233] The game execution control unit 130a also determines whether operation information corresponding to the operation of the summoning item image has been received from the player terminal 1 (S10-5). That is, the game execution control unit 130a determines whether a selection operation to select a summoning item to be used by the player has been input in the summoning item selection frame 70. If a selection operation has been input (YES in S10-5), the game execution control unit 130a stores the utility ID linked to the selected summoning item in association with the player ID (S10-6). That is, here, the summoning item to be used and the utility to be activated are associated with the player.

[0234] The game execution control unit 130a also determines whether the player who input the selection operation does not currently possess the combination right (S10-7). If the player does not possess the combination right (YES in S10-7), the game execution control unit 130a checks the waiting information and completion information in the storage area of ​​the game information storage unit 180 (S10-8). Then, the game execution control unit 130a determines whether the player can acquire the combination right based on the summon item selected by the player and the most recent waiting information and completion information checked in S10-8 (S10-9).

[0235] If the player is eligible to acquire the combination right (YES in S10-10), the game execution control unit 130a stores the utility ID of the most recent waiting information in association with the player ID of the player (S10-11). The game execution control unit 130a also updates the most recent completion information from "0" to "1" (S10-12). The game execution control unit 130a also generates a summoning information dialogue 71 based on the processing results from S10-6 to S10-12, and has the player terminal 1 receive it (S10-13). As a result, the summoning information dialogue 71 is displayed on the player terminal 1.

[0236] If the player does not have the fusion right, the summoning information dialogue 71 is generated in S10-13 so that the summoning information display field 71a, the cancel button 71b, and the activation button 71c are displayed, and the fusion information display field 71d and the fusion release button 71e are hidden. On the other hand, if the player has the fusion right, the summoning information dialogue 71 is generated in S10-13 so that the summoning information display field 71a, the cancel button 71b, the activation button 71c, the fusion information display field 71d, and the fusion release button 71e are displayed.

[0237] Also, as shown in FIG. 18, the game execution control unit 130a judges whether operation information corresponding to the operation of the combination release button 71e has been received from the player terminal 1 (S10-21). That is, the game execution control unit 130a judges whether a discard operation to discard the combination right has been input in the summoning information dialogue 71. If a discard operation has been input (YES in S10-21), the game execution control unit 130a erases the waiting information linked to the player ID in S10-11, i.e., the utility ID of the combination source (S10-22). That is, here, the waiting information linked to the player or information corresponding to the waiting information is discarded. In other words, the utility of the combination source, i.e., the special utility, is discarded based on the input of the discard operation by the player.

[0238] The game execution control unit 130a also judges whether operation information corresponding to the operation of the activation button 71c has been received from the player terminal 1 (S10-23). ​​That is, the game execution control unit 130a judges whether an activation operation for activating a utility using a summoning item has been input in the summoning information dialogue 71. If an activation operation has been input (YES in S10-23), the game execution control unit 130a performs processing for executing a summoning action (S10-24). Here, the utility is activated based on the utility ID associated with the player ID and stored. Also, when the fusion right is used, the game execution control unit 130a activates a special utility based on the input of the activation operation by the player. Also, for example, calculation of the damage value to be inflicted on the enemy character 51b, derivation of the number of turns required until the used summoning item can be used again, etc. are executed.

[0239] In addition, the game execution control unit 130a generates a performance image corresponding to the summoning action and causes the player terminal 1 to receive it. Here, a game image corresponding to a utility activated by the use of the summoning item is displayed. At this time, if the fusion right is not used, one game image is displayed as shown in FIG. 11A and FIG. 11B. On the other hand, if the fusion right is used, two game images are displayed as shown in FIG. 11C. That is, here, a process is executed to display a first image corresponding to the first utility and a second image corresponding to the second utility on the player terminal 1 based on the activation of the special utility.

[0240] The game execution control unit 130a erases the utility ID that was associated with the player ID and stored in S10-6 and S10-11 (S10-26). That is, the process of activating the special utility includes a process of discarding the waiting information associated with the player or information corresponding to the waiting information.

[0241] The game execution control unit 130a also determines whether the combination standby permission information of the summon item used by the player is "enabled" (S10-27). If the combination standby permission information is "enabled" (YES in S10-27), the game execution control unit 130a stores the utility ID of the summon item used as standby information in a storage area of ​​the game information storage unit 180 (S10-28). At this time, the game execution control unit 130a stores "0" as completion information.

[0242] The storage area of ​​the game information storage unit 180 is allocated for each multi-battle. That is, the storage area of ​​the game information storage unit 180 is linked to a multi-battle ID set for each multi-battle. Therefore, the process of S10-28 can be said to be a process of linking waiting information to a multi-battle.

[0243] Furthermore, if there is any other operational input that progresses the multi-battle (YES in S10-29), the game execution control unit 130a executes a process for progressing the game based on the operational input (S10-30).

[0244] Although one aspect of the embodiment has been described above with reference to the accompanying drawings, it goes without saying that the present invention is not limited to the above embodiment. It is clear that a person skilled in the art can come up with various modified or revised examples within the scope of the claims, and it is understood that these also naturally belong to the technical scope.

[0245] In the above embodiment, a case has been described where the player terminal 1 is a smartphone. However, the player terminal 1 is not limited to a smartphone, and may be any computer such as a personal computer.

[0246] The game content in the above embodiment is merely an example. The game genre to which the above technical matters can be applied is not particularly limited. For example, the above technical matters can be applied to all game genres, such as RPG, action games, puzzle games, training games, and sports games.

[0247] In the above embodiment, the waiting information is enabled or disabled depending on the completion information stored in the storage area of ​​the game information storage unit 180. Specifically, when a summoning item is used and a utility is activated, the waiting information is stored in the storage area of ​​the game information storage unit 180, and "0" is stored as the completion information. In this way, by storing a flag of "0" as the completion information, the waiting information stored in the storage area of ​​the game information storage unit 180 is enabled. Furthermore, by updating the completion information from "0" to "1", the waiting information stored in the storage area of ​​the game information storage unit 180 is disabled.

[0248] However, the method of activating and deactivating the waiting information is not limited to this. Completion information is not required, and for example, the waiting information is activated by storing the waiting information in the waiting information storage unit. Then, when another player acquires the right to combine thereafter, the waiting information stored in the waiting information storage unit is erased. In this case, the waiting information may be stored in only one storage area. Then, in this case, the waiting information is activated by the process of storing the waiting information in the waiting information storage unit, and the waiting information is invalidated by the process of erasing the waiting information from the waiting information storage unit.

[0249] As described above, the storage area of ​​the game information storage unit 180 in which the waiting information is stored is linked to the multi-battle ID. Therefore, in this example, the process of invalidating the waiting information can be said to be a process of releasing the link between the multiplayer game and the waiting information. In this way, the process of validating or invalidating the waiting information can be appropriately modified.

[0250] In the above embodiment, the special utility activated by the fusion of summoned items is composed of a utility linked to the summoned item selected by the player and a utility linked to the summoned item most recently used by another player. However, the content of the special utility is not limited to this. For example, suppose that after another player activates a first utility, the player selects a summoned item that activates a second utility.

[0251] In this case, in the above embodiment, the first utility and the second utility become the special utility. However, for example, the special utility may be determined by a combination of the first utility and the second utility. As an example, depending on the type of the first utility, some or all of the content, parameters, etc. of the second utility change. In this case, the changed second utility becomes the special utility.

[0252] Also, in the above embodiment, a case where two summoned items are combined has been described. However, for example, in the above embodiment, two abilities may be combined. In this case, for example, when an ability is selected, the most recent ability activated by another player may be combined with the selected ability. Also, for example, when a summoned item is selected, the most recent ability activated by another player may be combined with the selected summoned item. In any case, the two game media to be combined may be those that are linked to some utility, and are not particularly limited.

[0253] In the above embodiment, a case has been described in which a player can acquire the right to combine using a summoning item that the player used earlier as the source of the combination. However, the source of the summoning item (utility) that allows the player to acquire the right to combine may be limited to summoning items whose utility has been activated by a player other than the player. In this case, the waiting information may include the player ID of the player who used the summoning item.

[0254] For example, when any player selects a summoning item, it is confirmed whether or not there is waiting information in the server 100. At this time, it is determined whether the player ID in the waiting information most recently stored in the server 100 is different from the player ID of the player who selected the summoning item. Then, if the player IDs are different, the completion information is updated to "1" as in the above embodiment, and the player who selected the summoning item is granted the right to combine.

[0255] In the above embodiment, there are summoned items that cannot be combined, i.e., summoned items whose combination waiting permission information is "not allowed." However, it is also possible that all summoned items can be combined with at least one summoned item.

[0256] In the above embodiment, each summoned item is set with a summoned item that can be used as a combination source. However, a summoned item that can be combined may be combined with any summoned item, regardless of the type of the combined source summoned item. In other words, only information on whether or not a summoned item can be combined may be linked to the summoned item, and when a summoned item that can be combined is used, standby information may be stored. When a summoned item is selected, the right to combine may be granted to the player who selected the summoned item, regardless of the type of summoned item most recently used and the type of summoned item selected.

[0257] In the above embodiment, the suggestion image 72 is superimposed on the item image corresponding to the summoning item that can be combined. That is, the suggestion image 72 is displayed on a screen for selecting a summoning item. However, the suggestion image 72 may be displayed on a screen other than the screen for selecting a summoning item. For example, the suggestion image 72 may be displayed on the summoning item selection tab 53b shown in FIG. 6C.

[0258] In the above embodiment, the acquired combination right is reserved across turns. However, if the combination right is not used in the turn, it may be lost at the end of the turn. In other words, the combination right may be reserved only during the turn in which the combination right is acquired. In any case, the information processing system S includes one or more computers, and the computers perform the following processes.

[0259] (Computer-Performed Processing) In a multiplayer game in which multiple players can participate (in the embodiments, a multi-battle is taken as an example), a process (in the embodiments, S10-24 is taken as an example) of activating a first utility based on a first operation (in the embodiments, operation of activation button 71c is taken as an example) input by a first player. A process (S10-28 as an example in the embodiment) of validating predetermined standby information (a utility ID as an example in the embodiment) based on the input of a first operation or activation of a first utility. When the standby information is enabled, a process (S10-11 is an example of an embodiment) in which a predetermined utility is added to a pre-established second utility or a special utility changed from the second utility is determined as an activateable utility based on a predetermined operation (in an embodiment, an operation on a summoned item image is an example of an embodiment) input by the second player. A process of invalidating standby information based on input of a predetermined operation or determination of a special utility (S10-12 in the embodiment as an example). A process (S10-13 in the embodiment) that allows the second player to select one of a plurality of operations including at least an activation operation for activating the determined special utility and a discard operation for discarding the determined special utility. A process of activating a special utility based on an activation operation input by the second player (S10-24 in the embodiment as an example). A process of discarding the special utility based on a discard operation input by the second player (S10-22 in the embodiment as an example).

[0260] Furthermore, the multiple operations selectable by the second player may include an operation for progressing the multiplayer game while reserving activation of a special effect. However, in the above embodiment, the fusion right may not be reserved. For example, when the fusion right is acquired, the summoning information dialog 71 shown in FIG. 10B is displayed. When the cancel button 71b is operated, the summoning information dialog 71 is closed, and at this time, the fusion right may be discarded by operating the cancel button 71b.

[0261] The predetermined operation may be an operation to select a second utility to be activated in the multiplayer game from among a plurality of second utilities (an operation on a summon item image is an example in the embodiment). However, the predetermined operation may be, for example, an operation on the summon item selection tab 53b in the above embodiment. In this case, for example, information on the utility of the fusion source to be additionally activated may be displayed first.

[0262] In addition, based on the activation of a special utility, a process (S10-25 in the embodiment) may be executed to display a first image (game image 80) corresponding to the first utility and a second image (game image 81) corresponding to the second utility.

[0263] Furthermore, the process of validating the waiting information may include a process of linking the waiting information to the multiplayer game. Furthermore, the process of invalidating the waiting information may include a process of releasing the association between the multiplayer game and the waiting information. Furthermore, the process of determining the special utility may include a process of linking the waiting information or information corresponding to the waiting information to the second player. Furthermore, the process of activating the special utility and the process of discarding the special utility may include a process of discarding waiting information linked to the second player or information corresponding to the waiting information.

[0264] In the above embodiment, the information processing system S, which is a client-server system, performs each of the above information processes. However, the function of the server 100 in the above embodiment may be provided in the player terminal 1. Also, the function of the player terminal 1 in the above embodiment may be provided in the server 100. In other words, each of the above processes may be performed by either the player terminal 1 or the server 100.

[0265] The program in the above embodiment may be stored in a non-transitory storage medium readable by a computer and provided as a storage medium. Furthermore, the program may be provided as a game terminal device or an information processing system including the storage medium. The above embodiment may also be an information processing method for implementing each function and step shown in the flowchart. [Explanation of symbols]

[0266] 1 Player terminal 100 Servers S Information Processing System

Claims

1. A process for activating a first utility based on a first operation input by a first player in a multiplayer game in which a plurality of players can participate; a process of validating predetermined standby information based on the input of the first operation or the activation of the first utility; a process of determining, when the standby information is enabled, a special utility obtained by adding a predetermined utility to a second utility provided in advance or changing the second utility, as an exercisable utility, based on a predetermined operation input by a second player; a process of invalidating the standby information based on the input of the predetermined operation or the determination of the special utility; a process of allowing the second player to select one of a plurality of operations including at least an activation operation for activating the determined special utility and a discard operation for discarding the determined special utility; a process of activating the special utility based on the input of the activation operation by the second player; discarding the special utility based on the input of the discard operation by the second player; The computer executes the following: Information processing program.

2. the plurality of operations selectable by the second player include an operation of progressing the multiplayer game while suspending activation of the special effect; The information processing program according to claim 1 .

3. The predetermined operation is an operation of selecting the second utility to be activated in the multiplayer game from among a plurality of the second utilities; 3. The information processing program according to claim 1 or 2.

4. a process of displaying a first image corresponding to the first effect and a second image corresponding to the second effect based on the activation of the special effect; Then, the computer executes the above steps.

3. The information processing program according to claim 1 or 2.

5. The process of validating the waiting information includes: a process of linking the waiting information to the multiplayer game, The process of invalidating the waiting information includes: A process of discarding the waiting information associated with the multiplayer game, The process of determining the special utility includes: a process of linking the waiting information or information corresponding to the waiting information to the second player; The process of activating the special utility and the process of discarding the special utility include: a process of discarding the waiting information or information corresponding to the waiting information associated with the second player; 3. The information processing program according to claim 1 or 2.

6. One or more computers A process for activating a first utility based on a first operation input by a first player in a multiplayer game in which a plurality of players can participate; a process of validating predetermined standby information based on the input of the first operation or the activation of the first utility; a process of determining, when the standby information is enabled, a special utility obtained by adding a predetermined utility to a second utility provided in advance or changing the second utility, as an exercisable utility, based on a predetermined operation input by a second player; a process of invalidating the standby information based on the input of the predetermined operation or the determination of the special utility; a process of allowing the second player to select one of a plurality of operations including at least an activation operation for activating the determined special utility and a discard operation for discarding the determined special utility; a process of activating the special utility based on the input of the activation operation by the second player; discarding the special utility based on the input of the discard operation by the second player; To carry out Information processing methods.

7. One or more computers; The computer, A process for activating a first utility based on a first operation input by a first player in a multiplayer game in which a plurality of players can participate; a process of validating predetermined standby information based on the input of the first operation or the activation of the first utility; a process of determining, when the standby information is enabled, a special utility obtained by adding a predetermined utility to a second utility provided in advance or changing the second utility, as an exercisable utility, based on a predetermined operation input by a second player; a process of invalidating the standby information based on the input of the predetermined operation or the determination of the special utility; a process of allowing the second player to select one of a plurality of operations including at least an activation operation for activating the determined special utility and a discard operation for discarding the determined special utility; a process of activating the special utility based on the input of the activation operation by the second player; discarding the special utility based on the input of the discard operation by the second player; An information processing system that carries out the above.

Images