Information processing program, information processing method, and information processing system

JP2025020958APending Publication Date: 2025-02-13CYGAMES INC
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
JP2023124609
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2023-07-31
Publication Date
2025-02-13

AI Technical Summary

Benefits of technology

【0012】 本発明によれば、プレイヤの操作性を簡便化することが可能となる。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025020958000001_ABST
    Figure 2025020958000001_ABST
Patent Text Reader

Abstract

To simplify a player's operability.SOLUTION: An information processing program allows a computer to execute processing for storing first information used in a first game that multiple players can join and can be started by a first player on the basis of the first player's operation, processing for storing second information used in a second game that multiple players can join and can be started by a second player on the basis of the first player's operation, and processing for executing the first game by using the first information and executing the second game that the first player joins by using the second information.SELECTED DRAWING: Figure 16
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

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

[0002] For example, Patent Document 1 discloses a system that realizes a multiplayer game in which multiple players cooperate to play against an enemy character. In this system, a player can request other players to help, i.e., participate in, a multiplayer game that the player has started. Therefore, a request for help is sent to each player for a multiplayer game in which the player can participate. The player can select the multiplayer game in which the player wishes to participate from among the multiplayer games for which the player has received a request for help. [Prior art documents] [Patent documents]

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

[0004] 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. In addition, 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 every time a multiplayer game is cleared, the player may have to perform an operation 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 operation may become complicated when playing a multiplayer game.

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

[0006] In order to solve the above problem, an information processing program includes: A process of storing first information to be used in a first game in which a plurality of players can participate and which is started by a first player, based on an operation of the first player; storing second information to be used in a second game in which a plurality of players can participate and which is started by a second player 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.

[0007] There are multiple types of games that are linked to different content IDs, The first game and the second game may include a game with the same content ID.

[0008] 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 a part of the actions of the character are automatically selected.

[0009] a plurality of abilities that can be executed in the first game and the second game are set for the character; 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.

[0010] In order to solve the above problem, an information processing method includes: One or more computers A process of storing first information to be used in a first game in which a plurality of players can participate and which is started by a first player, based on an operation of the first player; storing second information to be used in a second game in which a plurality of players can participate and which is started by a second player 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.

[0011] In order to solve the above problem, an information processing system includes: One or more computers; The computer, A process of storing first information to be used in a first game in which a plurality of players can participate and which is started by a first player, based on an operation of the first player; storing second information to be used in a second game in which a plurality of players can participate and which is started by a second player 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. Effect of the Invention

[0012] According to the present invention, it is possible to simplify the operability for the player. [Brief description of the drawings]

[0013] [Figure 1] FIG. 1 is an explanatory diagram showing a schematic configuration of an information processing system. [Diagram 2] Fig. 2A is a diagram illustrating the hardware configuration of a player terminal, and Fig. 2B is a diagram illustrating the hardware configuration of a server. [Diagram 3] Fig. 3A is a diagram showing an example of a My Page screen, and Fig. 3B is a diagram showing an example of a quest list screen. [Figure 4] Fig. 4A is a diagram showing an example of a rescue request list screen, Fig. 4B is a diagram showing an example of a multi-battle list screen, and Fig. 4C is a diagram showing an example of a multi-battle selection screen. [Diagram 5] Fig. 5A shows an example of a My Page screen when a rescue request is received from another player. Fig. 5B shows an example of a quest list screen when a rescue request is received from another player. Fig. 5C shows an example of a rescue request list screen when a rescue request is received from another player. [Figure 6] Fig. 6A is a 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. [Figure 7] 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. [Figure 8] 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. [Figure 9] 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. [Figure 10] Fig. 10A is a diagram illustrating a battle menu screen, and Fig. 10B is a diagram illustrating an ability setting screen. [Figure 11] FIG. 11 is a diagram illustrating an example of ability information of an ally character. [Figure 12] FIG. 12 is a diagram for explaining the first information used in the first game. [Figure 13] FIG. 13 is a diagram for explaining the second information used in the second game. [Figure 14] FIG. 14 is a functional block diagram of the player terminal. [Figure 15] FIG. 15 is a functional block diagram of the server. [Figure 16] FIG. 16 is a sequence diagram illustrating the processing of the player terminal and the server. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0015] (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.

[0016] 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0034] 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.

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

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

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

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

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

[0040] As will be described later, one type of quest is a multi-battle quest (hereinafter, referred to as a multi-battle) as a multi-player 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 the difficulty level). 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 multi-player game in which multiple players can participate. For example, it is assumed that a first player executes a multi-battle and starts (launches) a new multi-battle. The first player can request help from another player (a second player).

[0041] The second player can receive a rescue request from the first player and later join the multi-battle started by the first player. The player who newly starts a multi-battle may be called the discoverer, and the player who joins later may be called the rescuer. The number of people who can fight 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 the player (first player) participates in a multi-battle started by another player (second player). Hereinafter, a multi-battle started by a player is also simply referred to as a first game. A multi-battle started by another player and in which the player participates is also simply referred to as a second game.

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

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

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

[0045] 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.

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

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

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

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

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

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

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

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

[0054] 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."

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

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

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

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

[0059] 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.

[0060] 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.

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

[0062] 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.

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

[0064] When the multi-battle participation tab 39 is operated, the player can participate as a rescuer in the multi-battle of another player who has issued a rescue request. Although a detailed explanation is omitted, when the multi-battle participation tab 39 is operated, a party formation screen is displayed. After forming a party on the party formation screen, the player can participate in the multi-battle using the formed party.

[0065] In this embodiment, a rescue search setting function is provided that allows each player to set in advance the rescue requests that he or she wishes to receive. The rescue search setting function will be described in detail below.

[0066] FIG. 6A is a first diagram illustrating an example of a rescue search screen. FIG. 6B is a second diagram illustrating an example of a rescue search screen. FIG. 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 FIG. 6A is displayed. On the rescue search screen, similar to the rescue request list screen, a new arrival 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.

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

[0068] On the rescue search screen, when the first setting tab 35b1 is operated, 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.

[0069] 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 ID is set is selected, the multi-battle participation tab 39 is not displayed, and a message indicating that the search conditions have not been set is displayed, as shown in FIG. 6C.

[0070] Furthermore, 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 transmitted to the server 100. That is, 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.

[0071] Furthermore, the multi-battle participation tab 39 is updated when the reload tab 30b of the frame bar 30 is operated. 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.

[0072] In addition, a campaign period may be set separately from the event period. During the campaign period, the AP or BP required to play the campaign target quest may decrease, or the reward may increase. During the campaign period, the campaign icon 35h is displayed on the multi-battle participation tab 39 of the campaign target quest, as shown in FIG. 6A. Next, an example of a case where a multi-battle is performed as a discoverer will be described.

[0073] 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 showing the multi-battle in the quest list screen shown in FIG. 3B is operated, or the multi-battle challenge tab 37b in the multi-battle selection screen shown in FIG. 4C is operated, the battle screen shown in FIG. 7C is displayed. When the battle screen is displayed, it is immediately switched to the rescue request screen shown in FIG. 7A. In the rescue request screen, the player can set the range of players to issue a rescue request.

[0074] 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."

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

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

[0077] 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.

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

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

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

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

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

[0083] When the rescue request is completed by operating the rescue request sending tab 50d shown in Fig. 7A, a 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 is switched to a battle screen shown in Fig. 7C.

[0084] Also, 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 predetermined time has passed since the start of a battle without a rescue request being made, 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.

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

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

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

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

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

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

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

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

[0093] Furthermore, the survival or disappearance of the enemy character 51b may be determined based on a total damage ratio indicating a 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 (for example, 100%), the enemy character 51b may disappear.

[0094] As shown in Fig. 7C, a normal attack tab 52 marked "attack" is displayed on the battle screen. The normal attack tab 52 is disposed, for example, below the screen of the ally character 51a. The normal attack tab 52 receives an input indicating an action (for example, an attack) of the player.

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

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

[0097] In addition, in the lower half of the battle screen, an ability selection tab 53a, a summoned beast selection tab 53b, and a recovery tab 53c labeled "Recovery" are displayed. The 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 and the type of ability to be activated is determined, the determined ability is activated by the ally character 51a. Although the details of the ability will be described later, when the 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 the ability is activated once until it can be activated again is set for the ability. In addition, unlike the input of the normal attack tab 52, the enemy character 51b does not take action at the timing of activation of the ability.

[0098] 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 given to the enemy character 51b. The summoning action can be initiated when a predetermined summoning activation condition is met, such as the passage of a predetermined number of turns. Also, unlike input of the normal attack tab 52, the enemy character 51b does not take any action at the time the summoning action is initiated.

[0099] 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 of the normal attack tab 52, the recovery related to the recovery tab 53c does not cause the enemy character 51b to act at the time of execution.

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

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

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

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

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

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

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

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

[0108] FIG. 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, which can be switched to. The manual mode is a mode in which the player manually selects the action 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. In the following, 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 action of the ally character 51a. The actions that the player can select are broadly divided into two actions: normal actions and special actions. The normal actions are, for example, normal attack actions. The normal attack actions are executed manually by the player operating the normal attack tab 52, or automatically by the CPU 110. The special actions are, for example, ability actions, item use actions, and summon actions. The ability action is executed manually by the player operating the ability selection tab 53a, or automatically by the CPU 110. The item use action is executed manually by the player operating the recovery tab 53c. The summon action is executed manually by the player selecting the summon beast selection tab 53b, or automatically by the CPU 110.

[0109] When the normal attack tab 52 is operated, a normal attack action is started, and the four ally characters 51a perform normal attack actions against the enemy character 51b in a predetermined order (for example, the order set in the party formation). In the normal attack action, the ally characters 51a attack the enemy character 51b, thereby causing damage to the enemy character 51b. When the normal attack action is performed, as shown in FIG. 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.

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

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

[0112] 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.

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

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

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

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

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

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

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

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

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

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

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

[0124] Furthermore, in the special action section, the player can activate a summoning effect by a summoning action by tapping the summoned beast selection tab 53b. The ally character 51a can be equipped with a summoning item as equipment in addition to a weapon. A predetermined summoning activation condition is set for the summoning item. When the summoning activation condition set for the summoning item is satisfied, the summoning effect can be activated by operating the summoning item equipped to the ally character 51a by the player. By activating the summoning effect, a favorable effect can be given to the ally character 51a, a disadvantageous effect can be given to the enemy character 51b, a damage value can be given to the enemy character 51b, and so on, and the battle game can be advantageously advanced.

[0125] When using an ability, the player taps the ability selection tab 53a of one of the ally characters 51a. When using a recovery item, the player 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 a summoning effect is to be activated, the summoned beast selection tab 53b is tapped. 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.

[0126] Fig. 8A is a diagram illustrating an example of an ability selection frame 56. When the ability selection tab 53a of any of the ally characters 51a is tapped during a special action section, the ability selection frame 56 is displayed on the display 26, as shown in Fig. 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.

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

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

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

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

[0131] In this way, the ability actions are executed in the special action section in the order that the ability icons 56a are tapped (i.e., from the top to the bottom of the reserved action display section 57). As described below, when the ability actions are executed automatically by the CPU 110 in the special action section in auto mode, they are executed automatically in the order according to the priority order set for the ability actions. The ability actions change the values ​​of various parameters (parameter values) used in the battle game, such as the HP and attack power of the ally character 51a or enemy character 51b. Also, an action image (ability animation) corresponding to the ability action is displayed on the display 26, as shown in FIG. 8B.

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

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

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

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

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

[0137] 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, a summoning item icon (not shown) corresponding to the summoning item selected by the player is displayed in the reserved action display section 57. When the summoning action is executed, a summoning animation is displayed.

[0138] 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.

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

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

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

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

[0143] During the battle game, a predetermined meter value (hereinafter, also referred to as a special attack 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 using an ability or an item. As shown in FIG. 7D, a special attack activation selection tab 53d is displayed in the lower half of the screen of the display 26. The special attack 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, a special attack activation condition for activating the special attack action of the ally character 51a is satisfied. On the other hand, when the meter value of the ally character 51a does not reach the maximum value, the special attack activation condition is not satisfied, and the special attack action cannot be activated. When the secret technique activation selection tab 53d is set to the ON state, it allows the activation of the secret technique attack action of the ally character 51a whose secret technique activation condition is met, and when it is set to the OFF state, it restricts the activation of the secret technique attack action of the ally character 51a whose secret technique activation condition is met. In the manual mode, when the secret technique activation selection tab 53d is in the ON state and the normal attack tab 52 is tapped in a state where the secret technique activation condition of any of the ally characters 51a is met, the attack action of the ally character 51a whose secret technique activation condition is met becomes a secret technique attack action instead of a normal attack action. This secret technique attack action gives more damage to the enemy character 51b than a normal attack action. On the other hand, when the secret technique activation selection tab 53d is in the OFF state and the normal attack tab 52 is tapped in a state where the secret technique activation condition of any of the ally characters 51a is met, the attack action of the ally character 51a whose secret technique activation condition is met remains a normal attack action, and the secret technique attack action is not activated. In other words, when the secret attack selection tab 53d is in the OFF state, the secret attack action of the ally character 51a is reserved and the meter value that has reached the maximum value is maintained. After the secret attack action is activated, the meter value is reset to 0.

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

[0145] As described above, in the manual mode, the player can fight the ally character 51a and the enemy character 51b by manually selecting the normal action and the special action during the battle game. However, the player needs to manually select the normal action and the special action one by one during the battle game, and the manual operation during the battle game is troublesome. In addition, beginners may not understand the purpose of the special action or the effective use order, and may have difficulty in effectively using the special action.

[0146] 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 of this embodiment includes a normal auto mode and a full auto mode. Thus, the auto mode of this embodiment includes two types: a normal auto mode and a full auto mode.

[0147] 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). 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.

[0148] FIG. 9A is a diagram of a battle screen for explaining the normal auto mode. FIG. 9B is a diagram of a battle screen for explaining the full auto mode. In the normal auto mode of FIG. 9A, an Auto icon 58 is displayed on the battle screen. Also, in the full auto mode of FIG. 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 a player. When the Auto icon 58 is in an ON state, the normal auto mode can be turned on, and when the Auto icon 58 is in an OFF state, the normal auto mode can be turned off (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 a player. When the Full icon 59 is in an ON state, the full auto mode can be turned on, and when the Full icon 59 is in an OFF state, the full auto mode can be turned off (i.e., manual mode).

[0149] In this embodiment, when the battle game starts, the manual mode is set as a 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).

[0150] When the 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 shows a display state in the manual mode when the normal auto mode is OFF. In the manual mode state shown in Fig. 7D, the player can operate (tap) the Auto icon 58.

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

[0152] The Auto icon 58 shown in Fig. 9A shows a display state in which the normal auto mode is ON. As shown in Fig. 9A, when the normal auto mode is ON, the Auto icon 58 in the normal auto mode OFF state shown in Fig. 7D is displayed inverted. Furthermore, when the normal auto mode is ON, the player is in a state in which 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.

[0153] In the normal auto mode, during the player's turn until the battle game ends, the special action is not executed (i.e., the special action section is skipped), and the normal action (normal attack action) is repeatedly and automatically selected and executed. In other words, the player can automatically execute the normal action (normal attack action) during the player's turn until the battle game ends by 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 condition of the ally character 51a is satisfied, the special attack action of the ally character 51a whose special attack condition is satisfied is automatically executed during the player's turn. This is common to both the normal auto mode and the full auto mode.

[0154] 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 the normal auto mode. In other words, it may be difficult to clear the battle game by only performing normal actions.

[0155] Therefore, the auto mode function of this embodiment has a full auto mode in addition to the normal auto mode. In the full auto mode, special actions can be automatically selected and executed in addition to normal actions. In the full auto mode, special actions can be executed in addition to normal actions, allowing the player to proceed through the battle game more advantageously than in the normal auto mode.

[0156] When the full auto mode is set as the type of auto mode, when the battle game starts, a 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.

[0157] The Full icon 59 is switched from the OFF state to the ON state or from the ON state to the OFF state by being operated by the player in the same manner as the Auto icon 58. When the Full icon 59 is operated to the ON state, the player terminal 1 executes a process of switching from the manual mode to the full auto mode during the battle game.

[0158] 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 normal attack tab 52 is automatically operated, and the player does not 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, the player does not need 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 a special action is only accepted during the special action section up until the start of the normal action section, and once the normal action section begins, manual selection of a special action becomes invalid.

[0159] In full auto mode, special actions and normal actions (normal attack actions) during one'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, and item use actions are not automatically selected or executed. In addition to ability actions, summon actions can also be automatically executed in full auto mode, as described in detail below.

[0160] 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 his / her turn repeatedly until the battle game ends. This allows the player to reduce the complexity of manual operations during the battle game. In addition, in the full auto mode, special actions are executed in addition to normal actions, making it easier to clear the battle game than in the normal auto mode. A battle menu tab 53f is displayed at the top of the battle screen.

[0161] FIG. 10A is a diagram for explaining a battle menu screen. FIG. 10B is a diagram for explaining an 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 of the ally character 51a shown in FIG. 10B is displayed on the display 26.

[0162] 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 the normal auto mode as the type of auto mode in the battle game. The full auto mode tab 60b is a tab for setting the 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, the normal auto mode is set as the type of auto mode, and when the full auto mode tab 60b is operated by the player, the 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. The type of auto mode in the battle game can be set not only from the battle menu screen, but also from a menu screen (not shown) that is displayed by the player operating the menu tab 31a on the My Page screen shown in FIG. 3A.

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

[0164] The automatic summoning OFF tab 61a is a tab for setting the summoning action of the preset automatic summoning item to a state where it is not automatically executed when the summoning activation condition is satisfied. The automatic summoning ON tab 61b is a tab for setting the summoning action of the preset automatic summoning item to a state where it is automatically executed when the summoning activation condition is satisfied. 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, the immediate summoning selection tab 53e is displayed in the lower half of the screen of the display 26. The immediate summoning selection tab 53e can be operated by the player when the summoning activation condition of the automatic summoning item is satisfied to manually activate the summoning action of the automatic summoning item.

[0165] As shown in Fig. 10B, the ability setting screen displays a plurality of ability display fields 62a corresponding to a plurality of 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.

[0166] The full auto setting tab 62b is a tab for setting ability actions that are automatically selected and executed in full auto mode. By operating the full auto setting tab 62b by the player, 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 and executed.

[0167] FIG. 11 is a diagram for explaining an example of the ability information of the ally character 51a. As shown in FIG. 11, the ability information of the 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 order of the four ally characters 51a organized into a party. In the example shown in FIG. 11, the priority order of the ally characters 51a is determined in the order of character 1 → character 2 → character 3 → character 4, with character 1 having the highest priority order and character 4 having the lowest priority order. The ability identification information is information about the abilities set for each ally character 51a.

[0168] There are various types (attributes) of abilities. For example, there are 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 a number of types (attributes). As a result, the multiple abilities are classified into various types (attributes). Ability type information is information related to the type set for each ability.

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

[0170] 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.

[0171] 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, which may make it difficult for the player to gain an advantage in the battle game. Therefore, the field effect ability is excluded from the ability list that is automatically executed in full auto mode.

[0172] Furthermore, if a recovery ability is 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 he or she wishes to use it. Furthermore, even if a recovery ability is used, it does not contribute to damage to the enemy character 51b. Therefore, recovery abilities are excluded from the list of abilities that are automatically executed in full auto mode. However, this is not limited to this, and field effect abilities and recovery abilities may be set to be automatically executed in full auto mode.

[0173] Furthermore, a predetermined priority is set in advance for the types of abilities. For example, the priority is set higher for the types of abilities that strengthen the ally character 51a than for the types of abilities that affect the enemy character 51b. Specifically, the priority is set higher for strengthening abilities than for abilities that affect the enemy character 51b (weakening abilities, damage abilities).

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

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

[0176] When the search for type C has been completed up to character 4, the presence or absence of type D, which has the next highest priority after type C, is searched in the order of character 1 → character 2 → character 3 → character 4, and type D is selected in turn if it is found.

[0177] When the search for type D has been completed up to character 4, the presence or absence of type E, which has the next highest priority after type D, is searched in the order of character 1 → character 2 → character 3 → character 4, and type E is selected in turn if it is found.

[0178] 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 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 of selection.

[0179] As described above, in a multi-battle, there are cases where a player (first player) starts a multi-battle and cases where the player (first player) participates 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 when starting the multi-battle and when participating in the multi-battle. Furthermore, if the game settings set by the player are overwritten and saved every time the multi-battle is cleared, the player may have to perform an operation to change the game settings each time when starting and participating in the multi-battle. As a result, when the player plays a multi-battle, there is a risk that the player's operation becomes complicated. Note that the game settings are setting information used in the game (here, the multi-battle), and are, for example, setting information referenced in the process 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, the 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. Furthermore, the game settings may include setting information such as screen resolution settings, frame rate settings, vertical synchronization settings, graphics settings, volume settings, language settings, camera settings, etc.

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

[0181] 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 referring to 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 referring to 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, and the operability of the player can be simplified.

[0182] 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. 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 a plurality of different content identification information may be associated with one player identification information.

[0183] 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.

[0184] The multi-battle type identification information is for identifying whether the multi-battle played by the player corresponds to the first game or the second game. In Fig. 12 and Fig. 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".

[0185] 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 operation of the normal auto mode tab 60a and the full auto mode tab 60b by the player. In Figs. 12 and 13, "Full" represents the full auto mode, and "Normal" represents the normal auto mode. In the example shown in Figs. 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, when "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.

[0186] The automatic summon flag information is flag information for determining whether or not the summon action of the automatic summon item set in advance is automatically executed when the summon activation condition is satisfied. 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 condition of the automatic summon item is satisfied. 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 automatic summon flag information is in the "ON" state, the summon action of the automatic summon item is automatically executed when the summon activation condition of the automatic summon item is satisfied. In this way, the automatic summon flag information includes "OFF" information which sets the manual mode in which the player manually selects the summon action, and "ON" information which sets the auto mode in which the summon action is automatically selected.

[0187] The special attack flag information is flag information for determining whether or not to activate a special attack action. The special attack flag information is set in response to the operation of the special attack selection tab 53d by the player. In the example shown in FIG. 12 and FIG. 13, the special attack flag information is set to "ON" when the special attack selection tab 53d is set to the ON state. Also, the special attack flag information is set to "OFF" when the special attack selection tab 53d is set to the OFF state.

[0188] 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.

[0189] 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 in the "OFF" state, the ability action is not executed automatically in full auto mode, but is executed by manual operation by the player. Thus, the auto-selection flag information includes information that specifies whether or not each ability of the ally character 51a is executed automatically. In other words, the auto-selection flag information includes "OFF" information that sets the manual mode in which the player manually selects the ability action of the ally character 51a, and "ON" information that sets the auto mode in which the ability action is automatically selected.

[0190] In this way, the first information and the second information include information for specifying a target item of the manual mode in which the player manually selects the action of the ally character 51a, and information for specifying a target item of 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 individually specify the target items of the manual mode and the target items of the auto mode. That is, the target items to be set as the manual mode and the target items to be set as the auto mode can be individually and in detail set 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 and in detail set according to the game characteristics of the first game and the second game.

[0191] 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 individually set depending on whether the player has started a multi-battle in a game with the same content ID or whether the player has joined a multi-battle started by another player. However, the first game and the second game may be games with different content IDs.

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

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

[0194] The programs that control the browser include a communication 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.

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

[0196] 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.

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

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

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

[0200] 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 operation 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 multi-player game of a content ID selected by a player.

[0201] (Functional part of server 100) Fig. 15 is a functional block diagram of the server 100. The storage device 112 of the server 100 is provided with a program storage area 112a and a data storage area 112b. The program storage area 112a stores a game execution control program 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.

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

[0203] Specifically, the CPU 110 runs a game execution control program 170, causing the computer to function as a game execution control unit 170a. Similarly, the CPU 110 runs a communication control program 171, a first information storage processing program 172, and a 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.

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

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

[0206] 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 reception of various information indicating the input operation of the player to the player terminal 1. Furthermore, when the game information of the entire game is updated, the game execution control unit 170a generates display information based on the updated game information and causes the player terminal 1 to receive the display information via the communication control unit 171a.

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

[0208] 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, predetermined request information based on an operation of a player, and causes the player terminal 1 to receive display information generated based on the received information.

[0209] The first information storage processing unit 172a executes a management process for managing first information as game setting information set based on a 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, and the like.

[0210] The second information storage processing unit 173a executes a management process for managing the second information as game setting information 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, and the like.

[0211] (Communication processing between player terminal 1 and server 100) The following describes the process related to the player's game settings in the 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 the same for 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 is omitted.

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

[0213] 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.

[0214] 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, the content identification information, and the multi-type identification information included in the multi-battle start request information. Then, the first information storage processing unit 172a judges whether or not the first information including the extracted player identification information, the content identification information, and the multi-type identification information is stored in the player information storage unit 181. Here, the first information storage processing unit 172a judges whether or not there is the first information that matches the extracted player identification information, the content identification information, and the multi-type identification information. That is, the first information storage processing unit 172a judges whether or not there is the existing game setting information (first information) already set by the player in the multi-battle that the player is about to start playing (S1).

[0215] 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 the game setting information of the multi-battle 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 the game setting information of the multi-battle via the communication control unit 171a. Here, the default setting information includes the auto type identification information, the auto summon flag information, the secret skill activation flag information, and the auto selection flag information, which are the default settings.

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

[0217] 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.

[0218] 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).

[0219] Furthermore, 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.

[0220] When the first information storage processing unit 172a of the server 100 receives the auto type identification information via the communication control unit 171a, the first information storage processing unit 172a associates the received auto type identification information with the player identification information, the content identification information, the multi type identification information, the automatic summon flag information, the secret skill activation flag information, the character identification information, the ability identification information, and the automatic selection flag information, generates or updates the first information, and executes a storage process to store the information 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.

[0221] Furthermore, when the player operates the automatic summoning OFF tab 61a or the automatic summoning ON tab 61b, the communication control unit 70a of the player terminal 1 transmits the automatic summoning 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, the special skill activation flag information, the character identification information, the ability identification information, and the automatic selection flag information to the server 100, regardless of whether the settings have been changed.

[0222] 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 of generating or updating first information by associating the received automatic summon flag information with player identification information, content identification information, multi-type identification information, auto type identification information, secret skill activation flag information, character identification information, ability identification information, and automatic selection flag information, and stores the first information in the player information storage unit 181 (S5).

[0223] Furthermore, when the player operates the special skill activation selection tab 53d, the communication control unit 70a of the player terminal 1 transmits special skill activation flag information set by the player to the server 100 (P5). At this time, the communication control unit 70a transmits 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.

[0224] When the first information storage processing unit 172a of the server 100 receives the secret technique activation flag information via the communication control unit 171a, it executes a storage process to generate or update first information by associating the received secret technique activation flag information with 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, and stores the first information in the player information storage unit 181 (S6).

[0225] Furthermore, 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.

[0226] 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 of generating or updating first information by associating the received automatic selection flag information with player identification information, content identification information, multi-type identification information, auto type identification information, automatic summon flag information, secret skill activation flag information, character identification information, and ability identification information, and storing the first information in the player information storage unit 181 (S7).

[0227] 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 input operation of the player 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 the battle execution process based on the stored first information. Specifically, if the multi-battle is the first game, the battle execution process uses the first information, which is game setting information set by the player and 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 the second game, the battle execution process uses the second information, which is game setting information set by the player and 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 game.

[0228] Then, 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. Also, the game execution control unit 170a updates the player information based on the game result information of the ended multi-battle.

[0229] 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, secret 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.

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

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

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

[0233] Moreover, the game contents in the above embodiment are merely examples. Furthermore, the game genre to which the above technical matters can be applied is not particularly limited. For example, the above technical matters can be applied to all game genres, such as RPG, action games, puzzle games, training games, sports games, etc. In any case, the information processing system S includes one or more computers, and the computers perform the following processes.

[0234] A process of 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 an embodiment, S4, S5, S6, S7, and S10 are examples).

[0235] A process of 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 a first player (in an embodiment, S4, S5, S6, S7, and S10 are examples).

[0236] 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 as an example).

[0237] Furthermore, a plurality of types of games may be provided, each associated with a different content ID, and the first game and the second game may include a game with the same content ID.

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

[0239] In addition, a plurality of abilities that can be executed in the first game and the second game may be set for the character, and the information specifying the target items of the auto mode may include information specifying whether or not each of the character's abilities is to be automatically executed.

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

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

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

Claims

1. a process of storing first information to be used in a first game in which a plurality of players can participate and which is started by a first player, based on an operation of the first player; storing second information to be used in a second game in which a plurality of players can participate and which is started by a second player 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; have a computer carry out Information processing program.

2. A plurality of types of games are provided, each associated with a different content ID; The first game and the second game include games having the same content ID. The information processing program according to claim 1 .

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

4. a plurality of abilities executable in the first game and the second game are set for the character; 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.

5. One or more computers a process of storing first information to be used in a first game in which a plurality of players can participate and which is started by a first player, based on an operation of the first player; storing second information to be used in a second game in which a plurality of players can participate and which is started by a second player 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.

6. One or more computers; The computer, a process of storing first information to be used in a first game in which a plurality of players can participate and which is started by a first player, based on an operation of the first player; storing second information to be used in a second game in which a plurality of players can participate and which is started by a second player 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.

Citation Information

Patent Citations

  • Control program, game device, and control method

    JP2023030179A