JP7557027B1 - Information processing program, information processing method, and information processing system - Google Patents

Abstract

The present invention provides simplified operability for players.
[Solution] The information processing program causes a computer to perform the following processes: storing first information used in a first game, which is open to multiple players and is started by a first player, based on the operation of the first player; storing second information used in a second game, which is open to multiple players and is started by a second player, based on the operation of the first player; and executing the first game using the first information and executing the second game in which the first player participates, using the second information.
[Selection] Figure 16

Description

The present invention relates to an information processing program, an information processing method, and an information processing system.

For example, Patent Document 1 discloses a system that realizes a multiplayer game in which multiple players cooperate to play against enemy characters. In this system, a player can request the help of other players, i.e., participation, in a multiplayer game that the player has started. Therefore, a help request is sent to each player for multiplayer games in which the player can participate. The player can select the multiplayer game in which he or she wishes to participate from among the multiplayer games for which the player has received a help request.

JP 2023-30179 A

As described above, in a multiplayer game, there are cases where a player starts a multiplayer game and cases where a player joins a multiplayer game started by another player. Furthermore, a player may set different game settings when progressing through a multiplayer game depending on whether the player starts the multiplayer game or joins the multiplayer game. Furthermore, if the game settings set by the player are overwritten and saved each time a multiplayer game is cleared, the player may have to perform operations to change the game settings each time the player starts or joins a multiplayer game. As a result, there is a risk that the player's operations may become cumbersome when playing a multiplayer game.

The present invention aims to provide an information processing program, an information processing method, and an information processing system that can simplify operability for players.

In order to solve the above problem, an information processing program includes:
a process of storing first information, which is used in a first game in which a plurality of players can participate and which is started by a first player , and which associates type identification information, character identification information, and action information of the first game with each other, based on an operation of the first player;
a process of storing second information, which is used in a second game in which a plurality of players can participate and which is started by a second player , and which associates the type identification information, the character identification information, and the action information of the second game with each other , based on an operation of the first player;
a process of executing the first game using the first information, and executing the second game in which the first player participates using the second information;
The computer is made to carry out the above steps.

A plurality of types of games are provided, each associated with a different content ID;
The first game and the second game may include a game with the same content ID.

The first information and the second information are
The information may include information for designating a target item of a manual mode in which the first player manually selects an action of the character, and information for designating a target item of an auto mode in which at least some of the actions of the character are automatically selected.

a plurality of abilities executable by the character in the first game and the second game are set;
The information specifying the target items of the auto mode may include information specifying whether or not each ability of the character is to be automatically executed.

In order to solve the above problem, an information processing method includes:
One or more computers
a process of storing first information, which is used in a first game in which a plurality of players can participate and which is started by a first player , and which associates type identification information, character identification information, and action information of the first game with each other, based on an operation of the first player;
a process of storing second information, which is used in a second game in which a plurality of players can participate and which is started by a second player , and which associates the type identification information, the character identification information, and the action information of the second game with each other , based on an operation of the first player;
a process of executing the first game using the first information, and executing the second game in which the first player participates using the second information;
Carry out the following.

In order to solve the above problem, an information processing system includes:
One or more computers;
The computer,
a process of storing first information, which is used in a first game in which a plurality of players can participate and which is started by a first player , and which associates type identification information, character identification information, and action information of the first game with each other, based on an operation of the first player;
a process of storing second information, which is used in a second game in which a plurality of players can participate and which is started by a second player , and which associates the type identification information, the character identification information, and the action information of the second game with each other , based on an operation of the first player;
a process of executing the first game using the first information, and executing the second game in which the first player participates using the second information;
Carry out the following.

The present invention makes it possible to simplify operability for players.

FIG. 1 is an explanatory diagram showing a schematic configuration of an information processing system. 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. 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. 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. 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. Fig. 6A is a first diagram for explaining an example of a rescue search screen, Fig. 6B is a second diagram for explaining an example of a rescue search screen, and Fig. 6C is a third diagram for explaining an example of a rescue search screen. Fig. 7A is a diagram showing an example of a rescue request screen, Fig. 7B is a diagram showing an example of a rescue request completion screen, Fig. 7C is a diagram showing an example of a battle screen, and Fig. 7D is a diagram showing an example of an action screen. Fig. 8A is a diagram illustrating an example of an ability selection frame. Fig. 8B is a diagram illustrating an example of an animation when an ability is used. Fig. 8C is a diagram illustrating a state when an ability action has ended. Fig. 8D is a diagram illustrating an example of an animation when a reserved ability action is started. Fig. 9A is a diagram of a battle screen for explaining the normal auto mode, and Fig. 9B is a diagram of a battle screen for explaining the full auto mode. Fig. 10A is a diagram illustrating a battle menu screen, and Fig. 10B is a diagram illustrating an ability setting screen. FIG. 11 is a diagram illustrating an example of ability information of an ally character. FIG. 12 is a diagram for explaining the first information used in the first game. FIG. 13 is a diagram for explaining the second information used in the second game. FIG. 14 is a functional block diagram of a player terminal. FIG. 15 is a functional block diagram of the server. FIG. 16 is a sequence diagram illustrating the processing of the player terminal and the server.

One embodiment of the present invention will be described in detail below with reference to the attached drawings. The numerical values and other information shown in the embodiment are merely examples for ease of 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 illustrated.

(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.

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.

The server 100 is connected for communication with multiple 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.

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 provides a wireless or wired communication connection between the player terminal 1 and the server 100.

In the information processing system S of this embodiment, the player terminal 1 and the server 100 function as the game device G. The player terminal 1 and the server 100 are each assigned the role of controlling the progress of the game, and the game can progress through cooperation between the player terminal 1 and the server 100.

The 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 the player's input operation 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 the 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 game progress control is executed by the player terminal 1.

(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 is configured to include 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.

As shown in FIG. 2B, the server 100 is also configured to include 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.

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, respectively. Therefore, the following describes the hardware configuration of the player terminal 1, and a description of the server 100 is omitted.

The CPU 10 runs the programs stored in the storage device 12 and controls 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 the programs and various data required to control the progress of the game. The storage device 12 is connected to the CPU 10 via a bus 14.

An input/output interface 16 is connected to the bus 14. A memory unit 18, a communication unit 20, an input unit 22, and an output unit 24 are connected to the input/output interface 16.

The storage unit 18 is composed of 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 into the storage device 12 (RAM) by the CPU 10.

The communication unit 20 is wirelessly connected to the communication base station Na, 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 programs or data received from the server 100 are stored in the storage device 12 or the storage unit 18.

The input unit 22 is composed of, for example, a touch panel, buttons, a keyboard, a mouse, a cross key, an analog controller, etc., through which the player's operations are input (which accepts operations). 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 tilt 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 intentions in an identifiable manner.

The output unit 24 includes a display device and a speaker. The output unit 24 may be a device that is 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.

(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 will be referred to as ally characters.

The game includes various quests. 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 is described in detail below.

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 begins. When the game begins, the My Page screen shown in Fig. 3A is displayed on the display 26 of the player terminal 1. The My Page screen has multiple 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.

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 has a My Page tab 30a labeled "My Page," a reload tab 30b labeled "Reload," and a back tab 30c labeled "Back."

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.

As shown in FIG. 3A, a menu tab 31a labeled "Menu" is displayed in the upper right corner 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.

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

When the formation tab 32a is operated, a formation screen (not shown) is displayed. On the formation screen, the player can form a party to be used in quest battles. A party is formed of main members, who are starting members in battle, and sub-members, who are substitutes. The main members are formed of a total of four characters, the main character and three sub-characters. The sub-members are formed of two sub-characters. In a battle, if one of the main member characters becomes unable to fight, a sub-character will be added to the battle from the sub-members. Note that the party formation is not limited to this example, and any formation may be used. The player can also equip the main character with a weapon on the formation screen.

When the strengthening tab 32b is operated, a strengthening screen (not shown) is displayed. On the strengthening screen, the player can strengthen the weapons they possess according to certain rules.

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 spending in-game currency. Furthermore, when a specific type of weapon is acquired for the first time, a sub-character corresponding to that specific type of weapon can be acquired. The acquired sub-character can then be organized into a party.

As will be described later, one type of quest is a multi-battle quest (hereinafter, 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, that is, 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 with different difficulty levels (quests with common settings other than difficulty). However, a common content ID may be linked to the same quests 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 multiplayer game in which multiple players can participate. For example, assume that 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).

The second player can receive a rescue request from the first player and later join the multi-battle started by the first player. Note that a player who starts a new multi-battle is sometimes called the discoverer, and a player who joins later is sometimes called the rescuer. The number of people who can join together in a multi-battle (discoverer + rescuer) is limited to a certain number (e.g., 30 people). Thus, in a multi-battle, there is a first game in which a player (first player) starts a multi-battle, and a second game in which a player (first player) participates in a multi-battle started by another player (second player). Below, a multi-battle started by a player is also simply referred to as a first game. Also, a multi-battle started by another player and in which the player participates is also simply referred to as a second game.

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 specified items.

When the quest tab 32d is operated, the 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 the quests that can be executed.

Quests include main quests related to the progress of the main story, freely set free quests, and the above-mentioned multi-battles. 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 down the quest list screen.

In the example of FIG. 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.

As shown in FIG. 3B, the quest list screen also displays a multi-battle tab 34 labeled "Multi-battle." The multi-battle tab 34 is located, for example, above the top quest selection tab 33 on the screen.

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

The rescue request list screen has a new tab 35a and a rescue search tab 35b. The new tab 35a and the rescue search tab 35b function as operation units that accept operations by the player. When the new 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.

On the rescue request list screen, a game information display area 35c is provided below the new arrivals tab 35a and rescue search tab 35b. At the top of the game information display area 35c, a multi-battle tab 35c1 and an event tab 35c2 are provided.

Game information display area 35c displays game information indicating multi-battles that have been started by other players and in which the player can participate. The game information includes various information related to the multi-battle. Note that in the example of FIG. 4A, no game information is displayed in game information display area 35c, indicating that there are no multi-battles in which the player can participate.

Multi-battles are broadly divided into normal multi-battles that players can play at any time, and event multi-battles that are only offered during event periods. 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.

In addition, on the rescue request list screen, the new arrivals tab 35a is highlighted more than the rescue search tab 35b, making it possible to identify that the new arrivals tab 35a is selected. In addition, while the rescue request list screen is displayed, the currently selected tab is highlighted, either the multi-battle tab 35c1 or the event tab 35c2.

Also, as shown in FIG. 4A, the rescue request list screen has an ID input button 35d. 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 linked to the initiated multi-battle is obtained. Each player can also participate in a multi-battle by directly inputting a multi-battle ID into the ID input screen.

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."

When the normal selection tab 36b is operated, a difficulty 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 selection tab 36d for multi-battles classified as the high level class is displayed. In the example of FIG. 4B, the difficulty selection tab 36d for the normal class is displayed. In the high level class, enemy characters are set to be 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.

When the difficulty level selection tab 36d is operated, the multi-battle selection screen shown in FIG. 4C is displayed. The multi-battle selection screen is displayed with the content corresponding to the difficulty level selected by the operated difficulty level selection tab 36d.

As shown in FIG. 4C, a multi-battle selection tab 37a is displayed on the multi-battle selection screen. The multi-battle selection tabs 37a are displayed for each type of multi-battle. In addition, a multi-battle challenge tab 37b marked "Challenge" is displayed for each multi-battle selection tab 37a on the multi-battle selection screen. 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, a cancel tab 37c marked "Close" is displayed on the multi-battle selection screen. When the cancel tab 37c is operated, the user can return to the multi-battle list screen.

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

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

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.

Also, as shown in FIG. 5B, when a rescue request is received from another player, the frame of the multi-battle tab 34 marked "multi-battle" is highlighted on the quest list screen so that it can be distinguished from when there is no rescue request.

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.

Here, the game information displayed in the multi-battle participation tab 39 includes 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 enemy character's remaining HP at the time of the rescue request, and the BP required to participate. 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 friendly or enemy characters. Also, for example, the remaining HP of the enemy character may be displayed as changing in real time in the multi-battle participation tab 39.

When the multi-battle participation tab 39 is operated, the player can participate as a rescuer in a 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.

In this embodiment, a rescue search setting function is provided that allows each player to set in advance the rescue requests they would like to receive. The rescue search setting function is described in detail below.

Figure 6A is a first diagram illustrating an example of a rescue search screen. Figure 6B is a second diagram illustrating an example of a rescue search screen. Figure 6C is a third diagram illustrating an example of a rescue search screen. When the rescue search tab 35b is operated on the rescue request list screen, the rescue search screen shown in Figure 6A is displayed. On the rescue search screen, similar to the rescue request list screen, a new tab 35a, a rescue search tab 35b, a game information display area 35c, an ID input button 35d, and a multi-battle list button 35e are displayed.

However, instead of the multi-battle tab 35c1 and event tab 35c2 displayed on the rescue request list screen, the rescue search screen displays a first setting tab 35b1, a second setting tab 35b2, a third setting tab 35b3, and a search setting button 35f. Each player can set three patterns of search conditions for rescue requests in advance. Hereinafter, the search condition patterns will be referred to as search patterns. Once the search conditions are set, rescue requests are searched for according to the set search conditions. Then, once rescue requests that match the search conditions are extracted, the extracted rescue requests are displayed on the rescue search screen for each search pattern.

When the first setting tab 35b1 is operated on the rescue search screen, a list of multi-battle participation tabs 39 corresponding to multi-battles that match the first search pattern, i.e., the first search conditions, is displayed. Similarly, when the second setting tab 35b2 is operated, a list of multi-battle participation tabs 39 corresponding to multi-battles that match the second search conditions is displayed, as shown in FIG. 6B. Furthermore, when the third setting tab 35b3 is operated, a list of multi-battle participation tabs 39 corresponding to multi-battles that match the third search conditions is displayed, as shown in FIG. 6C.

The player can participate in a multi-battle as a rescuer in the same manner as described above by operating the multi-battle participation tab 39 displayed on the rescue search screen. Note that if a search pattern for which no content IDs are set is selected, the multi-battle participation tab 39 will not be displayed, and a message will be displayed indicating that no search conditions have been set, as shown in FIG. 6C.

In addition, an individual reload button 35g is provided in the game information display area 35c. When the individual reload button 35g is operated, an extraction request corresponding to the currently selected tab among the first setting tab 35b1, the second setting tab 35b2, and the third setting tab 35b3 is sent to the server 100. In other words, when the player operates the individual reload button 35g, a multi-battle participation tab 39 corresponding to the latest battle game that matches the currently selected search criteria is displayed.

Furthermore, when the reload tab 30b of the frame bar 30 is operated, the multi-battle participation tab 39 is updated. When the reload tab 30b is operated, a request to extract multi-battles that match the three search conditions may be sent. Alternatively, similar to the individual reload button 35g, only a request to extract multi-battles that match the currently selected search conditions may be sent.

A campaign period may also be set separately from the event period. During the campaign period, the AP or BP required to play the campaign quest will decrease, and the rewards will increase. During the campaign period, the campaign icon 35h will be displayed in the multi-battle participation tab 39 of the campaign quest, as shown in FIG. 6A. Next, an example of a case where a multi-battle is played as the discoverer will be described.

Fig. 7A is a diagram showing an example of a rescue request screen. Fig. 7B is a diagram showing an example of a rescue request completion screen. Fig. 7C is a diagram showing an example of a battle screen. Fig. 7D is a diagram showing an example of an action screen. When the quest selection tab 33a indicating a multi-battle on the quest list screen shown in Fig. 3B is operated, or the multi-battle challenge tab 37b on the multi-battle selection screen shown in Fig. 4C is operated, the battle screen shown in Fig. 7C is displayed. Immediately after the battle screen is displayed, it switches to the rescue request screen shown in Fig. 7A. On the rescue request screen, the player can set the range of players to issue rescue requests.

As shown in FIG. 7A, 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."

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 or 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 player's 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 take on quests.

When the global selection checkbox 50a is operated, the global selection check can be switched on and off. When the rescue request sending tab 50d is operated while the global selection checkbox 50a is in the on state, players for whom search conditions are set that include the content ID linked to the started multi-battle are randomly selected from all players. A rescue request is then sent to the selected player. In this case, the randomly selected player can participate in the started multi-battle.

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.

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

Note that here, if a friend is selected as the recipient of the rescue request, the rescue request is sent regardless of the search conditions set by 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 conditions that the player has set. If the received rescue request does not match the player's search conditions, the rescue request may be displayed on the rescue list screen shown in FIG. 5C. However, the rescue request may only be sent to players who are registered as friends and who have search conditions set that include the content ID linked to the started multi-battle.

When the guild selection checkbox 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 checkbox 50c is on, 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.

Note that here, if a guild is selected as the destination of a rescue request, the rescue request will be sent regardless of the search conditions set by 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 player's search conditions, the rescue request may be displayed on the rescue list screen shown in FIG. 5C, as described above. However, rescue requests may only be sent to players in the same guild who have search conditions set that include the content ID linked to the started multi-battle.

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

When the rescue request sending tab 50d shown in FIG. 7A is operated to complete sending the rescue request, the rescue request completion screen shown in FIG. 7B is displayed. When the OK tab 50f marked "OK" is operated on the rescue request completion screen, the screen switches to the battle screen shown in FIG. 7C.

In addition, when the cancel tab 50e shown in FIG. 7A is operated, a rescue request is not made, and the screen switches to the battle screen shown in FIG. 7C, 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.

As shown in FIG. 7A, the rescue request screen also has an SNS tab 50g. 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 world via the SNS.

Here, the SNS tab 50g is provided separately from the rescue request sending tab 50d. In other words, 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 SNS at the same time.

The method of sending a rescue request to other players using 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 SNS application 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.

As shown in FIG. 7C, ally characters 51a and enemy characters 51b are displayed in the upper half of the battle screen. When the battle begins, the main members of the party are displayed as ally characters 51a. FIG. 7C also shows an example in which there is one enemy character 51b.

Enemy characters 51b and each ally character 51a are each assigned a parameter value (e.g., HP value) related to life (or physical strength) (specifically, HP (hit points)). When the HP value of enemy character 51b decreases and reaches a predetermined limit value (e.g., 0), enemy character 51b disappears (is removed from the screen).

When all enemy characters 51b on the battle screen are eliminated, the battle is won and the quest is cleared. Clearing the quest gives the player a reward. Furthermore, when the HP value of any of the ally characters 51a reaches a predetermined limit (for example, 0), that character becomes unable to fight. A 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.

The determination of the survival or disappearance of the enemy character 51b is not limited to the HP value, and may be 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 the limit value (for example, 0%), the enemy character 51b may disappear.

The parameter related to the life of the enemy character 51b is not limited to HP, and may be, for example, the 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.

The survival or disappearance of the enemy character 51b may be determined based on a total damage ratio that indicates 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.

As shown in FIG. 7C, a normal attack tab 52 labeled "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 input indicating the player's action (e.g., attack).

The multi-battle basically progresses in a turn-based system. When the normal attack tab 52 is operated, the ally character 51a attacks the enemy character 51b, and then one turn passes as the enemy character 51b takes action. When the ally character 51a attacks the enemy character 51b, the HP value of the enemy character 51b changes based on the attack.

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 next time the normal attack tab 52 is operated, and during that time the enemy character 51b does not perform any action.

The lower half of the battle screen displays an ability selection tab 53a, a summoned beast selection tab 53b, and a recovery tab 53c labeled "Recovery." 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. Although the details of the abilities will be described later, 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 it can be activated again is set for the ability. Also, unlike input in the normal attack tab 52, when an ability is activated, the enemy character 51b does not take action at the time it is activated.

When the summoned beast selection tab 53b is operated to determine the type of summoned item to be summoned, a summoning action is initiated in which the summoned beast of the determined summoning item is summoned. When the summoning action is initiated, an attack by the summoned beast is inflicted on the enemy character 51b. The summoning action can be initiated when a specified summoning activation condition is met, such as the passage of a specified number of turns. Also, unlike input from the normal attack tab 52, the enemy character 51b will not take any action at the time the summoning action is initiated.

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 restored by the determined recovery item. Unlike input from the normal attack tab 52, recovery related to the recovery tab 53c does not result in the enemy character 51b taking an action at the time it is performed.

A contribution display area 54 is formed below the recovery tab 53c on the screen. The contribution display area 54 displays contribution information such as the contribution or ranking among one or more players in the multi-battle. If 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. Also, if 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.

As shown in FIG. 7C, the 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 percentage of the enemy character 51b. The HP gauge 55 is displayed in the form of a bar 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 edge of the HP gauge 55 on the screen corresponds to the HP percentage corresponding to the limit value (for example, 0%). In FIG. 7C, the HP gauge 55 is displayed when the HP percentage is 100%. As the HP percentage decreases, the right edge 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 HP status of the enemy character 51b.

The actions of the enemy character 51b are broadly divided into normal actions and special actions. All actions other than special actions are considered normal actions. Special actions have characteristics such as being stronger than normal actions, having a wider attack range, or having a greater number of attacks.

Special actions are 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 when a specific condition is met. 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.

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" will be displayed on the battle screen of the player terminal 1 to notify the player that a rescuer has been added.

In addition, 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, the HP gauge 55 of the enemy character 51b changes in real time based on the attack input of the second player, even if the first player has not input an attack.

In addition, in a multi-battle, when any player activates an ability, all players may enjoy the effect of that ability. For example, suppose 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 in the battle (e.g., the first player). Then, not only the second player but also the other players in the battle (e.g., the first player) can proceed with the battle with the enemy character 51b in a weakened state.

Note that 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 explained in detail below.

Figure 7D is a diagram showing an example of an action screen. The multi-battle battle game is broadly divided into a manual mode and an auto mode that can be switched. 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. Below, the battle game in the manual mode will be described first, and then the battle game in the auto mode will be described. In the battle game in the manual mode, the player can manually select the actions 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. Ability actions are executed manually by the player operating the ability selection tab 53a, or automatically by the CPU 110. Item use actions are executed manually by the player operating the recovery tab 53c. Summoning actions are executed manually by the player selecting the summon beast selection tab 53b, or automatically by the CPU 110.

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 a normal attack action, the ally characters 51a attack the enemy character 51b, thereby causing damage to the enemy character 51b. When a normal attack action is performed, as shown in FIG. 7D, 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.

Here, as a normal attack animation, an animation of the friendly character 51a attacking the enemy character 51b and the damage value inflicted on the enemy character 51b are displayed on the action screen. Note that 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 enemy character 51b's HP gauge 55 decreasing is also displayed.

When all four ally characters 51a have completed their normal attack actions, the enemy character 51b then performs a counterattack action. The enemy character 51b's counterattack action may include, for example, a normal attack action that attacks the ally character 51a to inflict damage, or a special attack action that limits the actions 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.

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.

As described above, the player can tap the normal attack tab 52 to execute a normal attack action as the action of the ally character 51a. When a normal attack action is executed, the normal attack action of the ally character 51a is executed four times, followed by the counterattack action of the enemy character 51b.

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

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. The two consecutive turns, the player's turn and the enemy turn, are collectively referred to as one turn.

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, it becomes a counterattack action section, and when the counterattack action section ends, the enemy's turn ends. This ends one turn of the battle game.

When the HP of the enemy character 51b reaches 0 during one turn of the battle game, the end condition of the battle game is met, and the battle game ends with the player's victory.

Here, each ally character 51a is preset with an ability as a special power. 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.

The abilities that affect the ally character 51a include abilities that give beneficial effects to the ally character 51a. For example, there are strengthening abilities that increase the attacking power or defensive power of the ally character 51a, and recovery abilities that restore the HP of the ally character 51a.

Abilities that affect the enemy character 51b include abilities that inflict detrimental effects on the enemy character 51b, damage abilities that inflict damage values on the enemy character 51b, and the like. An example of an ability that inflicts detrimental effects on the enemy character 51b is a weakening ability that reduces the attack power or defense power of the enemy character 51b. Weakening abilities also include abnormal status abilities that inflict abnormal status on the enemy character 51b (for example, limiting the actions of the enemy character 51b).

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 on which the ally character 51a and the enemy character 51b are positioned. The field effect ability exerts, for example, an effect that increases the attack power of both the ally character 51a and the enemy character 51b.

In the special action section, the player can activate any number of available abilities. However, each ability has usage limit conditions set, and the player can only select abilities that do not have usage limits. For example, there are abilities that have usage limit conditions that set the number of times they can be used in one battle game, abilities that are limited in use until certain activation conditions are met, and abilities that have a set number of turns before they can be used again.

In addition, during special action sections, the player can use a recovery item by tapping the recovery tab 53c. Just like when an ability is used, using this recovery item can also give the player an advantage in the battle game, such as recovering the HP value of the ally character 51a.

In addition, in the special action section, the player can activate a summoning effect by a summoning action by tapping the summoned beast selection tab 53b. In addition to weapons, the ally character 51a can be equipped with summoning items as equipment. Predetermined summoning activation conditions are set for the summoning items. When the summoning activation conditions set for the summoning items are met, the summoning effect can be activated by the player operating the summoning item equipped to the ally character 51a. By activating the summoning effect, a beneficial effect can be given to the ally character 51a, a detrimental effect can be given to the enemy character 51b, or a damage value can be given to the enemy character 51b, thereby giving the player an advantage in the battle game.

When the player wants to use an ability, he or she taps the ability selection tab 53a of one of the ally characters 51a. When the player wants to use a recovery item, he or she taps the recovery tab 53c. When the recovery tab 53c is tapped, the recovery items possessed by the player are displayed on the display 26, and the player can select one of the recovery items. When the player wants to activate a summoning effect, he or she taps the summoned beast selection tab 53b. When the summoned beast selection tab 53b is tapped, the summoned items equipped to the ally character 51a are displayed on the display 26, and the player can select one of the summoned items.

Figure 8A is a diagram illustrating an example of the 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 Figure 8A. 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.

An ability icon 56a is provided for each ability set for each ally character 51a. If an 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 the ally character 51a, etc.

Figure 8B 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 Figure 8A is tapped, a reservation action display section 57 is displayed at the top of the display 26, as shown in Figure 8B. At this time, the reservation action display section 57 displays the tapped ability icon 56a.

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 is lifted and the ability icon 56a becomes usable again, it is changed from the use restricted mode to the usable mode.

Up to 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 they are tapped. In addition, 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.

In this way, ability actions are executed in the special action section in the order in which the ability icons 56a are tapped (i.e., from the top to the bottom of the reserved action display section 57). As described below, when ability actions are executed automatically by the CPU 110 in a special action section in auto mode, they are executed automatically in order according to the priority order set for the ability actions. 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. Additionally, an action image (ability animation) corresponding to the ability action is displayed on the display 26, as shown in FIG. 8B.

Figure 8C is a diagram explaining the state when an ability action has ended. Figure 8D is a diagram explaining an example of an animation when a reserved ability action is started. When the display of the ability animation ends, as shown in Figure 8C, 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 are moved upward. In other words, the ability icon 56a corresponding to the used ability is erased as the ability animation ends.

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, as in the above, various parameters used in the battle game are changed. Also, as shown in Figure 8D, an ability animation corresponding to the ability action is displayed.

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 become hidden when the ability animation ends.

In this way, the player can manually select and execute an ability for the ally character 51a in a special action section in manual mode. When the selected ability is executed, an ability animation corresponding to the ability is displayed. Also, in a special action section, abilities can be executed consecutively by reserving multiple ability actions in the reserved action display section 57. However, even if an ability icon 56a is tapped while an 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 will be put on hold until the display of the ability animation has finished.

Note that, although the case where the ability icon 56a is tapped and an ability action is selected, reserved, and executed has been described above, 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 an item use action is executed, an item use animation is displayed.

Similarly, when the summoned beast selection tab 53b is tapped and then a summoning item is determined, a 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.

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.

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

Note that during the special action section, the player may use some or all of the available abilities, items, and summon items, or may not use any of them. When the desired abilities, items, and summon items have been used, or if there is no need to use abilities, items, or summon items, the player can end the special action section by tapping the normal attack tab 52.

Although a detailed explanation will be omitted, the player can tap the normal attack tab 52 during an ability action, an item use action, a summon action, or even when an ability, item, or summon item is reserved for use. In this case, an icon corresponding to the normal attack action is displayed in the reserved action display area 57, and the normal attack action is reserved. Then, when the normal attack action begins, the normal action section begins and the special action section ends. As described above, during 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, abilities, items, and summon items cannot be reserved.

In this embodiment, the player can set in advance between 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 not permitted state) during the special action section. When set to the reservation not permitted state, for example, when the ability icon 56a displayed in the ability selection frame 56 is tapped, an ability action is started immediately, 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.

During the battle game, a predetermined meter value (hereinafter also referred to as the ultimate 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. 7D, an ultimate activation selection tab 53d is displayed in the lower half of the screen of the display 26. The ultimate 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 ultimate activation condition for activating the ultimate 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 ultimate activation condition is not met, and it becomes impossible to activate the ultimate attack action. When the secret attack selection tab 53d is set to the ON state, it allows the ally character 51a whose secret attack condition is satisfied to perform a secret attack action, and when it is set to the OFF state, it restricts the ally character 51a whose secret attack condition is satisfied to perform a secret attack action. In the manual mode, when the secret attack selection tab 53d is set to the ON state and the normal attack tab 52 is tapped when the secret attack condition of any ally character 51a is satisfied, the attack action of the ally character 51a whose secret attack condition is satisfied becomes a secret attack action instead of a normal attack action. This secret attack action causes more damage to the enemy character 51b than a normal attack action. On the other hand, if the special attack selection tab 53d is OFF and the special attack condition of any of the ally characters 51a is met, and the normal attack tab 52 is tapped, the attack action of the ally character 51a whose special attack condition is met remains a normal attack action, and the special attack action is not activated. In other words, when the special attack selection tab 53d is OFF, the special attack action of the ally character 51a is preserved, and the meter value that has reached its maximum value is maintained. After the special attack action is activated, the meter value is reset to 0.

The special attack action can be activated by each ally character 51a individually, but can also be activated by 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 have reached 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.

As described above, in manual mode, the player can fight between friendly character 51a and enemy character 51b by manually selecting normal actions and special actions during the battle game. However, the player must manually select normal actions and special actions one by one during the battle game, making manual operations during the battle game cumbersome. Furthermore, beginners may not understand the purpose of special actions or the effective order of use, making it difficult to make effective use of special actions.

Therefore, this embodiment is equipped with an auto mode in which the CPU 110 automatically selects and executes at least some of the normal actions and special actions on behalf of the player during the battle game. The auto mode in this embodiment includes a normal auto mode and a full auto mode. Thus, the auto mode in this embodiment includes two types: a normal auto mode and a full auto mode.

In normal auto mode, special actions are not automatically selected and executed, but normal actions are executed automatically. Note that in normal auto mode, it is not possible to manually select a special action (to reserve an action in the reserved action display unit 57 described above). Therefore, if the player wishes to use a special action after selecting normal auto mode, he or she must first turn normal auto mode OFF to switch to manual mode, and then manually select the special action as described above. On the other hand, in full auto mode, both normal actions and special actions are automatically selected and executed.

Figure 9A is a diagram of a battle screen to explain normal auto mode. Figure 9B is a diagram of a battle screen to explain full auto mode. In the normal auto mode of Figure 9A, an Auto icon 58 is displayed on the battle screen. Also, in the full auto mode of Figure 9B, a Full icon 59 is displayed on the battle screen. The Auto icon 58 is configured to be switchable between an ON state and an OFF state by being operated by the player. When the Auto icon 58 is in an ON state, the normal auto mode can be set to an ON state, and when the Auto icon 58 is in an OFF state, the normal auto mode can be set to an OFF state (i.e., manual mode). Also, the Full icon 59 is configured to be switchable between an ON state and an OFF state by being operated by the player. When the Full icon 59 is ON, the full auto mode can be turned ON, and when the Full icon 59 is OFF, the full auto mode can be turned OFF (i.e., manual mode).

In this embodiment, when the battle game starts, the manual mode is set as the default, in which the above-mentioned normal actions and special actions are manually selected. In the manual mode, the player can switch from the manual mode to any auto mode (normal auto mode or full auto mode) by operating a switching icon (Auto icon 58 or Full icon 59).

When normal auto mode is set as the type of auto mode, for example, when the normal attack tab 52 is tapped as shown in FIG. 7D, an Auto icon 58 is displayed on the display 26. The Auto icon 58 shown in FIG. 7D indicates that the normal auto mode is OFF and that the display mode is manual mode. In the manual mode state shown in FIG. 7D, the player can operate (tap) the Auto icon 58.

When the Auto icon 58 is operated, the player terminal 1 executes a process to switch from manual mode to normal auto mode during the battle game. Also, when the Auto icon 58 is operated again after switching to normal auto mode, the player terminal 1 executes a process to switch from normal auto mode to manual mode.

The Auto icon 58 shown in FIG. 9A shows a display state when the normal auto mode is ON. As shown in FIG. 9A, when the normal auto mode is ON, the Auto icon 58 shown in FIG. 7D when the normal auto mode is OFF is displayed inverted. Also, when the normal auto mode is ON, the player is in a state where the normal attack tab 52 is automatically operated, and there is no need to manually operate the normal attack tab 52, so the normal attack tab 52 is hidden. However, when the normal auto mode is ON, the normal attack tab 52 may be displayed, and the normal attack tab 52 may be automatically pressed.

In normal auto mode, during the player's turn until the battle game ends, no special action is executed (i.e., the special action section is skipped), and normal actions (normal attack actions) are repeatedly and automatically selected and executed. In other words, the player can automatically execute normal actions (normal attack actions) repeatedly during the player's turn until the battle game ends by simply operating (tapping) the Auto icon 58 once. This allows the player to reduce the complexity of manual operations during the battle game. Note that when the special attack selection tab 53d is ON and the special attack conditions of the ally character 51a are met, the special attack action of the ally character 51a whose special attack conditions are met is automatically executed during the player's turn. This is common to both normal auto mode and full auto mode.

Depending on the difficulty level of the multi-battle and the training level of the ally character 51a, it may be difficult to clear the battle game in normal auto mode. In other words, it may be difficult to clear the battle game by only performing normal actions.

The auto mode function of this embodiment therefore has a full auto mode in addition to the normal auto mode. In full auto mode, in addition to normal actions, special actions can also be automatically selected and executed. In full auto mode, special actions can be executed in addition to normal actions, allowing the player to progress through the battle game with a greater advantage than in normal auto mode.

When the full auto mode is set as the type of auto mode, when the battle game starts, the Full icon 59 shown in FIG. 9B is displayed on the display 26. However, as described in FIG. 9A, the Full icon 59 may be displayed when the normal attack tab 52 is operated (tapped), similar to the Auto icon 58.

The Full icon 59, like the Auto icon 58, is operated by the player to switch from the OFF state to the ON state, or from the ON state to the OFF state. When the Full icon 59 is operated to the ON state, the player terminal 1 executes a process to switch from manual mode to full auto mode during the battle game.

The Full icon 59 shown in FIG. 9B shows a display state in which the full auto mode is ON. As in the normal auto mode ON state, in the full auto mode ON state, the player is automatically operated with the normal attack tab 52, and there is no need to manually operate the normal attack tab 52, so the normal attack tab 52 is hidden. However, in the full auto mode ON state, the normal attack tab 52 may be displayed and controlled to be automatically pressed. Also, in the full auto mode ON state, there is no need for the player to manually operate the ability icon 56a, so the ability icon 56a, the ability explanation area 56b, and the reserved action display section 57 are hidden. However, in the full auto mode, when the player manually taps the ability selection tab 53a, the ability icon 56a, the ability explanation area 56b, the reserved action display section 57, and the like are displayed, as in the manual mode described in FIG. 8A, FIG. 8B, FIG. 8C, and FIG. 8D. In full auto mode, manual selection of special actions is only accepted during the special action interval up until the start of the normal action interval; once the normal action interval begins, manual selection of special actions becomes invalid.

In full auto mode, special actions and normal actions (normal attack actions) during the player's turn are repeatedly and automatically selected and executed until the battle game ends. In this embodiment, among the special actions, ability actions are automatically selected and executed in full auto mode, but item use actions are not automatically selected or executed. In addition to ability actions, summon actions can also be executed automatically in full auto mode, as will be described in more detail below.

By simply operating (tapping) the Full icon 59 once, the player can automatically execute special actions (ability actions) and normal actions (normal attack actions) during the player's turn repeatedly until the battle game ends. This allows the player to reduce the complexity of manual operations during the battle game. Furthermore, in full auto mode, special actions are executed in addition to normal actions, making it easier to clear the battle game than in normal auto mode. A battle menu tab 53f is displayed at the top of the battle screen.

Fig. 10A is a diagram illustrating the battle menu screen. Fig. 10B is a diagram illustrating the ability setting screen. When the battle menu tab 53f is operated by the player, the battle menu screen shown in Fig. 10A is displayed on the display 26. When the formation tab 32a on the My Page screen shown in Fig. 3A is operated by the player, a formation screen (not shown) is displayed. When each ally character 51a is operated by the player on the formation screen, the ability setting screen for the ally character 51a shown in Fig. 10B is displayed on the display 26.

As shown in FIG. 10A, the battle menu screen has an AUTO button setting field. The AUTO button setting field has a normal auto mode tab 60a and a full auto mode tab 60b. The normal auto mode tab 60a is a tab for setting normal auto mode as the type of auto mode in the battle game. The full auto mode tab 60b is a tab for setting full auto mode as the type of auto mode in the battle game. When the normal auto mode tab 60a is operated by the player, normal auto mode is set as the type of auto mode, and when the full auto mode tab 60b is operated by the player, full auto mode is set as the type of auto mode. When the normal auto mode is set, an Auto icon 58 is displayed on the battle screen as shown in FIG. 9A. When the full auto mode is set, a Full icon 59 is displayed on the battle screen as shown in FIG. 9B. Note that the type of auto mode in a battle game can be set not only from the battle menu screen, but also from a menu screen (not shown) that is displayed when the player operates the menu tab 31a on the My Page screen shown in FIG. 3A.

The battle menu screen also has an auto summon setting field. The auto summon setting field has an auto summon OFF tab 61a and an auto summon ON tab 61b. In this embodiment, in full auto mode, it is possible to select whether or not to automatically execute a summon action. The auto summon items for the automatically executed summon action can be set in advance. For example, the auto summon items for the automatically executed summon action can be set on the formation screen (not shown) that is displayed when the player operates the formation tab 32a on the My Page screen shown in FIG. 3A.

The automatic summoning OFF tab 61a is a tab for setting the summoning action of a preset automatic summoning item to a state where it is not automatically executed when the summoning activation conditions are met. The automatic summoning ON tab 61b is a tab for setting the summoning action of a preset automatic summoning item to a state where it is automatically executed when the summoning activation conditions are met. When the automatic summoning OFF tab 61a is operated by the player, the summoning action of the automatic summoning item is set to a state where it is not automatically executed, and when the automatic summoning ON tab 61b is operated by the player, the summoning action of the automatic summoning item is set to a state where it is automatically executed. Note that, for example, as shown in FIG. 9B, an immediate summoning selection tab 53e is displayed in the lower half of the screen of the display 26. When the immediate summoning selection tab 53e is operated by the player when the summoning activation conditions of the automatic summoning item are met, the summoning action of the automatic summoning item can be manually activated.

As shown in FIG. 10B, the ability setting screen displays multiple ability display fields 62a corresponding to multiple abilities set for each ally character 51a. In the example shown in FIG. 10B, four ability display fields 62a are displayed on the ability setting screen. In addition, each ability display field 62a is provided with a full auto setting tab 62b.

The full auto setting tab 62b is a tab for setting ability actions that are automatically selected and executed in full auto mode. When the player operates the full auto setting tab 62b, the ability action of the ability corresponding to the ability display field 62a is switched between an ON state in which it is automatically selected and executed, and an OFF state in which it is not automatically selected or executed.

11 is a diagram for explaining an example of ability information of an ally character 51a. As shown in FIG. 11, the ability information of an ally character 51a includes character identification information, ability identification information, and ability type information. In FIG. 11, the character identification information is information about the four ally characters 51a (character 1, character 2, character 3, character 4) organized into a party. The ability information also includes information about the priority of the four ally characters 51a organized into a party. In the example shown in FIG. 11, the priority of the ally characters 51a is determined by the order of characters 1 → character 2 → character 3 → character 4, with character 1 having the highest priority and character 4 having the lowest priority. The ability identification information is information about the abilities set for each ally character 51a.

There are various types (attributes) of abilities. For example, there are various types of abilities, such as strengthening abilities, weakening abilities, damage abilities, recovery abilities, and field effect abilities. Each ability set for the ally character 51a is set to one of several types (attributes). As a result, the multiple abilities are classified into various types (attributes). Ability type information is information about the type set for each such ability.

In FIG. 11, type A in this embodiment indicates that the ability type is a recovery ability, type B indicates that the ability type is a field effect ability, type C indicates that the ability type is a strengthening ability, type D indicates that the ability type is a weakening ability, and type E indicates that the ability type is a damage ability.

When abilities are automatically executed in full auto mode, the execution (activation) of some types of abilities is restricted. This is because automatically executing some types of abilities may cause disadvantages to the player.

For example, a field effect ability may increase the attack power of both the friendly character 51a and the enemy character 51b. Therefore, if a field effect ability is automatically activated, the attack power of the enemy character 51b may be increased against the player's will, making it difficult for the player to advance in the battle game to an advantage. Therefore, field effect abilities are excluded from the list of abilities that are automatically executed in full auto mode.

In addition, if recovery abilities are automatically activated in full auto mode, there is a risk that the player will not be able to use the recovery ability at the timing they wish to use it. Furthermore, even if a recovery ability is used, it does not contribute to damage to enemy character 51b. For this reason, recovery abilities are excluded from the list of abilities that are automatically executed in full auto mode. However, this is not limited to the above, and field effect abilities and recovery abilities may be set to be executed automatically in full auto mode.

In addition, a predetermined priority is set in advance for each type of ability. For example, the priority is set higher for a type of ability that strengthens an ally character 51a than for a type of ability that affects an enemy character 51b. Specifically, the priority is set higher for strengthening abilities than for abilities that affect enemy characters 51b (weakening abilities, damage abilities).

In this embodiment, type C (strengthening abilities) shown in FIG. 11 is set to the highest priority, followed by type D (weakening abilities), and type E (damage abilities) to the lowest priority. In full auto mode, abilities to be automatically executed are selected according to the above priorities.

Using Figure 11 as an example, abilities are searched one by one in the order of Character 1 → Character 2 → Character 3 → Character 4 according to the above priority order. Specifically, the presence or absence of type C, which has the highest priority, is searched in the order of Character 1 → Character 2 → Character 3 → Character 4, and if type C is found, it is selected one by one.

When the search for type C has been completed up to character 4, the system searches for type D, which has the next highest priority after type C, in the order of character 1 → character 2 → character 3 → character 4, and if type D is found, it is selected in turn.

When the search for type D has been completed up to character 4, the system searches for type E, which has the next highest priority after type D, in the order of character 1 → character 2 → character 3 → character 4, and if type E is found, it is selected in turn.

In the example shown in FIG. 11, type C is selected one by one in the order of type C for character 1, type C for character 2, and type C for character 3. If each ally character 51a has multiple abilities (ability identification information) that correspond to type C, all of the multiple abilities that correspond to type C are selected one by one. In the example shown in FIG. 11, type C is not set for character 4, so the selection of type C ends and the selection moves on to type D, which has the next highest priority after type C. The selection of types D and E is also performed in the same manner as the selection of type C. In this way, the abilities that are automatically selected in full auto mode are automatically executed in the order they were selected.

As described above, in a multi-battle, a player (first player) may start a multi-battle, or the player (first player) may participate in a multi-battle started by another player (second player). In addition, a player may set different game settings when proceeding with a multi-battle, depending on whether the player starts the multi-battle or participates in the multi-battle. Furthermore, if the game settings set by the player are overwritten and saved each time the multi-battle is cleared, the player may have to perform an operation to change the game settings each time the player starts or participates in the multi-battle. As a result, when the player plays a multi-battle, the player's operations may become complicated. The game settings are setting information used in the game (here, the multi-battle), and are, for example, setting information referenced in the course of progressing through the game. In this embodiment, the game settings are, for example, setting information for the CPU 110 to automatically execute at least a part of the normal action and special action of the ally character 51a. However, without being limited thereto, game settings may include setting information such as input settings (for example, key configuration such as so-called button settings), game speed settings, game difficulty settings, settings related to auto mode, settings related to communication functions (chat, stamps, etc.), etc. Game settings may also include setting information such as screen resolution settings, frame rate settings, vertical synchronization settings, graphics settings, volume settings, language settings, and camera settings.

Therefore, in this embodiment, in a first game in which a player (first player) starts a multi-battle, the game setting information (player setting information) set by the player is stored in the server 100 as first information. Also, in a second game in which the player (first player) participates in a multi-battle started by another player (second player), the game setting information set by the player is stored in the server 100 as second information separate from the first information.

In this manner, in this embodiment, the game setting information (first information) used in the first game and set based on the player's operation, and the game setting information (second information) used in the second game and set based on the player's operation are stored separately in the server 100. Then, when the first game is played on the player terminal 1 after the first information is stored, the server 100 can reflect the first information used in the first game by referencing the stored first information. Similarly, when the second game is played on the player terminal 1 after the second information is stored, the server 100 can reflect the second information used in the second game by referencing the stored second information. This eliminates the need for the player to perform an operation to change the game setting information each time the first game and the second game are switched between to be played, simplifying the player's operability.

FIG. 12 is a diagram for explaining the first information used in the first game. FIG. 13 is a diagram for explaining the second information used in the second game. As shown in FIG. 12 and FIG. 13, the first information and the second information include player identification information, content identification information, multi-type identification information, auto-type identification information, auto-summon flag information, secret skill activation flag information, character identification information, ability identification information, and auto-selection flag information. The first information and the second information are associated (linked) with the player identification information, content identification information, multi-type identification information, auto-type identification information, auto-summon flag information, secret skill activation flag information, character identification information, ability identification information, and auto-selection flag information, respectively. Note that FIG. 12 and FIG. 13 show an example in which one content identification information is associated with one player identification information. However, this is not limited to this, and multiple different content identification information may be associated with one player identification information.

The player identification information is, for example, a player ID. The player ID is a unique identifier assigned to each player, and is used to individually identify each player. The content identification information is, for example, a content ID. The content ID is a unique identifier assigned to each multi-battle, and is used to individually identify each multi-battle.

The multi-battle type identification information is used to identify whether the multi-battle played by the player corresponds to the first game or the second game. In Figs. 12 and 13, "first" represents the first game, and "second" represents the second game. In the example shown in Fig. 12, the multi-battle type identification information includes information indicating that the multi-battle played by the player corresponds to the first game, with "o" next to "first" and "x" next to "second." In addition, in the example shown in Fig. 13, the multi-battle type identification information includes information indicating that the multi-battle played by the player corresponds to the second game, with "x" next to "first" and "o" next to "second."

The auto type identification information is for identifying the type of auto mode in the battle game. In this embodiment, the auto type identification information is set in response to the player's operation of the normal auto mode tab 60a and the full auto mode tab 60b. In Figures 12 and 13, "Full" represents full auto mode, and "Normal" represents normal auto mode. In the example shown in Figures 12 and 13, the auto type identification information indicates that "ON" is displayed for "Full" and "OFF" is displayed for "Normal", and includes information indicating that the type of auto mode is full auto mode. Conversely, if "OFF" is displayed for "Full" and "ON" is displayed for "Normal", the auto type identification information includes information indicating that the type of auto mode is normal auto mode.

The automatic summon flag information is flag information for determining whether or not the summon action of a preset automatic summon item is automatically executed when the summon activation conditions are met. The automatic summon flag information is set according to the operation of the automatic summon OFF tab 61a or the automatic summon ON tab 61b by the player. In the example shown in FIG. 12 and FIG. 13, the automatic summon flag information is set to "OFF" when the automatic summon OFF tab 61a is operated by the player and the summon action of the automatic summon item is set to a state in which it is not automatically executed. When the automatic summon flag information is in the "OFF" state, the summon action of the automatic summon item can be manually executed by the player operating the immediate summon selection tab 53e when the summon activation conditions of the automatic summon item are met. In addition, the automatic summon flag information is set to "ON" when the automatic summon ON tab 61b is operated by the player and the summon action of the automatic summon item is set to a state in which it is automatically executed. When the auto summon flag information is "ON", the summon action of the auto summon item is automatically executed when the summon activation conditions of the auto summon item are met. In this way, the auto summon flag information includes "OFF" information, which is a manual mode in which the player manually selects the summon action, and "ON" information, which is an auto mode in which the summon action is automatically selected.

The ultimate technique activation flag information is flag information for determining whether or not to activate an ultimate technique attack action. The ultimate technique activation flag information is set in response to the operation of the ultimate technique activation selection tab 53d by the player. In the example shown in FIG. 12 and FIG. 13, the ultimate technique activation flag information is "ON" when the ultimate technique activation selection tab 53d is set to the ON state. Furthermore, the ultimate technique activation flag information is "OFF" when the ultimate technique activation selection tab 53d is set to the OFF state.

The character identification information is, for example, an ally character ID. The ally character ID is a unique identifier assigned to each ally character 51a and is used to individually identify each ally character 51a. The ability identification information is, for example, an ability ID. The ability ID is a unique identifier assigned to each ability and is used to individually identify each ability.

The automatic selection flag information is flag information for determining whether or not each ability action is to be automatically executed in full auto mode. The automatic selection flag information is set according to the operation of the full auto setting tab 62b by the player. In the example shown in FIG. 12, the setting state of the full auto setting tab 62b shown in FIG. 10 is shown. Specifically, the full auto setting tab 62b of the ability display field 62a corresponding to "ability 1" shown in FIG. 12 is set to the "ON" state. Also, the full auto setting tab 62b of the ability display field 62a corresponding to "ability 2" is set to the "OFF" state. Also, the full auto setting tab 62b of the ability display field 62a corresponding to "ability 3" is set to the "ON" state. Also, the full auto setting tab 62b of the ability display field 62a corresponding to "ability 4" is set to the "ON" state. For abilities whose automatic selection flag information is in the "ON" state, the ability action is automatically executed in full auto mode. On the other hand, for abilities whose auto-selection flag information is "OFF", the ability action is not executed automatically in full auto mode, but is executed by manual operation by the player. In this way, the auto-selection flag information includes information that specifies whether or not each ability of ally character 51a is executed automatically. In other words, the auto-selection flag information includes "OFF" information, which is a manual mode in which the player manually selects the ability action of ally character 51a, and "ON" information, which is an auto mode in which the ability action is automatically selected.

In this way, the first information and the second information include information specifying target items for the manual mode in which the player manually selects the actions of the ally character 51a, and information specifying target items for the auto mode in which at least some of the actions of the ally character 51a are automatically selected. Therefore, the first information and the second information can specify target items for the manual mode and target items for the auto mode separately. In other words, the target items for the manual mode and the target items for the auto mode can be individually set in detail according to the game characteristics of the first game and the second game. Similarly, the first information and the second information can specify whether or not each ability of the ally character 51a is automatically executed. Therefore, the ability of the ally character 51a is individually set in detail according to the game characteristics of the first game and the second game.

In this embodiment, the first game and the second game are games with the same content ID. This allows the game settings for the multi-battle to be made individually in games with the same content ID, depending on whether the player has started a multi-battle or has joined a multi-battle started by another player. However, the first game and the second game may be games with different content IDs.

The following describes the processing of the player terminal 1 and the server 100 to realize the above game, and the functional units that carry out each of these processes. Note that the following describes processing related to multi-battles in particular, and omits explanations of other processing.

(Functional Units of Player Terminal 1)
14 is a functional block diagram of the player terminal 1. The storage device 12 of the player terminal 1 is provided with a program storage area 12a and a data storage area 12b. 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.

The programs that control the browser include a communications control program 70 and a multi-battle control program 71. Note that the programs listed in FIG. 14 are just examples, and many other programs are provided as programs that control the browser.

The CPU 10 runs each program stored in the program memory area 12a and updates the data in each storage unit in the data memory area 12b. The CPU 10 runs each program stored in the program memory area 12a, causing the player terminal 1 (computer) to function as a terminal control unit 1A. In other words, the player terminal 1 is an information processing device equipped with a terminal control unit 1A that processes various information processing programs. The terminal control unit 1A includes a communication control unit 70a and a multi-battle control unit 71a.

Specifically, the CPU 10 runs a communication control program 70, causing the computer to function as a communication control unit 70a. Similarly, the CPU 10 runs a multi-battle control program 71, causing the computer to function as a multi-battle control unit 71a.

The data storage area 12b includes a player information storage unit 80 as a storage unit for storing data. Note that the above storage units are merely examples, and the data storage area 12b includes many other storage units.

The player information storage unit 80 stores various information about the player, such as the player ID.

The communication control unit 70a transmits and receives information to and from the server 100. For example, the communication control unit 70a transmits to the server 100 specific request information based on the player's operation, and receives from the server 100 information in response to the transmitted request information.

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

(Functional Parts 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 170, a communication control program 171, a first information storage processing program 172, and a second information storage processing program 173. Note that the programs listed in Fig. 15 are just examples, and many other programs are stored in the program storage area 112a.

The CPU 110 runs each program stored in the program memory area 112a and updates the data in each storage unit in the data memory area 112b. The CPU 110 runs each program stored in the program memory area 112a, causing the server 100 (computer) to function as a server control unit 100A. In other words, 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 170a, a communication control unit 171a, a first information storage processing unit 172a, and a second information storage processing unit 173a.

Specifically, the CPU 110 runs the game execution control program 170, causing the computer to function as a game execution control unit 170a. Similarly, the CPU 110 runs the communication control program 171, the first information storage processing program 172, and the second information storage processing program 173, causing the computer to function as a communication control unit 171a, a first information storage processing unit 172a, and a second information storage processing unit 173a, respectively.

The data memory area 112b includes a game information memory area 180 and a player information memory area 181 as memory areas for storing data. Note that the above memory areas are only examples, and the data memory area 112b includes many other memory areas.

The game information storage unit 180 stores various information related to the progress of the game, such as the game progress status. The player information storage unit 181 stores various information related to each player.

The game execution control unit 170a controls the progress of the entire game. For example, the game execution control unit 170a updates the game information of the entire game based on receiving various information indicating the input operations of the player to the player terminal 1. Furthermore, when the game information of the entire game is updated, the game execution control unit 170a generates display information based on the updated game information and causes the player terminal 1 to receive it via the communication control unit 171a.

The game execution control unit 170a also cooperates with the multi-battle control unit 71a of the player terminal 1 to control the execution of the multi-battle. For example, the game execution control unit 170a causes the player to participate in a multi-player game that corresponds to the game information selected by the player from among the game information acquired by the player.

The communication control unit 171a transmits and receives information to and from the player terminal 1. For example, the communication control unit 171a receives from the player terminal 1 specific request information based on the player's operation, and causes the player terminal 1 to receive display information generated based on the received information.

The first information storage processing unit 172a executes a management process for managing the first information as game setting information that is set based on the player's operation. The management process includes, for example, a process for storing the first information received from the player terminal 1 in the player information storage unit 181, a process for reading the first information from the player information storage unit 181, a process for updating the first information, etc.

The second information storage processing unit 173a executes a management process for managing the second information as game setting information that is set based on the player's operation. The management process includes, for example, a process for storing the second information received from the player terminal 1 in the player information storage unit 181, a process for reading the second information from the player information storage unit 181, a process for updating the second information, etc.

(Communication Processing Between Player Terminal 1 and Server 100)
The following describes the process related to the player's game settings in the above-mentioned multi-battle among the communication processes between the player terminal 1 and the server 100. Note that the process related to the player's game settings in the multi-battle described below is similar to the process performed in the first game and the second game. Therefore, the following describes the process related to the player's game settings in the first game, and the process related to the player's game settings in the second game will not be described.

Figure 16 is a sequence diagram 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 any integer), and the processing in the server 100 is indicated as Sn (n is any integer).

As shown in FIG. 16, when a multi-battle start operation is input, the communication control unit 70a 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.

When the first information storage processing unit 172a of the server 100 receives the multi-battle start request information via the communication control unit 171a, it extracts the player identification information, content identification information, and multi-type identification information included in the multi-battle start request information. Then, the first information storage processing unit 172a determines whether or not the first information including the extracted player identification information, content identification information, and multi-type identification information is stored in the player information storage unit 181. Here, the first information storage processing unit 172a determines whether or not there is first information that matches the extracted player identification information, content identification information, and multi-type identification information. In other words, the first information storage processing unit 172a determines whether or not there is existing game setting information (first information) that has already been set by the player in the multi-battle that the player is about to start playing (S1).

When the first information is stored in the player information storage unit 181, the first information storage processing unit 172a reads out the first information from the player information storage unit 181, and causes the player terminal 1 to receive the read out first information as multi-battle game setting information via the communication control unit 171a. On the other hand, when the first information is not stored in the player information storage unit 181, the first information storage processing unit 172a causes the player terminal 1 to receive predetermined default setting information as multi-battle game setting information via the communication control unit 171a. Here, the default setting information includes auto type identification information, auto summon flag information, special skill activation flag information, and auto selection flag information, which are the default settings.

When the game execution control unit 170a of the server 100 receives the multi-battle start request information via the communication control unit 171a, the game execution control unit 170a executes a start setting process to set various start settings related to the multi-battle (S2). For example, the game execution control unit 170a sets the enemy character 51b in the multi-battle specified by the content identification information of the multi-battle start request information, sets the initial HP value of the enemy character 51b, sets the special action of the enemy character 51b, etc.

Next, the game execution control unit 170a executes a battle screen information generation process to generate battle screen information for displaying a battle screen (S3). Here, the game execution control unit 170a causes the player terminal 1 to receive the generated battle screen information via the communication control unit 171a.

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 70a (P2).

When the player operates the normal auto mode tab 60a or the full auto mode tab 60b, the communication control unit 70a of the player terminal 1 transmits the auto type identification information set by the player to the server 100 (P3). At this time, the communication control unit 70a transmits the auto summon flag information, the special skill activation flag information, the character identification information, the ability identification information, and the auto selection flag information to the server 100, regardless of whether the settings have been changed.

When the first information storage processing unit 172a of the server 100 receives the auto type identification information via the communication control unit 171a, it associates the received auto type identification information with the player identification information, content identification information, multi-type identification information, automatic summon flag information, secret skill activation flag information, character identification information, ability identification information, and automatic selection flag information, generates or updates the first information, and executes a storage process to store it in the player information storage unit 181 (S4). Here, if the started multi-battle is the first game, the first information storage processing unit 172a stores the first information used in the first game in the player information storage unit 181. Also, if the started multi-battle is the second game, the second information storage processing unit 173a stores the second information used in the second game in the player information storage unit 181. The same applies to S5, S6, S7, and S10 below.

When the player operates the Auto Summon OFF tab 61a or the Auto Summon ON tab 61b, the communication control unit 70a of the player terminal 1 transmits the auto summon flag information set by the player to the server 100 (P4). At this time, the communication control unit 70a transmits the auto type identification information, special skill activation flag information, character identification information, ability identification information, and auto selection flag information to the server 100, regardless of whether the settings have been changed.

When the first information storage processing unit 172a of the server 100 receives the automatic summon flag information via the communication control unit 171a, it executes a storage process in which it associates the received automatic summon flag information with the player identification information, content identification information, multi-type identification information, auto type identification information, special skill activation flag information, character identification information, ability identification information, and automatic selection flag information, generates or updates the first information, and stores it in the player information storage unit 181 (S5).

When the player operates the special ability activation selection tab 53d, the communication control unit 70a of the player terminal 1 transmits the special ability activation flag information set by the player to the server 100 (P5). At this time, the communication control unit 70a transmits the auto type identification information, auto summon flag information, character identification information, ability identification information, and auto selection flag information to the server 100, regardless of whether the settings have been changed.

When the first information storage processing unit 172a of the server 100 receives the special attack activation flag information via the communication control unit 171a, it executes a storage process in which it associates the received special attack activation flag information with the player identification information, content identification information, multi-type identification information, auto type identification information, auto summon flag information, character identification information, ability identification information, and auto selection flag information to generate or update first information and store it in the player information storage unit 181 (S6).

When the player operates the full auto setting tab 62b, the communication control unit 70a of the player terminal 1 transmits the automatic selection flag information set by the player to the server 100 (P6). At this time, the communication control unit 70a transmits the auto type identification information, automatic summon flag information, special skill activation flag information, character identification information, and ability identification information to the server 100, regardless of whether the settings have been changed.

When the first information storage processing unit 172a of the server 100 receives the automatic selection flag information via the communication control unit 171a, it executes a storage process in which it associates the received automatic selection flag information with the player identification information, content identification information, multi-type identification information, auto type identification information, automatic summon flag information, special skill activation flag information, character identification information, and ability identification information, generates or updates first information, and stores it in the player information storage unit 181 (S7).

The multi-battle control unit 71a of the player terminal 1 performs a battle execution process for executing a multi-battle by communicating with the server 100 based on the player's input operation on the battle screen (P7). Also, the game execution control unit 170a of the server 100 performs a battle execution process for executing a multi-battle based on the information received from the player terminal 1 (S8). At this time, if the first information is stored in the player information storage unit 181, the game execution control unit 170a performs a battle execution process based on the stored first information. Specifically, if the multi-battle is a first game, the battle execution process uses the first information, which is game setting information set by the player stored in the player information storage unit 181, reflects the first information in the first game, and executes the first game reflected in the first information. Also, if the multi-battle is a second game, the battle execution process uses the second information, which is game setting information set by the player stored in the player information storage unit 181, reflects the second information in the second game, and executes the second game reflected in the first information.

When the end condition of the multi-battle is met, the game execution control unit 170a of the server 100 performs a battle game end process to end the multi-battle (S9). At this time, the game execution control unit 170a causes the player terminal 1 to receive battle game end information to end the multi-battle via the communication control unit 171a. The game execution control unit 170a also updates the player information based on the game result information of the ended multi-battle.

The multi-battle control unit 71a 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 171a (P8). At this time, the communication control unit 70a of the player terminal 1 transmits to the server 100 game setting information (first information) including auto type identification information, auto summon flag information, special skill activation flag information, character identification information, ability identification information, and auto selection flag information at the time of the end of the multi-battle.

When the first information storage processing unit 172a of the server 100 receives the game setting information via the communication control unit 171a, it executes a storage process to generate or update the first information based on the received game setting information and store it in the player information storage unit 181 (S10).

Although one aspect of the embodiment has been described above with reference to the attached 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 naturally fall within the technical scope.

In the above embodiment, 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.

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 any game genre, such as RPG, action games, puzzle games, training games, sports games, etc. In any case, the information processing system S includes one or more computers, and the computers perform the following processes.

A process for storing first information to be used in a first game in which multiple players can participate and which is started by a first player, based on the operation of the first player (in the embodiment, steps S4, S5, S6, S7, and S10 are given as examples).

A process for storing second information to be used in a second game in which multiple players can participate and which is started by a second player, based on the operation of the first player (in the embodiment, steps S4, S5, S6, S7, and S10 are taken as examples).

A process of executing a first game using the first information, and executing a second game in which the first player participates using the second information (S8 in the embodiment is an example).

In addition, multiple types of games may be provided that are linked to different content IDs, and the first game and the second game may include games with the same content ID.

The first information and the second information may also include information specifying target items for a manual mode in which the first player manually selects an action for the character, and information specifying target items for an auto mode in which at least some of the actions for the character are automatically selected.

The character may also be set with a number of abilities that can be executed in the first game and the second game, and the information specifying the target items of the auto mode may include information specifying whether each of the character's abilities can be executed automatically.

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

The program in the above embodiment may be stored in a computer-readable storage medium and provided as the storage medium. It may also be provided as a game terminal device or information processing system that includes this storage medium. The above embodiment may also be an information processing method that realizes each function and step shown in the flowchart.

1 Player terminal 100 Server S Information processing system

Claims (6)

a process of storing first information, which is used in a first game in which a plurality of players can participate and which is started by a first player , and which associates type identification information, character identification information, and action information of the first game with each other, based on an operation of the first player;
a process of storing second information, which is used in a second game in which a plurality of players can participate and which is started by a second player , and which associates the type identification information, the character identification information, and the action information of the second game with each other , based on an operation of the first player;
a process of executing the first game using the first information, and executing the second game in which the first player participates using the second information;
The computer executes the following:
Information processing program. A plurality of types of games are provided, each associated with a different content ID;
The first game and the second game include a game having the same content ID.
The information processing program according to claim 1 . The first information and the second information are
the information designating a target item of a manual mode in which the first player manually selects an action of a character, and information designating a target item of an auto mode in which at least a part of the actions of the character are automatically selected;
3. The information processing program according to claim 1 or 2. a plurality of abilities executable by the character in the first game and the second game are set;
The information for specifying the target items of the auto mode includes information for specifying whether or not each ability of the character is to be automatically executed.
The information processing program according to claim 3. One or more computers
a process of storing first information, which is used in a first game in which a plurality of players can participate and which is started by a first player , and which associates type identification information, character identification information, and action information of the first game with each other, based on an operation of the first player;
a process of storing second information, which is used in a second game in which a plurality of players can participate and which is started by a second player , and which associates the type identification information, the character identification information, and the action information of the second game with each other , based on an operation of the first player;
a process of executing the first game using the first information, and executing the second game in which the first player participates using the second information;
To carry out
Information processing methods. One or more computers;
The computer,
a process of storing first information, which is used in a first game in which a plurality of players can participate and which is started by a first player , and which associates type identification information, character identification information, and action information of the first game with each other, based on an operation of the first player;
a process of storing second information, which is used in a second game in which a plurality of players can participate and which is started by a second player , and which associates the type identification information, the character identification information, and the action information of the second game with each other , based on an operation of the first player;
a process of executing the first game using the first information, and executing the second game in which the first player participates using the second information;
To carry out
Information processing system.

Images