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

Description

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

Patent Literature 1 discloses a battle game in which a player pits a support character borrowed from another player against an enemy character.

JP 2019-69243 A

By the way, among battle games, there are also battle games in which specific characters cannot participate and restrictions are placed on characters who can participate. In a battle game in which characters that can participate are limited, if a support character borrowed from another player is a character that cannot participate as in Patent Document 1, the support character cannot be borrowed from another player. . If it becomes impossible to borrow support characters from other players, there is a problem that the range of strategy of the battle game is reduced.

An object of the present invention is to provide an information processing program, an information processing method, and an information processing system that are capable of expanding the range of strategies in a battle game.

In order to solve the above problem, the information processing program is a battle game played using characters each associated with a player ID and assigned a different ID, and the IDs of participating characters are not limited. A battle game execution unit that executes a first battle game and a second battle game in which the IDs of participating characters are restricted, and IDs of support characters that a player can borrow from other players in the first battle game. A list generation unit that generates a first list and generates a second list in which IDs of characters that cannot participate in the second battle game are excluded from support character IDs in the second battle game, and characters possessed by the player. as a support character that can be lent to other players, and a party organization unit that organizes a plurality of characters with different IDs to participate in the first battle game or the second battle game based on the player's input operation. and causing the computer to function, the second battle game includes a plurality of battle games having different IDs of characters who cannot participate in each other, the support character setting unit sets support characters for the second battle game, The list generation unit generates different second lists according to a plurality of types of the second battle game, and if the number of IDs of the support characters extracted for generating the second list is less than a predetermined number , general-purpose Perform character addition processing.
When displaying the second list on the display unit, the computer may function as a display control unit that displays characters that can participate in the second battle game among the support characters.

When the number of support characters in the second list is less than the predetermined number, the list generation unit generates characters that can participate in the second battle game among the characters that the player can acquire until the number of support characters reaches the predetermined number. may be added to the second list.

The party organization section may set the number of support characters that can be organized for the second battle game to be larger than the number of support characters that can be organized for the first battle game.

In the first battle game, the party organization unit organizes the characters possessed by the player and the characters selected from the support characters on the first list, and in the second battle game, the characters possessed by the player and the characters on the second list. Characters selected from the support characters may be organized, and the battle game execution section may execute the first battle game or the second battle game using the characters organized by the party formation section.

In order to solve the above problems, an information processing method is an information processing method executed by one or both of a player terminal and a server capable of communicating with the player terminal, wherein a character possessed by a player is transferred to another player. and a step of setting a support character that can be lent to the player, and a character that is associated with the player ID and assigned a different ID for each character to play the battle game, based on the player's input operation. Organizing a plurality of characters with different IDs to participate in a first battle game in which character IDs are not restricted or a second battle game in which participating character IDs are restricted; executing the first battle game; executing a second battle game; generating a first list of support character IDs that the player can borrow from other players in the first battle game; generating a second list in which the IDs of the characters who cannot participate in the second battle game are excluded from the IDs of the support characters borrowable from the second list; A plurality of battle games with different IDs are included, the step of setting the support characters sets the support characters for the second battle game, and the step of generating the second list is performed according to the plurality of types of the second battle game. A different second list is generated, and if the number of support character IDs extracted for generating the second list is less than a predetermined number , a general-purpose character addition process is performed.

In order to solve the above problems, an information processing system includes a player terminal and a server capable of communicating with the player terminal, wherein one or both of the player terminal and the server are associated with a player ID. A first battle game in which the IDs of participating characters are not restricted, and a second battle game in which the IDs of participating characters are restricted. a battle game execution unit for executing a second battle game; generating a first list of IDs of support characters that the player can borrow from other players in the first battle game; and a support character setting unit for setting the characters possessed by the player as support characters that can be lent to other players. and a party organization unit that organizes a plurality of characters with different IDs to participate in the first battle game or the second battle game based on the player's input operation, and the second battle game includes characters that cannot participate in each other. a plurality of battle games with different IDs, the support character setting unit sets support characters for the second battle game, and the list generation unit creates a different second list according to the plurality of types of the second battle game. If the number of support character IDs generated and extracted to generate the second list is less than a predetermined number , general-purpose character addition processing is performed.

According to the present invention, it is possible to expand the strategic range of the battle game.

FIG. 1 is an explanatory diagram showing a schematic configuration of an information processing system. FIG. 2A is a diagram for explaining the hardware configuration of the player terminal. FIG. 2B is a diagram for explaining the hardware configuration of the server. FIG. 3A is a diagram showing an example of a home screen. FIG. 3B is a diagram illustrating an example of a teammate character confirmation screen. FIG. 3C is a diagram showing an example of a quest screen. FIG. 4 is the first diagram for explaining an example of the support setting screen. FIG. 5A is a diagram illustrating an example of a guild search screen. FIG. 5B is a diagram illustrating an example of a guild search popup. FIG. 5C is a diagram illustrating an example of a guild formation popup. FIG. 6A is a diagram illustrating an example of a main quest screen. FIG. 6B is a diagram illustrating an example of a main quest selection screen. FIG. 6C is the first diagram for explaining an example of the party selection screen. FIG. 7 is the first diagram for explaining an example of the support character selection screen. FIG. 8A is a diagram illustrating an example of a battle screen. FIG. 8B is a diagram illustrating an example of a result screen. FIG. 8C is a diagram illustrating an example of a report screen. FIG. 9A is a first diagram illustrating an example of an event battle screen. FIG. 9B is a second diagram illustrating an example of a support setting screen used for event battles. FIG. 9C is the first diagram illustrating an example of the event battle selection screen. FIG. 10A is a first diagram for explaining an example of a composable character detail dialogue screen. FIG. 10B is a second diagram illustrating an example of the party selection screen. FIG. 10C is a second diagram for explaining an example of the support character selection screen. FIG. 11A is a second diagram illustrating an example of an event battle screen. FIG. 11B is a third diagram illustrating an example of a support setting screen used for event battles. FIG. 11C is a second diagram illustrating an example of the event battle selection screen. FIG. 12A is a second diagram for explaining an example of a composable character detail dialog screen. FIG. 12B is a third diagram for explaining an example of the party selection screen. FIG. 12C is a third diagram for explaining an example of the support character selection screen. FIG. 13A is a diagram illustrating an example of a story screen. FIG. 13B is a diagram illustrating an example of the main story screen. FIG. 14 is a diagram for explaining the configuration of a memory in a player terminal and functions as a computer. FIG. 15 is a diagram for explaining the configuration of a memory in a server and functions as a computer. FIG. 16 is a sequence diagram illustrating basic processing of the player terminal and server. FIG. 17 is a flowchart illustrating an example of list generation processing. FIG. 18 is a flowchart for explaining an example of party organization screen processing.

One aspect of an embodiment of the present invention will be described in detail below with reference to the accompanying drawings. The dimensions, materials, and other specific numerical values shown in these embodiments are merely examples for facilitating understanding, and do not limit the present invention unless otherwise specified. In the present specification and drawings, elements having substantially the same function and configuration are given the same reference numerals to omit redundant description, and elements that are not directly related to the present invention are omitted from the drawings. do.

(Overall Configuration of Information Processing System S)
FIG. 1 is an explanatory diagram showing a schematic configuration of an information processing system S. As shown in FIG. The information processing system S is a so-called client-server system including a player terminal 1, a server 100, and a communication network 200 having a communication base station 200a.

The player terminal (information processing device) 1 can establish communication with the server 100 via the communication network 200 . The player terminal 1 includes a wide range of electronic devices that can be connected to the server 100 for wireless or wired communication. Examples of the player terminal 1 include smart phones, mobile phones, tablet devices, personal computers, game machines, and the like. In this embodiment, a case where a smart phone is used as the player terminal 1 will be described.

The server 100 is configured to be able to communicate with a plurality of player terminals 1 and is connected to the plurality of player terminals 1 for communication. The server 100 accumulates various types of information (player information) for each player ID for identifying a player who plays the game.

The communication base station 200a is connected to the communication network 200, and transmits/receives information to/from the player terminal 1 by radio. The communication network 200 includes a mobile phone network, an Internet network, a LAN (Local Area Network), a dedicated line, etc., and realizes wireless or wired communication connection between the player terminal 1 and the server 100 .

In the information processing system S of this embodiment, the player terminal 1 and the server 100 function as a game device G. FIG. The player terminal 1 and the server 100 are responsible for controlling the progress of the game, respectively.

(Hardware configuration of player terminal 1 and server 100)
FIG. 2A is a diagram for explaining the hardware configuration of the player terminal 1. As shown in FIG. FIG. 2B is a diagram for explaining the hardware configuration of the server 100. As shown in FIG. As shown in FIG. 2A, the player terminal 1 includes a CPU (Central Processing Unit) 10, a memory 12, a bus 14, an input/output interface 16, a storage section 18, a communication section 20, an input section 22, and an output section 24. be done.

2B, the server 100 includes a CPU 110, a memory 112, a bus 114, an input/output interface 116, a storage section 118, a communication section 120, an input section 122, and an output section .

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

The CPU 10 operates programs stored in the memory 12 to control the progress of the game. The memory 12 is composed of a ROM (Read Only Memory) or a RAM (Random Access Memory), and stores programs and various data necessary for controlling the progress of the game. Memory 12 is connected to CPU 10 via bus 14 .

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

The storage unit 18 is composed of a semiconductor memory such as a DRAM (Dynamic Random Access Memory), and stores various programs and data. In the player terminal 1, the programs and data stored in the storage unit 18 are loaded by the CPU 10 into the memory 12 (RAM).

The communication unit 20 is wirelessly connected to the communication base station 200 a and transmits/receives information such as various data and programs to/from the server 100 via the communication network 200 . In the player terminal 1 , the program or the like received from the server 100 is stored in the memory 12 or the storage section 18 .

The input unit 22 includes, for example, a touch panel through which player's operations are input (accepts operations), buttons, a keyboard, a mouse, a cross key, an analog controller, and the like. Also, the input unit 22 may be a dedicated controller provided in the player terminal 1 or connected (externally attached) to the player terminal 1 . Furthermore, the input unit 22 may be configured with an acceleration sensor that detects the tilt or movement of the player terminal 1, or a microphone that detects the voice of the player. That is, the input unit 22 broadly includes a device capable of inputting the player's intention in an identifiable manner.

The output unit 24 includes a display device and a speaker. Note that 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 provided as an input unit 22 so as to overlap the display 26 .

(game content)
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. In this embodiment, a so-called battle game is provided in which friendly characters battle enemy characters. Specifically, in the game of this embodiment, a plurality of teammate characters are provided. The player selects a plurality of (here, five) ally characters from the provided ally characters to form a party. Also, the player can play a plurality of types of battle games with different enemy characters and different degrees of difficulty. In the battle game, the purpose of the battle game is for allied characters organized in a party to defeat (clear) enemy characters and obtain rewards.

FIG. 3A is a diagram showing an example of a home screen. FIG. 3B is a diagram illustrating an example of a teammate character confirmation screen. FIG. 3C is a diagram showing an example of a quest screen. The display 26 of the player terminal 1 displays game screens as shown in FIGS. 3A, 3B, and 3C. In this embodiment, the game screen is roughly divided into a normal screen and a battle screen.

The normal screen is mainly a screen for the player to confirm various settings and information. On the other hand, the battle screen is a screen displayed on the display 26 from the start to the end of the battle game. Here, all screens other than the battle screen are normal screens. The normal screen includes the home screen shown in FIG. 3A, the friend character confirmation screen shown in FIG. 3B, the story screen shown in FIG. 13A described later, the quest screen shown in FIG. 3C, the event battle screen shown in FIGS. A plurality of screens such as a gacha screen, a menu screen and a shop screen are provided.

A menu bar 30 is displayed at the bottom of the display 26 on the normal screen. The menu bar 30 is provided with a plurality of operation units that can be operated (tapped) by the player. The menu bar 30 includes a home screen selection operation section 30a labeled "Home", a teammate character confirmation screen selection operation section 30b labeled "Character", a story screen selection operation section 30c labeled "Story", A quest screen selection operation section 30d marked with "quest", a gacha screen selection operation section 30e marked with "gacha", and a menu screen selection operation section 30f marked with "menu" are provided. In addition, in the menu bar 30, the operation section corresponding to each screen is highlighted so that the screen being displayed on the display 26 can be identified.

When the home screen selection operation unit 30a is tapped, the home screen shown in FIG. 3A is displayed on the display 26. FIG. Further, when the teammate character confirmation screen selection operation section 30b is tapped, the teammate character confirmation screen shown in FIG. 3B is displayed on the display 26. FIG. Further, when the story screen selection operation portion 30c is tapped, the story screen (see FIG. 13A) is displayed on the display 26. FIG. When the quest screen selection operation section 30d is tapped, the quest screen shown in FIG. 3C is displayed on the display 26. FIG. When the gacha screen selection operation unit 30 e is tapped, the gacha screen is displayed on the display 26 . When the menu screen selection operation section 30f is tapped, the menu screen is displayed on the display 26. FIG. Although detailed explanation is omitted, on the story screen, a new story is released when the player advances a main quest (see FIG. 6A) described later on the quest screen, and the player can view the released story on the story screen. can be seen from On the gacha screen, it is possible to perform a gacha lottery in which a teammate character can be obtained by lottery. Also, on the menu screen, you can check game settings and various information.

Here, in the present embodiment, the player can make friend settings, follow settings, support settings, and the like on the menu screen. In the friend settings, the player can register friends with other players. Friend registration is performed when a player sends a friend application to another player and the other player approves the friend application, or when the player approves a friend application sent from another player. When friend registration is completed, the player ID and other player IDs are associated as friends, and the other player IDs are stored in server 100 as the player's friend IDs. Note that the player ID is for identifying the player, and is assigned a different ID for each player. That is, the player ID is assigned an ID different from other player IDs. The follow setting allows a player to register to follow other players. Follow registration is performed by a player sending a follow request to another player, and does not require approval from the other player. When the follow registration is completed, the player ID is associated with another player ID, and the other player ID is stored in the server 100 as the player's follow ID.

In the support setting, the player can set a friend character owned by the player as a support character (hereinafter referred to as a support character) that can be lent to another player. Another player can borrow the support character set by the player and fight against the enemy character. Here, the player can obtain a reward by setting a support character. For example, the player can obtain in-game currency as a reward for training a friend character owned by the player.

FIG. 4 is the first diagram for explaining an example of the support setting screen. As shown in FIG. 4, on the support setting screen, support characters can be set according to the type of battle game (here, "main quest" and "guild battle", which will be described later). . The player can set up to two support characters in the support character setting area 30g labeled "main quest". However, two identical support characters cannot be set in the support character setting area 30g. In addition, the player can set up to two support characters in the support character setting area 30h labeled "Guild Battle". However, two identical support characters cannot be set in the support character setting area 30h. In the example shown in FIG. 4, the player has set two support characters in the support character setting area 30g. Also, the player has set two support characters in the support character setting area 30h. Support characters (ally characters) set in the support character setting areas 30g and 30h are saved as a part of the player information in association with their ally character IDs (hereinafter also referred to as support character IDs) with the player IDs. Player information including the support character ID is transmitted from the player terminal 1 to the server 100 and stored in the server 100 .

Each support character set in the support character setting area 30g is provided with a setting cancellation section 30i. Similarly, each support character set in the support character setting area 30h is provided with a setting canceling section 30j. The player can cancel the setting of each support character by operating the setting canceling units 30i and 30j. At this time, the association between the player ID and the support character ID is released, and the information regarding the support character ID is deleted from the player information. However, the setting of the support character cannot be canceled until a certain period of time (for example, 30 minutes) has passed since it was set. The setting canceling units 30i and 30j are in a state in which they do not accept operations from the player until a certain period of time has passed since the support character was set.

A support character set in the support character setting area 30g cannot be set in the support character setting area 30h. That is, the same support character cannot be set in the support character setting areas 30g and 30h. However, it is not limited to this, and the same support character may be set in the support character setting areas 30g and 30h. Other players can borrow the support character set by the player in the support character setting area 30g when playing a battle game of "main quest" to be described later. Also, other players can borrow the support character set by the player in the support character setting area 30h when playing a battle game of "Guild Battle", which will be described later.

For example, other players can borrow support characters set in the support character setting areas 30g and 30h from players who have completed friend registration. Similarly, the player can borrow support characters set in the support character setting areas 30g and 30h from other players who have completed friend registration. However, the support characters set in the support character setting areas 30g and 30h may be lent and borrowed between a player who has not completed friend registration and another player (non-friend). For example, the support characters set in the support character setting areas 30g and 30h may be borrowed from other players (non-friends) with whom the player has followed registration.

Also, the player can belong to a guild, which will be described later, and can borrow support characters set in the support character setting areas 30g and 30h from other players (guild members) belonging to the same guild. Similarly, guild members can borrow support characters set in the support character setting areas 30g and 30h from players belonging to the same guild.

Returning to FIG. 3A, the home screen shown in FIG. 3A corresponds to the initial screen, and a header display area 31 is provided at the top. The header display area 31 displays level information 31a indicating the player level associated with the player ID, and a stamina display bar 31b indicating the stamina of the player associated with the player ID. The player information also includes information about the level information 31a and stamina.

Note that stamina is a parameter necessary for the player to play the battle game. In this embodiment, a plurality of types of battle games are provided, and each battle game is set with a consumption value of stamina required for playing, the maximum number of times it can be executed per day, and the like. When playing a battle game in which the stamina consumption value required for playing is set, the player consumes stamina to play the battle game. can't play

Although detailed explanation is omitted, the player can obtain a predetermined value as a player experience value when winning the battle game. Each time the player experience value reaches a certain value, the player level increases. An upper limit value of stamina is set for the player level, and the upper limit value of stamina increases as the player level increases. Stamina recovers by a predetermined value (for example, 1 point) at regular intervals (for example, 5 minutes) within the range of the upper limit. The stamina display bar 31b displays the current remaining amount of stamina with respect to the upper limit of stamina so that the user can visually grasp the remaining amount of stamina.

Also, a notification selection operation section 32 may be displayed on the right end of the home screen. When an event battle, which will be described later in detail, is held, the notification selection operation section 32 marked with "event battle" is displayed during the period of the event battle.

Then, when the notification selection operation section 32 marked with “event battle” is tapped, an event battle screen (see FIGS. 9A and 11A) is displayed on the display 26 . Note that when the event battle is not being held, the notification selection operation section 32 is hidden.

A home menu 33 is displayed between the menu bar 30 and the notification selection operation section 32 on the home screen. The home menu 33 includes a shop screen selection operation section 33a labeled "Shop", a guild screen selection operation section 33b labeled "Guild", a notification screen selection operation section 33c labeled "Notice", and a "Gift ” is provided.

When the shop screen selection operation portion 33a is tapped, a shop screen (not shown) on which items can be purchased is displayed. Further, when the guild screen selection operation portion 33b is tapped, a guild search screen is displayed on the display 26. FIG.

FIG. 5A is a diagram illustrating an example of a guild search screen. FIG. 5B is a diagram illustrating an example of a guild search popup. FIG. 5C is a diagram illustrating an example of a guild formation popup.

In the game of this embodiment, a plurality of players can form a guild (group). The players who form the guild are called guild members. A player who belongs to a guild (guild member) has a player ID associated with the guild group ID (guild ID) and stored in the server 100 as a guild member ID. When logging in with a player ID that is not associated with any group ID, that is, when the player has not joined a guild, the guild screen selection operation section 33b displayed on the home screen shown in FIG. 3A is operated. When (tapped), the guild search screen shown in FIG. 5A is displayed on the display 26 .

A guild search operation section 34, an invitation list operation section 35, a guild formation operation section 36, a searched guild display area 37, and a menu bar 30 are displayed on the guild search screen.

When the guild search operation unit 34 is operated, a guild search pop-up 38 shown in FIG. 5B is displayed on the display 26 . The guild search pop-up 38 displays a guild name search tab 38a and a conditional search tab 38b. Only one of the guild name search tab 38a and the conditional search tab 38b can be selected, and the guild can be searched under conditions related to the selected guild name search tab 38a or conditional search tab 38b. The guild name search tab 38a is associated with a guild name entry field 38c for entering a guild name. The player selects the guild name search tab 38a, inputs arbitrary characters in the guild name input field 38c, and then operates the search operation section 39. FIG. Then, the information of the guild whose guild name includes any characters entered in the guild name input field 38c is displayed in the searched guild display area 37 of the guild search screen shown in FIG. 5A. On the other hand, when the cancel operation unit 40 labeled "cancel" is operated, the process corresponding to the currently displayed screen is canceled and the guild search screen shown in FIG. 5A is displayed.

The condition search tab 38b is associated with a member number selection tab 38d, an activity policy selection tab 38e, a subscription condition selection tab 38f, and a mode selection tab 38g. The number of members selection tab 38d, activity policy selection tab 38e, subscription condition selection tab 38f, and mode selection tab 38g are each selectable by the player's operation from a plurality of preset candidates. For example, in the member number selection tab 38d, four candidates of "no setting", "1 to 10 people", "11 to 20 people", and "21 to 30 people" are set. Any of these four candidates can be selected. In addition, the mode selection tab 38g has two options, "guild mode" and "single mode", and the player can select either one of these two options.

Then, the player selects the condition search tab 38b, operates the member number selection tab 38d, the activity policy selection tab 38e, the subscription condition selection tab 38f, and the mode selection tab 38g to input the search conditions. to operate. Then, the information of the guild that matches the search conditions is displayed in the searched guild display area 37 of the guild search screen shown in FIG. 5A.

The searched guild display area 37 displays information on the searched guild. Guild information includes, for example, the guild name, the number of guild members, activity policy, joining conditions, and the mode being set. After that, when any of the guild information displayed in the search guild display area 37 is operated (tapped) and a joining operation unit (not shown) is operated, joining information indicating joining the operated guild is sent to the server. 100. When the server 100 receives the joining information, the server 100 associates the group ID of the guild indicated in the joining information with the player ID of the player who performed the joining operation, and stores them in the guild information.

Further, although detailed explanation is omitted, a guild member belonging to a guild can invite a player who has not joined the guild to join the guild. When the invitation list operation unit 35 is operated on the player terminal 1 of the player invited to the guild, information on the invited guild is displayed in the searched guild display area 37 . After that, when any of the guild information displayed in the search guild display area 37 is operated (tapped) and a joining operation unit (not shown) is operated, joining information indicating joining the operated guild is sent to the server. 100. When the server 100 receives the joining information, the server 100 associates the group ID of the guild indicated in the joining information with the player ID of the player who performed the joining operation, and stores them in the guild information.

Also, a player who has not joined a guild can form (create) a guild. On the player terminal 1 of the player who has not joined the guild, when the guild formation operation section 36 is operated, the guild formation pop-up 41 shown in FIG. 5C is displayed on the display 26 .

The guild formation pop-up 41 displays a guild name input field 41a, a guild description input field 41b, an activity policy selection tab 41c, a joining condition selection tab 41d, and a mode selection tab 41e. The activity policy selection tab 41c, the subscription condition selection tab 41d, and the mode selection tab 41e are selected from a plurality of preset candidates in the same manner as the activity policy selection tab 38e, the subscription condition selection tab 38f, and the mode selection tab 38g. , can be selected by the player's operation.

Arbitrary characters are entered in the guild name input field 41a and the guild description input field 41b, and after operating the activity policy selection tab 41c, the joining condition selection tab 41d, and the mode selection tab 41e, "form" is entered. When the forming operation section 42 is operated, a new guild is formed.

For example, when one player forms (registers) a guild, the server 100 associates the group ID of the guild with the player ID of the player who formed the guild and stores it as guild information. When another player performs an operation to join the guild, the group ID of the guild and the player ID of the player who performed the joining operation are associated and stored in the guild information. In addition, the server 100 stores group information such as the guild name, selected mode, activity policy, joining conditions, number of guild members, ranking, chat contents, guild battle status, etc. for each guild (group ID). .

Returning to FIG. 3A , when the notification screen selection operation section 33 c is tapped, a notification screen (not shown) displaying update information, maintenance information, and the like is displayed on the display 26 . Further, when the gift screen selection operation portion 33d is tapped, a gift screen (not shown) displaying items distributed by the operator is displayed on the display 26, for example.

When the teammate character confirmation screen selection operation section 30b shown in FIG. 3A is tapped, the teammate character confirmation screen shown in FIG. 3B is displayed on the display . On the teammate character confirmation screen, all images of teammate characters corresponding to the teammate character ID associated with the player ID are displayed. That is, on the teammate character confirmation screen, all teammate characters possessed by the player are displayed. The teammate character ID is for identifying the teammate character, and a different ID is assigned to each teammate character. Then, when the player acquires a new ally character through, for example, a gacha lottery, the player ID of the player is associated with the ally character ID of the acquired ally character. The teammate character ID is configured as part of the player information.

Information about the experience value and information about the level are stored in association with the ally character ID. The experience value increases when the player wins a battle game, which will be described later, or when a predetermined item is used. The level is set according to the experience value, and the level rises each time the experience value reaches a predetermined value. Each ally character has an upper limit of level, and the level increases only within the range up to the upper limit.

Base values of combat power such as life points, offensive power, and defensive power are set for allied characters based on their levels. The player can progress the battle game more advantageously as the combat power of the ally character increases. Also, each base value set for an ally character increases as the level increases.

In addition, it is possible to equip (set) equipment such as weapons and armor to the ally character. Each piece of equipment is set with an additional value for attack power, defense power, and the like. When equipment is equipped, the added value of each equipment is added to the above-mentioned base value, and the fighting power of the ally character can be increased. Information related to equipment such as weapons and armor is also associated with the teammate character ID and configured as part of the player information.

Also, a party screen selection operation section 43 marked with "Party" is displayed at the right end of the teammate character confirmation screen. When the party screen selection operation section 43 is tapped, a party organization screen (not shown) is displayed on the display 26, and a party composed of up to five ally characters can be organized and saved.

When the quest screen selection operation section 30d shown in FIG. 3A is tapped, the quest screen shown in FIG. 3C is displayed on the display . The quest screen displays a plurality of game type selection operation sections 44 in which the types of provided battle games are described. Here, five types of battle games are provided, and five game type selection operation sections 44 are displayed.

The game type selection operation unit 44 includes a main quest selection operation unit 44a labeled "main quest", a guild battle selection operation unit 44b labeled "guild battle", and a 1V1 battle selection operation unit 44b labeled "1V1 battle". An operation unit 44c, a 3V3 battle selection operation unit 44d labeled "3V3 battle", and an event battle selection operation unit 44e labeled "event" are provided. The event battle selection operation section 44e is displayed while the event battle is being held, and is hidden when the event battle is not being held.

When the main quest selection operation section 44a is tapped, the main quest screen shown in FIG. 6A is displayed on the display 26. FIG. Further, when the guild battle selection operation portion 44b is tapped, a guild battle screen (not shown) is displayed on the display 26. FIG. Similarly, when the 1V1 battle selection operation section 44c is tapped, a 1V1 battle screen (not shown) is displayed on the display 26. FIG. Further, when the 3V3 battle selection operation section 44d is tapped, a 3V3 battle screen (not shown) is displayed on the display 26. FIG. Further, when the event battle selection operation portion 44e is tapped, an event battle screen (see FIGS. 9A and 11A) is displayed on the display 26. FIG.

It should be noted that some types of battle games have opening conditions. The release conditions include, for example, that the player level is a predetermined value or higher, that a specific story is being viewed from the story screen, that another predetermined battle game has been cleared, and the like. In addition, a plurality of battle games (hierarchies or rounds) belong to each battle game type. An opening condition is set for each of these battle games. Then, when the opening condition is satisfied, the game opening information included in the player information is updated.

In the player terminal 1, it is determined whether or not the battle game is released based on the game release information, and only the game type selection operation section 44 of the battle game that satisfies the release condition accepts the player's operation (tap). . Therefore, the player can only play the battle game that satisfies the opening conditions.

FIG. 6A is a diagram illustrating an example of a main quest screen. FIG. 6B is a diagram illustrating an example of a main quest selection screen. FIG. 6C is the first diagram for explaining an example of the party selection screen.

As described above, when the main quest selection operation portion 44a in the game type selection operation portion 44 shown in FIG. 3C is tapped, the main quest screen shown in FIG. 6A is displayed on the display 26. FIG.

The main quest screen displays a quest operation section 45 for selecting a plurality of battle games (hierarchies) belonging to the main quest. A menu bar 30 and a header display area 31 are also displayed on the main quest screen.

Clear information of each battle game is also displayed on the quest operation section 45 . Clear information is indicated by, for example, three stars. In the battle game belonging to the main quest, when the battle game is cleared, stars are obtained according to the number of ally characters whose life points are 0 when the battle game is cleared. For example, if there is no friendly character whose life point is 0, three stars are obtained, and if there is only one friendly character whose life point is 0, two stars are obtained. , when there are two or more allied characters whose life points are 0, one star is obtained.

In the example of FIG. 6A, 3 stars are obtained in the "1-1" battle game, 2 stars are obtained in the "1-2" battle game, and 1 star is obtained in the "1-3" battle game. has been obtained. Also, in the battle game "1-4", not even one star has been obtained, and it is reported that this battle game has not been cleared.

In addition, in the main quest, clearing the previous battle game is set as an opening condition. For example, in the example of FIG. 6A, by clearing up to the battle game "1-3", the battle game "1-4" is released, but after that ("1-5" not shown) ) battle game has not been released.

On the main quest screen, for example, when the quest operation section 45 of the battle game “1-4” is operated (tapped), the main quest selection screen shown in FIG. 6B is displayed on the display 26 . The main quest selection screen displays enemy characters appearing in the battle game and items (rewards) obtainable in the battle game. Also, on the main quest selection screen, there is a challenge operation section 46 marked "Challenge" for challenging the battle game, and a "Cancel" for canceling the process corresponding to the currently displayed screen. The written cancel operation section 40 is displayed.

When the cancel operation unit 40 is operated (tapped), the main quest screen shown in FIG. 6A is displayed on the display 26, and the challenge to the selected battle game "1-4" is canceled.

On the other hand, when the challenge operation unit 46 is operated (tapped), the party selection screen shown in FIG. 6C is displayed on the display 26. FIG. On the party selection screen, all allied characters possessed by the player are displayed, a selected friendly character display area 47 for displaying the selected friendly characters is displayed at the bottom, and "Support" is displayed at the top. A support character selection operation section 48 marked with is displayed.

The party selection screen also displays a cancel operation section 40 and a battle start operation section 49 labeled "Battle Start".

On the party selection screen, when the player operates (tap) a displayed ally character, the operated ally character is displayed in the selected ally character display area 47 . That is, here, among a plurality of teammate character IDs associated with the player ID, the teammate character ID for use in the battle game (for determining the party) is selected. A party is organized by the player selecting a plurality of ally characters. It should be noted that the same ally character cannot be duplicated in the party organization.

Further, when the support character selection operation section 48 is operated (tapped) on the party selection screen, the support character selection screen is displayed. FIG. 7 is the first diagram for explaining an example of the support character selection screen. On the support character selection screen, the support character selection operation section 48 is highlighted so that the friendly character being displayed on the display 26 can be identified as the support character.

The support character selection screen displays support characters that other players have set as support. For example, the support character selection screen displays a support character that has been set as a support by another player (hereinafter referred to as a friend player) who has completed the friend registration described above. Also, on the support character selection screen, the support characters set by the guild members as described above are displayed. Note that the support character selection screen may display a support character that has been set as a support by another player whose friend registration has not been completed (hereinafter referred to as a non-friend player). For example, the support character selection screen may display a support character that has been set as a support by another player (non-friend player) whose follow registration has been completed.

On the support character selection screen, the level of the support character is displayed below the support character. Also, the player names of other players (here, "A" to "X") are displayed below the support characters.

When the player operates (tap) the displayed support character on the support character selection screen, the operated support character is displayed in the selected teammate character display area 47 . That is, here, the support character ID for use in the battle game is selected from among the support character IDs of a plurality of support characters associated with other player IDs.

Here, in the battle game belonging to the main quest, the number of selectable support characters is limited to a first upper limit value (for example, one) or less. That is, the number of support characters that the player can borrow is limited to the first upper limit value or less. In this embodiment, the player can borrow up to one support character in a battle game belonging to a main quest or a guild battle, which will be described later. When the player borrows the selected support character, the player pays consideration (for example, in-game currency) to another player who possesses the selected support character. Other players possessing the selected support character can receive compensation from the player who selected the support character.

In this way, the player can select an ally character to be used in the battle game from among ally characters owned by the player and support characters set by other players. However, the selection of the support character is not essential, and the player does not have to select the support character. In this way, a party is organized by the player selecting an ally character from among ally characters and support characters.

When the party formation is completed and the battle start operation unit 49 is operated (tapped), the battle game is started.

FIG. 8A is a diagram illustrating an example of a battle screen. FIG. 8B is a diagram illustrating an example of a result screen. FIG. 8C is a diagram illustrating an example of a report screen. When the battle start operation unit 49 is operated (tapped) on the party selection screen shown in FIG. 6C or the support character selection screen shown in FIG. 7, the battle game is started.

During the battle game, a battle screen is displayed as shown in FIG. 8A. A friend character and an enemy character are displayed on the display 26 on the battle screen. A friend character operates under computer control, and damages an enemy character or receives damage from the enemy character. Also, the enemy character operates under computer control, and inflicts damage on the ally character or receives damage from the ally character.

When damage points are given to the enemy character, the damage points are subtracted from the life points of the enemy character. Similarly, when damage points are given to an ally character, the damage points are subtracted from the life points of the ally character. When the life points of all enemy characters become 0, the player wins (clears), and when the life points of all ally characters become 0 (defeat), the player loses.

Here, an ally character display area 50 is provided at the bottom of the battle screen, as shown in FIG. 8A. In the ally character display area 50, a life point 50a and a deathblow gauge 50b for each ally character are displayed. The deathblow gauge 50b rises when the ally character receives damage from the enemy character or damages the enemy character. Then, when the deathblow gauge 50b reaches a predetermined maximum value, the ally character can use the deathblow. A special move gives more damage points to an enemy character than a normal attack, recovers the life points of an ally character, or gives a special effect to the enemy character.

Here, two patterns are provided for the method of using the deathblow. One is a method in which the player operates (tap) a friend character displayed in the friend character display area 50 and whose deathblow gauge 50b has reached the maximum value. The other is a method in which when the deathblow gauge 50b reaches the maximum value in the auto state, the ally character uses a deathblow under computer control. Note that the battle screen displays an auto-selection operation unit 51, and the player can switch between the auto state and the manual state by operating the auto-selection operation unit 51. FIG. When the automatic selection operation unit 51 is operated in the manual state, the automatic state is entered in which the deathblow is automatically used. In addition, when the automatic selection operation section 51 is operated in the automatic state, a manual state is entered in which the deathblow is manually used. Even in the auto state, when the special move gauge 50b has reached the maximum value and the special move is not being used under computer control, if the player operates (tap) the ally character, the special move is used. is possible.

Then, when the battle game ends normally (normally ended), a result screen is displayed on the display 26 as shown in FIG. 8B. FIG. 8B shows, as an example, a result screen when a teammate character wins.

At least part of the game result information of the battle game is displayed on the result screen, and a report display operation section 52 marked with "report" and an end operation section 53 marked with "close" are displayed. be.

The game result information includes the friendly character ID (party) of the friendly character, the enemy character ID of the enemy character, the remaining status of the friendly character and the enemy character at the end of the battle (whether the life points are 0 at the end of the battle game). or not), damage points given (total value), manual state or auto state, battle log ID, battle game type (main quest, guild battle, etc.), information associated with each battle game type ( Clear information, battle game floors, etc.), granted item information, etc. are included. As for manual mode or auto mode, if the battle game is in auto mode from start to finish and the special move is not manually used by the player, it is in auto mode, otherwise it is in manual mode. Also, a battle log ID is uniquely assigned to each battle game. Also, the information associated with each type of battle game has different contents for each type of battle game.

When the end operation unit 53 is operated (tapped) on the result screen, the display of the display 26 is switched from the battle screen to the normal screen. That is, the result screen is part of the battle screen. Note that the normal screen switched from the result screen may be the screen displayed immediately before switching to the battle screen, or may be a predetermined screen such as the home screen. Thus, the battle game ends when the display of the result screen ends.

When the report display operation unit 52 is operated (tapped) on the result screen, the report screen shown in FIG. 8C is displayed on the display 26. FIG. The report screen displays the damage points (total value) inflicted by the ally character and the enemy character, as well as a post operation section 54 and an end operation section 53 labeled "Post".

Here, when the posting operation unit 54 is operated (tapped), the game result information can be posted on the guild screen (not shown). Also, when the end operation unit 53 is operated (tapped), the result screen shown in FIG. 8B is displayed on the display 26 .

Next, I will explain the guild battle. Since the guild battle is basically the same as the main quest, the description of the guild battle will be omitted, and only the differences from the main quest will be described.

A guild battle is a battle game in which the player (himself) cooperates with guild members of the guild to which the player belongs to fight powerful enemy characters. The guild battle is a game feature in which guilds compete for ranking (order) according to the total value of damage inflicted on enemy characters, that is, the game progresses on a guild-by-guild basis. Therefore, in the guild battle, if the player does not belong to any guild, the player cannot participate in the battle game (guild battle). A guild battle is held, for example, once a month for five days. Also, after the guild battle ends, items (ranking rewards) are given to each guild according to the ranking. In guild battles, all players belonging to the same guild are given ranking rewards according to their ranking.

In the guild battle, the maximum number of times the battle game can be executed per day is set to, for example, three times. Therefore, one player can execute the battle game of the guild battle three times a day at maximum.

Here, in this embodiment, every time a predetermined amount of stamina is consumed, the number of executions of the battle game of the guild battle is incremented by one, and the maximum number of executions is three. For example, every time 300 stamina is consumed, the number of executions of the guild battle battle game is incremented by one, and when 900 stamina is consumed, the maximum number of executions (3 times) is given.

When the guild battle selection operation unit 44b shown in FIG. 3C is operated, a guild battle screen (not shown) is displayed on the display 26. FIG. In the guild battle, enemy characters can be selected in a predetermined order. After defeating one enemy character, it becomes possible to fight against the next enemy character. In the guild battle, when an enemy character is defeated, a treasure box is displayed instead of the defeated enemy character. In addition, when all the enemy characters displayed on the guild battle screen are defeated, one cycle ends, the next cycle starts, and it becomes possible to again select enemy characters in order from the first one.

In the guild battle, two types of battle games are provided: a main battle game (hereinafter simply referred to as main battle) and a simulated battle game (hereinafter simply referred to as simulated battle). When the main battle is started, the number of executions of the battle game of the guild battle is consumed by one, and the ally character and the enemy character fight each other. In addition, the life points of the enemy character are reduced according to the damage points given to the enemy character by the ally character after the main battle is over. When the main battle ends, the game result information is displayed on the display 26 in the same manner as the main quest result screen. A report screen can also be displayed.

On the other hand, when the simulated battle is started, the ally character and the enemy character will battle each other without consuming the number of executions of the battle game of the guild battle. However, the damage points given to the enemy character by the ally character after the simulated battle is over are not reflected in the life points of the enemy character. Therefore, the enemy character's life points do not decrease after the simulated battle ends. In other words, the mock battle is a simulation of the main battle. The player can search for a party (combination of allied characters) that gives a large number of damage points to the enemy character by conducting a simulated battle. When the simulated battle ends, the game result information is displayed on the display 26 in the same manner as the main quest result screen. A report screen can also be displayed.

Next, the 1V1 battle and the 3V3 battle will be explained. Since the basic parts of the battle game are the same as those of the main quest, the description thereof will be omitted, and only the parts different from the main quest will be described.

A 1V1 battle is a battle game in which a party for 1V1 pre-associated with other player IDs competes. That is, each player sets a party for 1V1 in advance.

When the 1V1 battle selection operation section 44c shown in FIG. 3C is operated, a 1V1 battle screen (not shown) is displayed on the display . A plurality of parties of other players are displayed on the 1V1 battle screen, and the player selects a party to battle against. In addition, the player determines his own party and starts the battle game in the same way as the main quest. In the battle game of 1V1 battle, it is set in advance so that the player cannot switch between the auto state and the manual state, and the battle game always progresses in the auto state. Therefore, in the battle game of 1V1 battle, the deathblow cannot be used manually.

When the 1V1 battle game ends, game result information is displayed on the display 26 in the same manner as the result screen of the main quest. A report screen can also be displayed.

The 3V3 battle is a battle game in which three parties for 3V3 pre-associated with other player IDs compete against each other. That is, each player presets three parties for 3V3.

When the 3V3 battle selection operation unit 44d shown in FIG. 3C is operated, a 3V3 battle screen (not shown) is displayed on the display 26. FIG. A plurality of parties of other players are displayed on the 3V3 battle screen, and the player selects a party to battle against. Also, the player selects three of his own parties and battles them. In the battle game of 3V3 battle, the auto state is always set so that the deathblow cannot be used manually.

When the 3V3 battle game ends, game result information is displayed on the display 26 in the same manner as the main quest result screen. A report screen can also be displayed. Here, in the 3V3 battle, the first to win two games wins. Therefore, if the player wins or loses twice in succession from the first round, the third round will not be executed.

Next, the event battle will be explained. FIG. 9A is a first diagram illustrating an example of an event battle screen. FIG. 9B is a second diagram illustrating an example of a support setting screen used for event battles. FIG. 9C is the first diagram illustrating an example of the event battle selection screen. FIG. 10A is the first diagram for explaining an example of the composable character detail dialog screen 62b. FIG. 10B is a second diagram illustrating an example of the party selection screen. FIG. 10C is a second diagram for explaining an example of the support character selection screen.

In the event battle, a battle game is performed in which all the players stored in the server 100 cooperate with each other to fight a powerful enemy character (a sub-boss in this embodiment). The event battle of this embodiment is closely related to the story, and reproduces a battle game in which the main character of the story battles the main boss after a specific story. Therefore, event battles have participation conditions. In this embodiment, the participation condition is that the story screen selection operation unit 30c shown in FIG. 3A is operated and that a specific story is viewed from the story screen (the player information includes flag information indicating that the specific story has been viewed). It is set as so that players who have viewed a specific story can participate in the event battle. Therefore, players who have not seen a specific story cannot participate in the event battle.

In event battles, for example, unlike normal battle games such as main quests and guild battles (hereinafter referred to as normal battles), the types of allied characters that can participate in the battle game (parties can be formed) are limited. That is, in the event battle, only a specific kind of ally character can participate, and ally characters other than the specific kind of ally character cannot participate.

During the event battle, when the notification selection operation unit 32 indicated as "event battle" shown in FIG. 3A or the event battle selection operation unit 44e shown in FIG. 3C is operated (tapped), the operation shown in FIG. 9A An event battle screen is displayed on the display 26 .

The event battle screen displays four sub-bosses (sub-boss A, sub-boss B, sub-boss C, sub-boss D), a remaining challenge count display area 60a, a challenge count recovery time display area 60b, a support setting operation section 60c, A cumulative defeat count display area 60d is displayed.

In the present embodiment, when an event battle is held, each player is given a certain number of times to challenge a plurality of sub-bosses. For example, when each player logs in during the event battle period, each player is given the number of times that the player can challenge the sub-boss five times at the first login. An upper limit is provided for the number of challenges, and the upper limit is 5 in the present embodiment. The player executes a battle game with each sub-boss (hereinafter also referred to as a sub-boss battle), and the battle game satisfies the end condition (life points of all ally characters or sub-bosses are 0, or a certain period of time has elapsed). , 1 challenge is consumed. If the player retires in the middle of the battle game, the number of challenges is not consumed, and the damage points given to the sub-boss during the battle game are reset.

The current remaining number of challenges with respect to the upper limit of the number of challenges is displayed in the remaining number of challenges display area 60a. In the example shown in FIG. 9A, 3 (times) is displayed as the number of remaining attempts in the number of remaining attempts display area 60a.

The number of challenges is given a predetermined number of times every predetermined time. For example, the number of challenges is given three times every six hours. In the challenge count recovery time display area 60b, the remaining time until the next challenge count is granted (recovered) is displayed. In the example shown in FIG. 9A, 5 hours and 42 minutes are displayed as the remaining time until the number of challenges is given in the challenge count recovery time display area 60b.

The support setting operation section 60c is displayed on the event battle screen, and is displayed only during the event battle. When the player operates (tap) the support setting operation section 60c, the support setting screen shown in FIG. 9B is displayed. On the support setting screen, a support character setting area 61 marked with "event battle" is displayed. The player can set up to two support characters in the support character setting area 61 . In the example shown in FIG. 9B, the player has set one support character in the support character setting area 61 . The support character set in the support character setting area 61 is stored as part of the player information with the support character ID associated with the player ID. Player information including the support character ID is transmitted from the player terminal 1 to the server 100 and stored in the server 100 .

In addition, in the example shown in FIG. 9B, the support character setting area 61 displays an additional setting possible mark 61a for additionally setting a support character. The player can newly add a support character other than the support characters already set in the support character setting area 61 by operating (tapping) the additional setting possible mark 61a. In addition, in the support character setting area 61 for "event battle", the same support characters as those set in the support character setting area 30g for "main quest" and the support character setting area 30h for "guild battle" are displayed. can be set.

A support character set in the support character setting area 61 is provided with a setting cancellation portion 61b. The player can cancel the setting of the support character by operating the setting cancellation section 61b. At this time, the association between the player ID and the support character ID is released, and the information regarding the support character ID is deleted from the player information. However, the setting of the support character cannot be canceled until a certain period of time (for example, 30 minutes) has passed since it was set. The setting canceling unit 61b is in a state in which it does not accept an operation from the player until a certain period of time has passed since the support character was set. When the event battle ends, the support characters set in the support character setting area 61 are automatically canceled.

Other players can borrow the support character set by the player in the support character setting area 61 when playing the "event battle" battle game. For example, other players (guild members, friend players, non-friend players) can borrow support characters set in the player's support character setting area 61 . Similarly, the player can borrow a support character set in the support character setting area 61 of another player (guild member, friend player, non-friend player).

In this embodiment, when an event battle is held, a plurality of sub-bosses are displayed as shown in FIG. 9A, and a sub-boss battle is started in which all players face each sub-boss. Destruction conditions are set for each sub-boss, and even if the sub-boss is defeated by the player, the sub-boss is revived until the number of times it has been defeated (hereinafter also referred to as the number of subjugations) reaches a specified number of times. Here, the number of subjugations is a value common to all players participating in the event battle, and the server 100 manages this value (the number of subjugations) during the period of the event battle. When each sub-boss is defeated by the player a specified number of times, the conditions for its disappearance are satisfied and it disappears. Specifically, the server 100 counts the number of times each sub-boss has been defeated by all players participating in the event battle. Then, the server 100 determines whether or not each sub-boss has been subjugated a specified number of times (that is, whether the sub-boss elimination condition has been satisfied), and the sub-boss has been subjugated the specified number of times (destruction condition is satisfied), an effect process is executed to eliminate the sub-boss.

Therefore, as shown in FIG. 9A, below each sub-boss, a cumulative defeat count display area 60d is displayed. In the cumulative defeat number display area 60d, for example, a defeat remaining number display bar indicating the number of remaining defeats until each sub-boss disappears is displayed. However, the present invention is not limited to this, and the total number of times sub-bosses have been defeated may be displayed in the cumulative number of sub-bosses display area 60d. In addition, when the difference between the specified number of times and the total number of times of subjugation becomes less than a predetermined value, a notation indicating that the total number of times of subjugation is unknown may be used so that the remaining number of times of subjugation cannot be known.

When the remaining number of subjugation display bar displayed in the cumulative number of subjugation display area 60d reaches 0 (that is, the cumulative number of subjugations reaches a specified number), the sub-boss disappears, and the sub-boss disappears from the event battle screen. Occur. Also, in the cumulative defeat count display area 60d, there is a notation indicating that the sub-boss has disappeared. For example, after the sub-boss disappears, the text "Defense Successful" is displayed in the cumulative defeat count display area 60d.

The player can freely fight against any of the four sub-bosses. In this embodiment, the types of allied characters that can participate in each sub-boss battle are different types. For example, an ally character that can participate in the sub-boss A battle game cannot participate in the sub-boss B, sub-boss C, and sub-boss D battle games. However, it is not limited to this, and the types of allied characters that can participate in each sub-boss battle may be partially common.

On the event battle screen, for example, when "sub-boss A" is operated (tapped), the event battle selection screen shown in FIG. 9C is displayed on the display 26. FIG. The event battle selection screen displays enemy characters (sub-boss A) appearing in the battle game and items (rewards) obtainable in the battle game. Also, on the event battle selection screen, a composable character display section 62, a challenge operation section 46 for challenging the battle game, and a cancel operation section 40 are displayed.

The composable character display portion 62 displays some of the ally characters who can participate in the battle game of the selected sub-boss (here, sub-boss A). In the example shown in FIG. 9C, among allied characters who can participate in the sub-boss A battle game, four (four types) of allied characters are displayed in ascending order of the numbers of the allied character IDs. The composable character display section 62 is provided with a detailed display operation section 62a. The player can cause the display 26 to display the composable character details dialogue screen 62b shown in FIG. 10A by operating the details display operation section 62a. All ally characters who can participate in the battle game of the selected sub-boss (here, sub-boss A) are displayed on the composable character detail dialog screen 62b.

As shown in FIG. 10A, a total of eight friendly characters (8 types in total) are displayed on the composable character detail dialog screen 62b. Only allied characters displayed on the composable character detail dialog screen 62b can participate in the sub-boss A battle game. In other words, in the sub-boss A battle game, allied characters that are not displayed on the composable character detail dialog screen 62b cannot participate. The same applies to sub-boss B, sub-boss C, and sub-boss D battle games.

Returning to FIG. 9C, when the cancel operation unit 40 is operated (tapped), the event battle screen shown in FIG. 9A is displayed on the display 26, and the selected "sub-boss A" battle game challenge is canceled. .

On the other hand, when the challenge operation unit 46 is operated (tapped), the party selection screen shown in FIG. 10B is displayed on the display 26. FIG. On the party selection screen, all ally characters possessed by the player are displayed, a selected ally character display area 47 is displayed at the bottom, and a support character selection operation section 48 is displayed at the top. A cancel operation section 40 and a battle start operation section 49 are also displayed on the party selection screen.

When the player operates (tap) a displayed ally character on the party selection screen, the operated ally character is displayed in the selected ally character display area 47, and a party is organized. It should be noted that the player is required to organize at least one ally character owned by himself/herself when forming a party for the event battle.

Here, as shown in FIG. 10B, on the party selection screen, only friendly characters who can participate in the battle game of the selected sub-boss are displayed so as to be organized, and friendly characters who cannot participate in the battle game of the selected sub-boss are Displayed as non-organizable. In the example shown in FIG. 10B, a total of 8 types of friendly characters that can participate in the sub-boss A battle game (that is, the 8 types of friendly characters displayed on the composable character detail dialog screen 62b shown in FIG. 10A) can be selected. Is displayed. Also, ally characters that cannot participate in the battle game of sub-boss A are displayed as "Unorganized" in FIG.

Therefore, the player organizes a party to be used in the sub-boss A battle game from among the eight types of friendly characters that can be selected. In this way, in the event battle, the party formation used for the battle game of each sub-boss is restricted.

Further, when the support character selection operation section 48 is operated (tapped) on the party selection screen, the support character selection screen shown in FIG. 10C is displayed. The support character selection screen displays support characters set by other players (guild members, friend players, non-friend players) in the support character setting area 61 of the "event battle".

Here, the support characters displayed on the support character selection screen do not display friendly characters that cannot participate in the battle game of the selected sub-boss, and only friendly characters that can participate in the battle game of the selected sub-boss are displayed. be. In other words, the support characters displayed on the support character selection screen are filtered according to the battle game restrictions of each sub-boss. For example, in the example shown in FIG. 10C, among the support characters set in the support character setting area 61 by other players, allied characters who cannot participate in the sub-boss A battle game are excluded and can participate in the sub-boss A battle game. Only friendly characters are displayed.

Thus, the types of friendly characters that can participate in each sub-boss battle are different from each other. Therefore, there may be a case where the type of ally character selected by the player who can participate in the sub-boss battle does not match the type of support character set for the event battle by another player. Here, if a large number of support characters that cannot participate in the sub-boss battle are displayed on the player's support character selection screen, the support character selection screen becomes difficult to see. Only characters are displayed on the player's support character selection screen, and the types of support characters displayed on the support character selection screen are limited. Therefore, if the types of support characters set by other players are biased, the number of support characters displayed on the player's support character selection screen may be less than the predetermined number. As a result, the support characters that the player can borrow from other players when playing the sub-boss battle are limited, and there is a risk that the range of strategies for the sub-boss battle will be reduced.

Therefore, in this embodiment, when the number of support characters displayed on the player's support character selection screen is less than a predetermined number, event battles (sub-boss battles, main boss battles to be described later) among allied characters available to the player An ally character that can participate in is added as a general-purpose character. Although the details will be described later, before the event battle is held, the operator selects a plurality of types of general-purpose characters that can participate in the event battle (sub-boss battle, main boss battle to be described later) among allied characters that can be acquired by the player, and prepares them in advance on the server 100 . is set to In addition, the operator sets a non-player character (hereinafter referred to as NPC) different from the player in the server 100, and the general-purpose character described above is set as a support character that the player can borrow from the NPC. However, the operator is not limited to this, and the operator is a friendly character that cannot be obtained by the player, and can participate in the event battle (sub-boss battle, main boss battle described later). A plurality of types may be set in the server 100 . In that case, a general-purpose character dedicated to the event battle is set as a support character that the player can borrow from the NPC. As a result, the number of support characters displayed on the support character selection screen can be increased, and the range of strategies for sub-boss battles can be expanded.

When the player operates (tap) the displayed support character on the support character selection screen, the operated support character is displayed in the selected teammate character display area 47 . In the event battle, even if the player borrows the selected support character, it is not necessary to pay consideration (for example, in-game currency) to other players. Also, other players who own the selected support character cannot obtain compensation from the player even if the set support character is borrowed by the player. In other words, the support character set in the support character setting area 61 for "event battle" can be lent and borrowed between the player and other players free of charge.

Here, in a battle game belonging to an event battle, the number of selectable support characters is limited to a second upper limit value (for example, four) or less. That is, the number of support characters that the player can borrow is limited to the second upper limit value or less. In this embodiment, a player can borrow up to four support characters in a battle game belonging to an event battle. However, the present invention is not limited to this, and the number of support characters (second upper limit) that the player can borrow may be changed according to, for example, the type of sub-boss or the main boss (to be described later). In other words, the number of support characters that the player can borrow in event battles is greater than the number of support characters that can be borrowed in normal battles.

Therefore, even if the types of allied characters that can be formed in the event battle are limited, the player can easily form a party because the number of support characters that can be selected is greater than in the normal battle. When the party formation is completed and the battle start operation unit 49 is operated (tapped), the battle game is started. Since the basic part of the battle game is the same as the main quest, its explanation will be omitted, and the parts different from the main quest will be explained.

In the main quest battle game, the player's stamina is consumed to play the battle game, while in the sub-boss battle, the player's stamina is not consumed, and the battle game is played by consuming the number of challenges given to the player. . Also, in the battle game of the main quest, if the life points of the enemy character cannot be reduced to 0 in one battle game, the damage points given to the enemy character by the ally character are reset. Therefore, even if the player fights against the same enemy character again, the damage points inflicted on the enemy character are reset to zero. On the other hand, in each sub-boss battle game, even if the life points of the sub-boss cannot be reduced to 0 in one battle game, the damage points given by the ally character to the enemy character are continued. In other words, when the player fights against the same sub-boss again, the game starts with the damage points from the previous fight.

In addition, there are two types of rewards for the sub-boss battle game: a reward for subjugating one sub-boss and a disappearance reward for defeating (that is, disappearing) the sub-boss a specified number of times. The reward for subjugating one sub-boss is a reward that can be obtained only by the player who has subjugated one sub-boss. The player can obtain a sub-boss subjugation reward each time he subjugates one sub-boss. However, even if another player subjugates one sub-boss, the player cannot obtain the reward for subjugating one sub-boss. The disappearance reward is a common reward that can be obtained by all players who access the event battle screen during the event battle after the sub-boss disappears.

The event battle includes a sub-boss battle in which the sub-boss is fought, and a battle game in which the main boss is fought (hereinafter also referred to as a main-boss battle). The main boss battle is displayed on the event battle screen when all the sub-bosses have been subjugated (disappeared) in the sub-boss battle, or when a certain period of time has passed since the start of the event battle. In other words, the player cannot fight the main boss until all the sub-bosses have been subjugated (disappeared) in the sub-boss battle, or a certain period of time has elapsed since the start of the event. In addition, if sub-bosses remain after a certain period of time has passed since the start of the event, an event will occur in which all remaining sub-bosses will be forcibly destroyed, and after all sub-bosses have disappeared, the main boss will appear. An event occurs.

FIG. 11A is a second diagram illustrating an example of an event battle screen. FIG. 11B is a third diagram illustrating an example of a support setting screen used for event battles. FIG. 11C is a second diagram illustrating an example of the event battle selection screen. FIG. 12A is a second diagram illustrating an example of the composable character detail dialog screen 62c. FIG. 12B is a third diagram for explaining an example of the party selection screen. FIG. 12C is a third diagram for explaining an example of the support character selection screen.

FIG. 11A shows the event battle screen after all the sub-bosses have been defeated (disappeared) in the sub-boss battle, or after a certain period of time has passed since the start of the event. On the event battle screen, one main boss is displayed, and a remaining challenge count display area 60a, a support setting operation section 60c, and a life point display bar 63 are also displayed.

Unlike the sub-boss battle, in the main-boss battle, the player individually fights against the main boss. In other words, in the main boss battle, all players cannot cooperate with each other to fight against the main boss.

In this embodiment, when the main boss battle is started, each player is given an unlimited number of challenges to the main boss. Therefore, characters indicating that the number of challenges is infinite are displayed in the remaining number of challenges display area 60a. In addition, since the number of challenges is infinite, the event battle screen of the main boss battle shown in FIG. 11A does not display the challenge count recovery time display area 60b that was in the event battle screen of the sub-boss battle shown in FIG. 9A. there is

The support setting operation section 60c is displayed on the event battle screen of the main boss battle shown in FIG. 11A as well as the event battle screen of the sub-boss battle shown in FIG. 9A. When the support setting operation unit 60c is operated (tapped), a support setting screen shown in FIG. 11B is displayed. A support character setting area 61 is displayed on the support setting screen. The player can set up to two support characters in the support character setting area 61 in the same way as the support setting screen for the sub-boss battle shown in FIG. 9B. In addition, the support character set in the support character setting area 61 is provided with a setting cancellation portion 61b. In the "event battle" support character setting area 61, the same support characters as those set in the "main quest" support character setting area 30g and the "guild battle" support character setting area 30h are set. It is possible to

Also in the main boss battle, other players can borrow the support character set by the player in the support character setting area 61 when playing the "event battle" battle game. Similarly, the player can borrow a support character set in the support character setting area 61 of another player (guild member, friend player, non-friend player).

As shown in FIG. 11A, a life point display bar 63 is displayed below the main boss. Each player can defeat the main boss by setting the life point of the main boss to 0 in the main boss battle. In other words, the victory condition for each player is to set the life point (life point display bar 63) of the main boss to zero.

In this embodiment, the player is restricted in forming a party in the main boss battle as well as in the sub-boss battle. The types of friendly characters that can participate in the main boss battle are different from the types of friendly characters that can participate in each sub-boss battle. For example, the types of friendly characters that can participate in the main boss battle are different from the types of friendly characters that can participate in sub-boss A, sub-boss B, sub-boss C, and sub-boss D. In other words, the types of friendly characters that can participate in the sub-boss A, sub-boss B, sub-boss C, and sub-boss D battle games cannot participate in the main boss battle. However, it is not limited to this, and the types of allied characters that can participate in the main boss battle may be partly common to each sub-boss battle.

When the "main boss" is operated (tapped) on the event battle screen, the event battle selection screen shown in FIG. 11C is displayed on the display 26. FIG. The event battle selection screen displays enemy characters (main bosses) appearing in the battle game and items (rewards) obtainable in the battle game. Also, on the event battle selection screen, a composable character display section 62, a challenge operation section 46 for challenging the battle game, and a cancel operation section 40 are displayed.

A part of allied characters who can participate in the main boss battle are displayed in the composable character display section 62 . In the example shown in FIG. 11C, among allied characters who can participate in the main boss battle, four (four types) of allied characters are displayed in ascending order of the numbers of the allied character IDs. The composable character display section 62 is provided with a detailed display operation section 62a. The player can cause the display 26 to display the composable character details dialog screen 62c shown in FIG. 12A by operating the details display operation section 62a. All allied characters who can participate in the main boss battle are displayed on the composable character detail dialog screen 62c.

As shown in FIG. 12A, a total of eight friendly characters (8 types in total) are displayed on the composable character detail dialog screen 62c. Only allied characters displayed on the composable character detail dialog screen 62c can participate in the main boss battle. In other words, allied characters that are not displayed on the compatable character detail dialog screen 62c cannot participate in the main boss battle. As described above, in the main boss battle, friendly characters that can participate in sub-boss battles cannot participate. Therefore, the types of teammate characters displayed on the composeable character details dialog screen 62c shown in FIG. 12A are different from the types of teammate characters displayed on the composeable character details dialog screen 62b shown in FIG. 10A.

Returning to FIG. 11C, when the cancel operation unit 40 is operated (tapped), the event battle screen shown in FIG. 11A is displayed on the display 26, and the selected "main boss" battle game challenge is canceled.

On the other hand, when the challenge operation unit 46 is operated (tapped), the party selection screen shown in FIG. 12B is displayed on the display 26. FIG. On the party selection screen, all ally characters possessed by the player are displayed, a selected ally character display area 47 is displayed at the bottom, and a support character selection operation section 48 is displayed at the top. A cancel operation section 40 and a battle start operation section 49 are also displayed on the party selection screen.

When the player operates (tap) a displayed ally character on the party selection screen, the operated ally character is displayed in the selected ally character display area 47, and a party is organized. In the main boss battle, unlike the sub-boss battle, it is necessary to organize specific ally characters possessed by the player into the party. The specific teammate character is, for example, a teammate character distributed when the player logs into the game provided by the game device G for the first time. As in the sub-boss battle, the player needs to organize at least one friendly character that he/she owns in forming a party.

Here, as shown in FIG. 12B, on the party selection screen, allied characters who can participate in the main boss battle are displayed as organizable, and ally characters who cannot participate in the main boss battle are displayed as unorganizable. In the example shown in FIG. 12B, all eight types of friendly characters that can participate in the main boss battle (that is, the eight types of friendly characters displayed in the composable character detail dialog screen 62c shown in FIG. 12A) are displayed in a selectable manner. . Also, ally characters that cannot participate in the main boss battle are displayed as "unorganized" in FIG. 12B, and are not allowed to be selected by the player.

Therefore, the player organizes a party to be used in the main boss battle from among eight types of friendly characters that can be selected. Here, teammate characters who are allowed to participate on the party selection screen shown in FIG. 10B are not organized (unable to participate) on the party selection screen shown in FIG. 12B. Conversely, ally characters that are not allowed to be formed (cannot participate) on the party selection screen shown in FIG. 10B can participate on the party selection screen shown in FIG. 12B.

Further, when the support character selection operation section 48 is operated (tapped) on the party selection screen, the support character selection screen shown in FIG. 12C is displayed. The support character selection screen displays support characters set by other players (guild members, friend players, non-friend players) in the support character setting area 61 of the "event battle".

Here, the support characters displayed on the support character selection screen are limited to only friendly characters who can participate in the main boss battle, without displaying friendly characters who cannot participate in the main boss battle. In other words, the support characters displayed on the support character selection screen are filtered according to the main boss battle restrictions. For example, in the example shown in FIG. 12C, among the support characters set in the support character setting area 61 by other players, friendly characters who cannot participate in the main boss battle are excluded, and only friendly characters who can participate in the main boss battle are displayed. be done.

In this way, in the main battle, the types of support characters displayed on the support character selection screen are limited. Therefore, as described above, the number of support characters displayed on the support character selection screen is likely to be less than the predetermined number, and there is a risk that the strategic range for the main boss battle will be reduced. Therefore, in the present embodiment, similar to the content described above, when the number of support characters displayed on the player's support character selection screen is less than a predetermined number, a general purpose character capable of participating in a plurality of types of main boss battles set in advance is used. Characters are added. As a result, the number of support characters displayed on the support character selection screen can be increased, and the range of strategies for the main boss battle can be expanded.

When the player operates (tap) the displayed support character on the support character selection screen, the operated support character is displayed in the selected teammate character display area 47 .

In the main boss battle, as in the sub-boss battle, the number of support characters to be selected is limited to a second upper limit value (for example, 4 characters) or less. Specifically, the number of support characters that the player can borrow is limited to the second upper limit value or less. In the main boss battle, the player can borrow up to four support characters. That is, the number of support characters that the player can borrow in event battles (second upper limit) is greater than the number of support characters that can be borrowed in normal battles (first upper limit).

Therefore, even if the types of allied characters that can be formed in the event battle are limited, the player can easily form a party because the number of support characters that can be selected is greater than in the normal battle. When the party formation is completed and the battle start operation unit 49 is operated (tapped), the battle game is started. Since the basic part of the battle game is the same as the sub-boss battle, its explanation is omitted. Unlike sub-boss battles, the main boss battle can be challenged an unlimited number of times and does not require stamina to be consumed, so the player can challenge the main boss battle any number of times until the victory conditions are met.

When the event battle period ends, the notification selection operation section 32 shown in FIG. 3A and the event battle selection operation section 44e shown in FIG. 3C are hidden, and the player cannot access the event battle screen. Therefore, a player who could not log in to the game during the event battle period or a player who could not beat the main boss during the event battle period would lose the opportunity to challenge the main boss battle.

Therefore, in this embodiment, after the end of the event battle holding period, the player who has seen the above-described specific story from the story screen is given an opportunity to challenge the main boss battle. However, a player who has already won the main boss battle is not given an opportunity to challenge the main boss battle again.

FIG. 13A is a diagram illustrating an example of a story screen. FIG. 13B is a diagram illustrating an example of the main story screen. When the story screen selection operation portion 30c displayed on the home screen shown in FIG. 3A is operated (tapped), the story screen shown in FIG. 13A is displayed on the display 26. FIG.

As shown in FIG. 13A, a story selection display area 64 is displayed on the story screen. Also, in the story selection display area 64, a main story selection operation section 64a and a character story selection operation section 64b are displayed.

When the main story selection operation section 64a is operated, the main story screen shown in FIG. 13B is displayed on the display 26. FIG. As shown in FIG. 13B, a main story selection display area 64c and a battle selection operation section 64d are displayed on the main story screen. The main story selection display area 64c displays a plurality of main stories that are unlocked according to the progress of the above-described "main quest". In this embodiment, five main stories, "Story 1", "Story 2", "Story 3", "Story 4", and "Story 5" are displayed in the main story selection display area 64c. The player can view the contents of each main story by performing a selection operation on each main story. Here, opening conditions are set for each main story. The opening conditions are that the main story to be viewed will be unlocked by viewing the main story that precedes the main story to be viewed, and by clearing the specific target main quest. It's becoming It is assumed that "Story 1", which does not have a previous main story, is open from the beginning. For example, in the example of FIG. 13A, the main story of "Story 5" is unlocked when the player sees all the main stories of "Story 1" to "Story 4".

The battle selection operation section 64d is displayed for players who have not won the main boss battle and who have seen a specific main story ("Story 5" in this embodiment) after the event battle holding period ends. . Here, the player information includes flag information indicating whether or not the main boss battle has been won, and flag information indicating whether or not a specific main story (for example, "Story 5") has been viewed. The server 100 can judge and decide whether or not to display the battle selection operation section 64d based on the player information including the flag information. When the battle selection operation section 64d is operated, the event battle screen shown in FIG. 11A is displayed on the display 26. FIG. However, since the event battle holding period has ended, the support setting operation section 60c for "event battle" shown in FIG. 11A is not displayed.

Since the basic part of the main boss battle after the end of the event battle holding period is the same as the main boss battle described above, the explanation thereof will be omitted. On the support character selection screen shown in FIG. 12C, support characters set in the support character setting area 30g (see FIG. 4) for the "main quest" by other players (guild members, friend players, non-friend players) are displayed. Is displayed. At this time, the support characters displayed on the support character selection screen shown in FIG. 12C are filtered according to the restrictions of the main boss battle as described above.

On the other hand, when the character story selection operation section 64b is operated, the display 26 displays character stories (not shown) that are released according to the degree of intimacy with the ally character. The friendliness of the ally character increases when the player wins the battle game described above, or when a predetermined item is used. The rank of intimacy increases each time the intimacy reaches a predetermined value. Note that an upper limit value is set for the rank of intimacy for the ally character, and the rank increases only within the range up to the upper limit value. When the friend character's intimacy reaches the upper limit, all character stories for that friend character are released.

As described above, in a battle game in which the types of allied characters that can participate are limited, the support character selection screen excludes allied characters that cannot participate in the battle game, and displays only allied characters that can participate in the battle game. be done.

Therefore, the support characters displayed on the support character selection screen are limited to ally characters who cannot participate in the battle game, and the situation in which the player cannot borrow a support character is avoided. According to this embodiment, the player can borrow the support character displayed on the support character selection screen even in a battle game in which the types of friendly characters that can participate are limited.

In addition, in a battle game in which the types of allied characters that can participate are limited, if the number of support characters displayed on the support character selection screen is less than a predetermined number, it is possible to participate in that battle game, as will be described later in detail. Generic characters are added.

Therefore, the player can easily organize a party even in a battle game in which the types of friendly characters that can participate are limited. Thus, according to the information processing system S of the present embodiment, it is possible to expand the strategic range of the battle game.

By the way, as described above, the player can acquire a new ally character by, for example, a gacha lottery. However, if the gacha lottery is biased, the types of allied characters possessed by the player are also biased. As a result, it may be difficult for the player to clear the battle game in which the types of friendly characters that can participate are limited, using only the friendly characters owned by the player.

Therefore, in the present embodiment, the number of support characters that can be borrowed in a battle game in which the types of friendly characters that can participate is limited is changed to the number of support characters that can be borrowed in a normal battle in which the types of friendly characters that can participate are not limited. set more than

As a result, even in a battle game in which the types of allied characters that can participate are limited, by borrowing a large number of support characters, it becomes easier for the player to optimally organize the party, and the battle game can proceed advantageously. become able to. Thus, according to the information processing system S of the present embodiment, it is possible to expand the strategic range of the battle game.

Next, the basic configuration and communication processing of the player terminal 1 and the server 100 for executing the event battle will be described. Here, basic communication processing for progressing the game and an example of main communication processing relating to event battles will be described, and description of other processing will be omitted.

(Functional Configuration of Player Terminal 1)
FIG. 14 is a diagram for explaining the configuration of the memory 12 in the player terminal 1 and its functions as a computer. The memory 12 is provided with a program storage area 12a and a data storage area 12b. When the game is started, the CPU 10 stores a terminal-side game control program (module) in the program storage area 12a.

The terminal-side game control program includes a game execution control program 80, a battle game execution program 81, a player information storage program 82, a group information storage program 83, a list information storage program 84, a support character setting program 85, a party formation program 86, A display control program 87 is included. Note that the programs listed in FIG. 13 are only examples, and many other programs are provided in the terminal-side game control program.

In the data storage area 12b, as storage units for storing data, a game information storage unit 90, a player information storage unit 91, a group information storage unit 92, a list information storage unit 93, a support character information storage unit 94, and party organization information storage. A portion 95 is provided. The storage units described above are only examples, and the data storage area 12b is provided with a large number of other storage units.

The CPU 10 operates each program stored in the program storage area 12a and updates the data in each storage section of the data storage area 12b. Then, the CPU 10 causes the player terminal 1 (computer) to function as the terminal-side game control section 1A by operating each program stored in the program storage area 12a. The terminal-side game control section 1A includes a game execution control section 80a, a battle game execution section 81a, a player information storage section 82a, a group information storage section 83a, a list information storage section 84a, a support character setting section 85a, a party formation section 86a, a display It includes a control unit 87a.

Specifically, the CPU 10 operates the game execution control program 80 to cause the computer to function as the game execution control section 80a. Similarly, the CPU 10 operates a battle game execution program 81, a player information storage program 82, a group information storage program 83, a list information storage program 84, a support character setting program 85, a party organization program 86, and a display control program 87. It functions as a battle game execution unit 81a, a player information storage unit 82a, a group information storage unit 83a, a list information storage unit 84a, a support character setting unit 85a, a party formation unit 86a, and a display control unit 87a.

The game execution control section 80a controls the progress of the entire game. The game execution control unit 80a transmits login information to the server 100, for example, when logging into the game. Further, the game execution control unit 80a receives the game information from the server 100 and stores it in the game information storage unit 90 when the game information of the game in general is updated.

The battle game executing section 81a is responsible for controlling the execution of the battle game. For example, the battle game execution unit 81a updates the battle screen, controls the actions of the ally characters and enemy characters, and derives damage points based on operations input to the player terminal 1. FIG.

The player information storage unit 82 a stores the player information received from the server 100 in the player information storage unit 91 . Further, when the player information is changed according to the player's operation, the player information storage unit 82a stores the changed player information in the player information storage unit 91 and transmits the changed player information to the server 100. . Here, the player information includes a player ID, an ally character ID, a support character ID, a friend ID, a follower ID (non-friend ID), and the like. The player information also includes flag information indicating whether or not the player has won the main boss battle, flag information indicating whether or not the player has viewed a specific story, and the like. Thereby, the server 100 can determine whether or not each player satisfies the conditions for participation in the event battle (main boss battle) based on the player information of each player.

The group information storage unit 83 a stores the group information received from the server 100 in the group information storage unit 92 . Further, when the group information is changed according to the player's operation, the group information saving section 83a saves the changed group information in the group information storage section 92 and transmits the changed group information to the server 100. . Here, the group information includes a guild group ID (guild ID) associated with the player ID, a guild member ID, and the like. Note that the group information may store a friend ID registered as a friend with a player or a follow ID registered as a follower.

The list information storage unit 84a stores list information about support characters that can be borrowed by the player, received from the server 100, in the list information storage unit 93. FIG. Here, the list information includes information on support characters that the player can borrow when forming a party. Although details will be described later, the list information includes first list information of support characters that the player can borrow from other players in a normal battle (first battle game) in which the types of friendly characters that can participate are not limited. In addition, the list information includes allied characters that cannot participate in the event battle among the support characters that the player can borrow from other players in an event battle (second battle game) in which the types of allied characters that can participate are limited. contains the excluded second list information.

The support character setting unit 85a sets the support character of the player based on the player's input operation to the support character setting areas 30g, 30h, and 61. FIG. Further, the support character setting unit 85 a stores information about the set support character (support character information: support character ID) in the support character information storage unit 94 and transmits the information to the server 100 .

The party organization unit 86a organizes a party based on the player's input operation on the party selection screen. The party organization unit 86a also stores information (party organization information: teammate character ID and support character ID) on the organized party in the party organization information storage unit 95 and transmits the information to the server 100. FIG.

The display control unit 87a generates a screen to be displayed on the display 26 and causes the display 26 to display the generated screen.

(Functional Configuration of Server 100)
FIG. 15 is a diagram for explaining the configuration of the memory 112 in the server 100 and its functions as a computer. The memory 112 is provided with a program storage area 112a and a data storage area 112b. When the game is started, the CPU 110 stores a server-side game control program (module) in the program storage area 112a.

The server-side game control programs include a game execution control program 180, a battle game execution program 181, a player information storage program 182, a group information storage program 183, a list generation program 184, a support character information storage program 185, and a party organization information storage program. 186, a rewarding program 187 is included. The programs listed in FIG. 15 are only examples, and many other programs are provided in the server-side game control program.

In the data storage area 112b, a game information storage section 190, a player information storage section 191, a group information storage section 192, a list information storage section 193, a support character information storage section 194, and party formation information storage are stored as storage sections for storing data. A portion 195 is provided. The storage units described above are only examples, and the data storage area 112b is provided with a large number of other storage units.

The CPU 110 operates each program stored in the program storage area 112a and updates the data in each storage section in the data storage area 112b. Then, the CPU 110 causes the server 100 to function as the server-side game control section 100A by operating each program stored in the program storage area 112a. The server-side game control unit 100A includes a game execution control unit 180a, a battle game execution unit 181a, a player information storage unit 182a, a group information storage unit 183a, a list generation unit 184a, a support character information storage unit 185a, and a party formation information storage unit 186a. , and a reward granting unit 187a.

Specifically, the CPU 110 operates the game execution control program 180 and causes the computer to function as the game execution control section 180a. Similarly, the CPU 110 operates a battle game execution program 181, a player information storage program 182, a group information storage program 183, a list generation program 184, a support character information storage program 185, a party organization information storage program 186, and a reward giving program 187. , a battle game execution unit 181a, a player information storage unit 182a, a group information storage unit 183a, a list generation unit 184a, a support character information storage unit 185a, a party formation information storage unit 186a, and a reward provision unit 187a.

The game execution control section 180a controls the progress of the entire game. For example, when the login information is received from the player terminal 1, the game execution control unit 180a stores the player information stored in the player information storage unit 191, the group information stored in the group information storage unit 192, and the support character information storage unit 194. The saved support character information and the party formation information saved in the party formation information storage unit 195 are transmitted to the player terminal 1 . Further, when the game information of the game in general is updated, the game execution control section 180 a reads out the updated game information from the game information storage section 190 and transmits it to the player terminal 1 . The game information includes, for example, event information related to the event battle described above, and information related to the upper limit of the number of selectable support characters (first upper limit and second upper limit) in the battle game (regular battle and event battle). be The event information includes information about the types (ally character IDs) of ally characters who cannot participate in the above-described event battles (sub-boss battles, main boss battles).

The battle game execution unit 181a is responsible for controlling the execution of the battle game. The battle game execution unit 181a uses ally characters formed into a party by the player to perform a first battle game in which the types of ally characters who can participate are not limited, or a second battle in which the types of ally characters who can participate are limited. run the game. In this embodiment, the battle game execution unit 181a counts the number of times each sub-boss is defeated during the event battle period. For example, when any of sub-boss A, sub-boss B, sub-boss C, and sub-boss D is defeated by all the players participating in the event battle, the battle game execution unit 181a increments the defeated sub-boss by 1. The number of defeats of each sub-boss is stored in the game information storage section 190 and managed by the battle game execution section 181a. Then, the battle game execution unit 181a compares the number of defeats of each sub-boss with the prescribed number set for each sub-boss, and determines whether or not the number of defeats has reached the prescribed number. The battle game execution unit 181a revives (survives) each sub-boss when the number of subjugations has not reached the specified number of times, and eliminates each sub-boss when the number of subjugations has reached the specified number of times.

Upon receiving player information (for example, game result information) from the player terminal 1 , the player information storage unit 182 a stores the received player information in the player information storage unit 191 .

The group information storage unit 183 a stores the group information received from the player terminal 1 in the group information storage unit 192 .

The list generating unit 184a generates a list of support characters that can be borrowed by the player playing the battle game. For example, the list generation unit 184a creates a list of support characters (support character IDs) that can be borrowed from other players when the player plays a normal battle (that is, a first battle game that does not impose party formation restrictions) (hereinafter referred to as (referred to as the first list). In addition, the list generation unit 184a creates a list of support characters (support character IDs) that can be borrowed from other players when the player plays an event battle (that is, a second battle game with party organization restrictions) (hereinafter referred to as second list). Note that the second list is a list of support characters (support character IDs) excluding the types of allied characters that cannot participate in the event battle. After generating the first list or the second list, the list generator 184 a transmits the generated list information (first list information, second list information) to the player terminal 1 and stores it in the list information storage unit 193 .

Specifically, first, the list generating unit 184a selects the type of battle game selected by the player (for example, the type of normal battle, or the type of bosses appearing in event battles (sub-boss A, sub-boss B, sub-boss C, sub-boss D, Identify the main boss)). Next, the list generation unit 184a extracts support character information set according to the identified battle game type from the support character information stored in the support character information storage unit 194. FIG. The list generator 184a also identifies friend IDs, follow IDs (non-friend IDs), and guild member IDs associated with the player ID from the player information and group information. Then, the list generation unit 184a extracts support character IDs associated with the friend ID, follow ID, and guild member ID from the extracted support character information.

When generating the first list (first list information), the list generation unit 184a sets according to the type of normal battle (main quest, guild battle) from the support character information stored in the support character information storage unit 194. Extract the supported character ID. The list generation unit 184a also identifies the friend ID, follow ID, and guild member ID associated with the player ID. Then, the list generation unit 184a extracts support character IDs associated with the friend ID, follow ID, and guild member ID from among the extracted support character IDs. The list generation unit 184a generates a first list (first list information) based on the support character IDs thus extracted.

On the other hand, when generating the second list (second list information), the list generation unit 184a extracts the support character ID set for the event battle from the support character information stored in the support character information storage unit 194. . At this time, support character IDs that cannot participate in the battle game selected by the player are excluded from the extracted support character IDs set for the event battle. The list generation unit 184a also identifies the friend ID, follow ID, and guild member ID associated with the player ID. Also, the list generating unit 184a extracts support character IDs associated with the friend ID, follow ID, and guild member ID from among the extracted support character IDs. The list generation unit 184a generates a second list (second list information) based on the support character IDs thus extracted.

When the support character information is received from the player terminal 1, the support character information storage unit 185a stores the received support character information in the support character information storage unit 194. FIG. At this time, the support character information storage unit 185a associates and stores the player ID and the support character ID. The support character information includes information about the type of support character (support character ID) and status information about the status of the support character (level information of the support character, information about equipment, etc.).

In addition, in the support character information storage unit 185a, the operator stores allied characters that can participate in event battles (sub-boss battles, main boss battles) among allied characters that can be acquired by the player before the event battle period. A plurality of types of characters are set in advance. In this embodiment, a plurality of types of general-purpose characters with different levels and statuses are set even for general-purpose characters of the same type (friend character ID). General-purpose characters are set as support characters that can be borrowed by players during event battles. Also, in the support character information storage unit 185a, an NPC different from the player is set by the operator before the event battle is held, and the above-described general-purpose character is set as the support character of the NPC. In this embodiment, a plurality of types of NPCs with different player levels and different names are set. The ID of the NPC (hereinafter referred to as NPCID) is associated with the ID of the general character (hereinafter referred to as general character ID) and stored in the support character information storage unit 194 . At this time, the NPCID and the general-purpose character ID associated with the NPCID are stored in the support character information storage unit 194 in a file format as NPC files grouped by player level band (for example, 10-level band). As a result, the player can borrow a general-purpose character from the NPC as a support character when an event battle is held. For the NPC, two general-purpose characters (types) are set as support characters in the same way as when the player sets support characters. A plurality of types of NPCs are set in the support character information storage unit 185a so that the player can borrow two or more (types) of general-purpose characters.

When the party formation information is received from the player terminal 1, the party formation information storage section 186a stores the received party formation information in the party formation information storage section 195. FIG.

The reward giving unit 187a gives a reward to the player. The reward giving unit 187a gives an item corresponding to the cleared battle game to the player who has cleared the battle game. More specifically, the reward giving unit 187a adds an item to be given to the player information corresponding to the player ID of the player who has cleared the battle game, and stores the added item in the player information storage unit 191 .

(Communication processing between player terminal 1 and server 100)
FIG. 16 is a sequence diagram illustrating basic processing of the player terminal 1 and the server 100. FIG. In the following description, processing in the player terminal 1 will be indicated as Pn (n is an arbitrary integer). Also, the processing in the server 100 is represented by Sn (n is an arbitrary integer). When the player starts the game application on the player terminal 1 (P1), the game execution control unit 80a transmits login information to the server 100. FIG. When receiving the login information, the game execution control unit 180a of the server 100 identifies the player ID associated with the login information and performs login processing (S1). Here, the game execution control unit 180a reads the player information corresponding to the identified player ID from the player information storage unit 191 and transmits it to the player terminal 1. FIG. Further, the game execution control unit 180a identifies a group ID associated with the identified player ID based on the group information stored in the group information storage unit 192, and stores the group information of the identified group ID in the group information storage unit 192. , and transmits it to the player terminal 1. Also, if there is updated game information, the game execution control unit 180 a reads the game information from the game information storage unit 190 and transmits it to the player terminal 1 . The game information includes, for example, event information regarding the event battle described above. The event information includes information about the types (ally character IDs) of ally characters who cannot participate in the above-described event battles (sub-boss battles, main boss battles). In this manner, the game execution control unit 180a of the server 100 transmits various information to the player terminal 1. FIG.

The game execution control unit 80a and the display control unit 87a of the player terminal 1 display the event battle screen (Fig. 9A or FIG. 11A) on the display 26 (event battle screen processing) is executed (P2).

Further, the game execution control unit 80a and the display control unit 87a of the player terminal 1 display the support character setting area 61 on the display 26 (support character setting area 61) when the player operates the support setting operation unit 60c on the event battle screen. setting screen processing) is executed (P3). When the player sets a support character in the support character setting area 61, the support character setting unit 85a of the player terminal 1 stores the set support character information (support character ID) in the support character information storage unit 94. Send to server 100 . When the support character information is received from the player terminal 1, the support character information storage unit 185a of the server 100 stores the received support character information in the support character information storage unit 194 in association with the player ID (support character information storage processing). (S2).

When the player performs a battle game start operation (operation of the challenge operation unit 46), the battle game execution unit 81a and the display control unit 87a of the player terminal 1 transmit start information to the server 100 (P4). A selection screen is displayed on the display 26 . This start information includes player information, battle information, and the like. Here, the battle information includes information about the type of battle game selected by the player, enemy character IDs, and the like.

When the start information is received from the player terminal 1, the list generation unit 184a of the server 100 generates a support character list (first list, second list) based on the received start information (S3). The list information of the generated list is transmitted to the server 100 and the list information is stored in the list information storage unit 193 of the server 100 . In addition, the list generation unit 184a extracts status information (for example, support character level information, equipment information, etc.) corresponding to the support character ID included in the list information from the player information storage unit 191, and stores the extracted status information. It is transmitted to the player terminal 1 separately. However, the present invention is not limited to this, and the list generation unit 184a may add status information to the list information and transmit the list information including the support character ID and the status information to the player terminal 1 .

FIG. 17 is a flowchart illustrating an example of list generation processing. The list generator 184a acquires the player ID from the received start information (S3-1). Also, the list generator 184a acquires information about the type of battle game from the received start information (S3-2). Then, the list generation unit 184a determines whether or not the battle game selected by the player is an event battle based on the acquired information about the battle game type (S3-3). If it is an event battle (YES in S3-3), the list generation unit 184a is set for event battle based on the support character information stored in the support character information storage unit 194 (that is, FIG. 9B or FIG. 11B). (set in the support character setting area 61 shown in ) is extracted. At this time, the list generation unit 184a determines support characters who cannot participate in the battle game selected by the player from the information about the type of the battle game, and determines support characters who cannot participate in the battle game from the extracted support character information. Perform processing to exclude support character information corresponding to . In other words, the list generator 184a performs a process of extracting only support character information corresponding to support characters who can participate in the battle game from the extracted support character information (S3-4).

It should be noted that the list generation unit 184a, when the player conducts an event battle (main boss battle) after the end of the event battle holding period, uses the support character information stored in the support character information storage unit 194 to set for the main quest. The support character information (that is, set in the support character setting area 30g shown in FIG. 4) is extracted as event battle support character information. Then, the list generation unit 184a performs a process of excluding support character information corresponding to support characters who cannot participate in the battle game (main boss battle) from the extracted support character information. In other words, the list generator 184a performs a process of extracting only support character information corresponding to support characters who can participate in the battle game (main boss battle) from the extracted support character information (S3-4).

Also, the list generation unit 184a identifies a group ID associated with the obtained player ID based on the group information stored in the group information storage unit 192, and obtains the guild member ID from the group information of the identified group ID. (S3-5). Also, the list generation unit 184a acquires a friend ID associated with the acquired player ID based on the player information stored in the player information storage unit 191 (S3-6). The list generator 184a extracts support character information (support character ID) associated with the acquired guild member ID and friend ID from the support character information extracted in S3-4 (S3-7). Here, the list generation unit 184a extracts support character information associated with the guild member ID and friend ID as support character information of support characters that can be borrowed from other players. Extraction of associated support character information is not essential, and only support character information associated with a friend ID may be extracted. Also, here, the list generating unit 184a will explain an example of extracting the support character information associated with the guild member ID and the friend ID. The support character information set by the player) may be extracted.

The list generator 184a counts the number of support characters extracted in S3-7, and determines whether or not the number of support characters is less than a predetermined number (S3-8). If the number of support characters is less than the predetermined number (YES in S3-8), the list generation unit 184a selects a general-purpose character who can participate in the battle game (sub-boss battle, main boss battle) selected by the player as a new support character. is added (S3-9). A plurality of types of general-purpose characters are set in advance corresponding to each sub-boss battle and main-boss battle, and are stored in the support character information storage unit 194 as described above. In this embodiment, as described above, the NPCID and the general-purpose character ID associated with the NPCID are stored in the support character information storage unit 194 in a file format as NPC files grouped by player level band. The list generation unit 184a refers to the player level included in the player information, selects an NPC file of the player level band corresponding to the referred player level, and selects an NPCID and a general character ID from the selected NPC files. process.

After adding one general-purpose character, the process returns to S3-8, and the list generation unit 184a again determines whether or not the number of support characters is less than the predetermined number. Then, if the number of support characters is less than the predetermined number (YES in S3-8), the list generation unit 184a performs general-purpose character addition processing (S3-9) until the number of support characters reaches the predetermined number. Here, in the present embodiment, the list generator 184a adds general-purpose characters based on the number of support characters, but is not limited to this, and adds general-purpose characters based on the types of support characters. may be performed. For example, the list generating unit 184a performs addition processing of a general-purpose character (general-purpose character ID) when the types of support characters are less than a predetermined type, and when the types of support characters are not less than the predetermined type, general-purpose characters (general-purpose character ID ) need not be added.

On the other hand, if the number of support characters is not less than the predetermined number (NO in S3-8), the list generation unit 184a generates a second list excluding the types of support characters that cannot participate in the event battle (S3- 10), end the list generation process.

On the other hand, if the battle game selected by the player is not an event battle (NO in S3-3), the list generation unit 184a determines that the player will play a normal battle, and based on the information about the type of the battle game, selects a normal battle. Determine the type (for example, main quest, guild battle, etc.). Based on the determined type of normal battle, the list generating unit 184a selects the support character information stored in the support character information storage unit 194 for the normal battle (that is, the support character setting area shown in FIG. 4). 30g or the support character information set in the support character setting area 30h) is extracted (S3-11).

Also, the list generation unit 184a identifies a group ID associated with the obtained player ID based on the group information stored in the group information storage unit 192, and obtains the guild member ID from the group information of the identified group ID. (S3-12). Also, based on the player information stored in the player information storage unit 191, the list generation unit 184a acquires a friend ID associated with the acquired player ID (S3-13). The list generator 184a extracts support character information (support character ID) associated with the acquired guild member ID and friend ID from the support character information extracted in S3-11 (S3-14). After that, the list generation unit 184a generates a first list based on the extracted support character information (S3-15), and ends the list generation process.

Returning to FIG. 16, on the party selection screen of the battle game selected by the player, the party formation unit 86a of the player terminal 1 selects a friendly character who cannot participate in the battle game based on the event information received from the server 100. Make it impossible to operate so that you can not organize a party. In addition, the display control unit 87a of the player terminal 1 displays "cannot be organized" for the ally characters who cannot participate in the battle game selected by the player, based on the event information.

Further, the display control unit 87a of the player terminal 1 displays the support character selection screen on the display 26 when the player operates the support character selection operation unit 48 of the party selection screen. On the support character selection screen, the display control unit 87a causes the display 26 to display the support character (that is, the support character who can participate in the battle game) of the support character information included in the list information received from the server 100. FIG. At this time, the display control unit 87a sorts and displays the support characters on the display 26 based on the ID information included in the support character information. For example, the display control unit 87a gives priority to the support character ID over the general-purpose character ID, and displays the support character so as to be positioned in front of the general-purpose character. However, the present invention is not limited to this, and the display control unit 87a may determine the display priority (display priority order) of the support characters based on various information such as status information included in the support character information.

In addition, the display control unit 87a determines the display priority (display priority order) of the friend ID, follow ID, and guild member ID associated with the support character ID. to take precedence over guild member IDs. Then, the display control unit 87a causes the support character of the friend player to be displayed in front of the support character of the non-friend player, and displays the support character of the non-friend player to be positioned in front of the support character of the guild member. to display. However, the order of display priority of the friend ID, follow ID, and guild member ID associated with the support character ID is not limited to this, and other display priority orders than those described above may be used.

When the player operates an ally character displayed on the party selection screen or the support character selection screen, the party organization unit 86a of the player terminal 1 organizes the operated ally character into a party (party organization screen processing) is performed (P5).

FIG. 18 is a flowchart for explaining an example of party organization screen processing. The party formation unit 86a determines whether or not the type of battle game selected by the player is normal battle (P5-1). If it is a normal battle (YES in P5-1), the party organizing section 86a sets the upper limit number of support characters selectable by the player to the first upper limit value (here, 1) (P5-2). On the other hand, if it is not a normal battle (NO in P5-1), the party formation section 86a sets the upper limit number of support characters selectable by the player to the second upper limit value (here, 4) (P5-3). , ends the party formation screen processing.

Returning to FIG. 16, the party organization section 86a transmits party organization information to the server 100 when the party organization is completed and the battle start operation section 49 is operated. When the party organization information storage unit 186 a of the server 100 receives the party organization information from the player terminal 1 , it stores the party organization information in the party organization information storage unit 195 .

In addition, the battle game execution unit 181a of the server 100 receives the start information and the party organization information, and transmits battle game start information necessary for starting the battle game to the player terminal 1 (S4). Then, when the battle game execution unit 81a of the player terminal 1 receives the battle game start information, it performs battle game start processing for starting the battle game (P6). Here, for example, an area of the memory 12 for progressing the battle game is secured, or a predetermined program is read from the storage unit 18 to the memory 12 .

Thereafter, the battle game execution unit 81a of the player terminal 1 performs battle game control processing for controlling the battle game (P7). In this battle game control process, an update process for updating various information is repeatedly executed on a frame-by-frame basis. The number of frames is not particularly limited. For example, the number of frames per second is 30-60. Therefore, during the battle game, information is updated in the player terminal 1 at intervals of about 16 ms (milliseconds) to 33 ms.

Then, when the battle game end condition is satisfied, the battle game execution unit 81a of the player terminal 1 performs battle game end processing for ending the battle game (P8). In the battle game end process, for example, a result screen is displayed on the display 26 and game result information is transmitted to the server 100 . The battle game executing unit 181a of the server 100 updates the player information when acquiring the game result information (S5). Also, the reward granting unit 187a grants items based on the game result information.

As described above, the player terminal 1 includes a game execution control program 80, a battle game execution program 81, a player information storage program 82, a group information storage program 83, a list information storage program 84, a support character setting program 85, and a party formation program. A program 86 and a display control program 87 are provided. The player terminal 1 also includes a game execution control unit 80a, a battle game execution unit 81a, a player information storage unit 82a, a group information storage unit 83a, a list information storage unit 84a, a support character setting unit 85a, a party formation unit 86a, display control Includes portion 87a. However, some or all of these programs and functional units may be provided in server 100 . In other words, these programs and functional units may be provided in one or both of the player terminal 1 and the server 100 .

The server 100 also includes a game execution control program 180, a battle game execution program 181, a player information storage program 182, a group information storage program 183, a list generation program 184, a support character information storage program 185, a party organization information storage program 186, A rewarding program 187 is provided. The server 100 also includes a game execution control unit 180a, a battle game execution unit 181a, a player information storage unit 182a, a group information storage unit 183a, a list generation unit 184a, a support character information storage unit 185a, a party formation information storage unit 186a, a reward It includes the imparting portion 187a. However, some or all of these programs and functional units may be provided in the player terminal 1 . In other words, these programs and functional units may be provided in one or both of the player terminal 1 and the server 100 .

Further, in the above embodiment, the main quest and the guild battle are provided as the first battle game, and the event battle is provided as the second battle game. However, if the first battle game and the second battle game are a first battle game in which the types of friendly characters who can participate are not limited, and a second battle game in which the types of friendly characters who can participate are limited, what kind of battle game is used? It can be a game.

Further, the information processing program in the above embodiment may be stored in a computer-readable storage medium and provided as the storage medium. Furthermore, it may be provided as a player terminal or an information processing system including this storage medium. Further, the above embodiment may be an information processing method that implements each function and the steps shown in the flowchart.

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 obvious that a person skilled in the art can conceive of various modifications or modifications within the scope of the claims, and it is understood that these also belong to the technical scope of the present invention. be done.

In the above embodiment, the list generation unit 184a first extracts support character information set according to the type of battle game selected by the player from all support character information stored in the support character information storage unit 194. Then, the process of extracting support character information associated with the player's friend ID, follow ID, and guild member ID from the extracted support character information has been described as an example. However, the present invention is not limited to this, and the list generation unit 184a first selects all the support character information stored in the support character information storage unit 194 and associates them with the player's friend ID, follow ID, and guild member ID. Support character information may be extracted, and then support character information set according to the type of battle game selected by the player may be extracted from the extracted support character information. In the above embodiment, the step of acquiring information about the type of battle game (S3-2) is the step of acquiring the guild member ID (S3-5, S3-12) and the step of acquiring the friend ID (S3- 6, before S3-13), but not limited thereto, the step of acquiring information about the type of battle game (S3-2) is the step of acquiring a guild member ID (S3-5, S3-12) and the step of acquiring a friend ID (S3-6, S3-13) may be performed later than or at the same time. The step of acquiring information about the type of battle game may be performed at any timing before the process of extracting support character information set according to the type of battle game selected by the player.

In the above embodiment, an example has been described in which it is necessary for the player to organize at least one ally character possessed by the player himself/herself in forming a party for the event battle. However, the present invention is not limited to this, and the player may be allowed to organize all ally characters as support characters in forming a party for the event battle.

INDUSTRIAL APPLICABILITY The present invention can be used for an information processing program, an information processing method, and an information processing system.

1 Player terminal 81a Battle game execution unit 85a Support character setting unit 86a Party formation unit 100 Server 184a List generation unit S Information processing system

Claims (7)

A first battle game in which characters associated with player IDs and given different IDs for each character are played, wherein the IDs of participating characters are not restricted; and a battle game execution unit that executes a second battle game whose ID is restricted;
In the first battle game, a player generates a first list of IDs of support characters that can be borrowed from other players, and in the second battle game, participates in the second battle game from the IDs of the support characters. a list generator that generates a second list in which the IDs of impossible characters are excluded;
a support character setting unit that sets a character possessed by the player as a support character that can be lent to the other player;
a party organization unit that organizes a plurality of characters with different IDs to participate in the first battle game or the second battle game based on the player's input operation;
to make the computer work,
The second battle game includes a plurality of battle games in which the IDs of characters that cannot participate in each other are different,
The support character setting unit is
setting the support character for the second battle game;
The list generation unit
generating different second lists according to the plurality of types of the second battle game;
An information processing program for performing general-purpose character addition processing when the number of IDs of support characters extracted to generate the second list is less than a predetermined number . a display control unit for displaying characters that can participate in the second battle game among the support characters when displaying the second list on the display unit;
2. The information processing program according to claim 1, which causes a computer to function. When the number of the support characters in the second list is less than a predetermined number, the list generation unit generates the second list of characters obtainable by the player until the number of the support characters reaches the predetermined number. 3. The information processing program according to claim 1, wherein said general-purpose character, which is a character that can participate in a battle game, is added to said second list. 1-, wherein said party organization unit sets the number of said support characters that can be organized for said second battle game to be larger than the number of said support characters that can be organized for said first battle game. 4. The information processing program according to any one of 3. The party organization unit organizes characters owned by the player and characters selected from the support characters on the first list in the first battle game, and organizes characters owned by the player in the second battle game. organize characters selected from among the characters and the supporting characters of the second list;
5. The information processing program according to claim 4, wherein said battle game executing section executes said first battle game or said second battle game using characters formed by said party forming section. An information processing method executed by one or both of a player terminal and a server capable of communicating with the player terminal,
a step of setting a character possessed by the player as a support character that can be lent to another player;
A first battle game in which the IDs of characters that can participate are not limited based on the player's input operation in order to play the battle game using characters associated with player IDs and assigned different IDs for each character. Alternatively, a step of forming a plurality of characters with different IDs to participate in a second battle game in which the IDs of characters that can participate are limited;
executing the first battle game;
executing the second battle game;
generating a first list of the IDs of support characters that the player can borrow from the other player in the first battle game;
generating a second list in which the IDs of characters unable to participate in the second battle game are excluded from the IDs of support characters that the player can borrow from the other players in the second battle game; ,
including
The second battle game includes a plurality of battle games in which the IDs of characters that cannot participate in each other are different,
The step of setting the support character includes:
setting the support character for the second battle game;
The step of generating the second list includes:
generating different second lists according to the plurality of types of the second battle game;
An information processing method for performing general-purpose character addition processing when the number of IDs of support characters extracted to generate the second list is less than a predetermined number . An information processing system comprising a player terminal and a server capable of communicating with the player terminal,
Either one or both of the player terminal and the server,
A first battle game in which characters associated with player IDs and given different IDs for each character are played, wherein the IDs of participating characters are not restricted; and a battle game execution unit that executes a second battle game whose ID is restricted;
In the first battle game, a player generates a first list of IDs of support characters that can be borrowed from other players, and in the second battle game, participates in the second battle game from the IDs of the support characters. a list generator that generates a second list in which the IDs of impossible characters are excluded;
a support character setting unit that sets a character possessed by the player as a support character that can be lent to the other player;
a party organization unit that organizes a plurality of characters with different IDs to participate in the first battle game or the second battle game based on the player's input operation;
with
The second battle game includes a plurality of battle games in which the IDs of characters that cannot participate in each other are different,
The support character setting unit is
setting the support character for the second battle game;
The list generation unit
generating different second lists according to the plurality of types of the second battle game;
An information processing system for performing general-purpose character addition processing when the number of IDs of support characters extracted to generate the second list is less than a predetermined number .

Images