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

Abstract

To suppress a risk of a scarcity of strategic characteristics in a battle game.SOLUTION: An information processing program allows a computer to execute: processing for granting a match right with an opponent in a battle game when a predetermined condition is satisfied; processing for executing the battle game with the opponent on the basis of a match condition set to the match right by consuming the match right; processing for granting a carry-over right when beating the opponent within the match condition in execution of the battle game by consuming the match right; processing for setting the match condition for the carry-over right; processing for executing the battle game with the opponent on the basis of the match condition for the carry-over right without consuming the match right by consuming the carry-over right; and processing for allowing a player to select which of the match right and the carry-over right is consumed when both of the match right and the carry-over right are possessed.SELECTED DRAWING: Figure 4

Description

Applied for application of Article 30, Paragraph 2 of the Patent Act. youtube. com/watch? v=e0k1j5nNmmU https://twitter. com/priconne_redive https://twitter. com/priconne_redive/status/1387697888583630850 https://twitter. com/priconne_redive/status/1387697519396851713 https://twitter. The internal mechanism is not disclosed at com/priconne_redive/status/1387697254933405697, but the invention is disclosed as a content that can be read to the extent of the outline of the invention June 4, 2021 https://priconne-redive. jp/news/update/12972/https://dmg. Priconne-redive. jp/news/detail. php? Although the internal mechanism is not disclosed with id = 12972, the invention was disclosed as content that can be read about the outline of the invention On June 11, 2021 https://twitter. com/priconne_redive https://twitter. The internal mechanism is not disclosed at com/priconne_redive/status/1403190111903178754, but the invention is disclosed as content that can be read to the extent of the outline of the invention June 22, 2021 https://priconne-redive. jp/news/update/13213/https://dmg. Priconne-redive. jp/news/detail. php? id=13213https://twitter. com/priconne_redive https://twitter. com/priconne_redive/status/1407171750975000582 The internal mechanism is not disclosed, but the invention is disclosed as content that can be read to the extent of the outline of the invention

Applied for application of Article 30, Paragraph 2 of the Patent Law June 11, 3rd year of Reiwa and June 22nd, 3rd year of Reiwa https://itunes. apple. com/jp/app/id1134429300 https://play. google. com/store/apps/details? id=jp. co. cygames. princessconnectredive https://dmg. Priconne-redive. Published a game service implementing the system according to the present invention at jp/

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

Conventionally, as disclosed in Patent Document 1, for example, an upper limit is set for the number of times a battle game can be executed within a predetermined period of time, and a plurality of players belonging to the same group cooperate to form a plurality of enemy characters. In a battle game in which characters are defeated in order, when a player defeats an enemy character, the next battle game can be executed without consuming the number of times the battle game can be executed is known. .

Patent No. 6655212

With such a game device, the next battle game can be executed without consuming the number of times the battle game can be executed, but there is a possibility that the strategy in the battle game will be poor.

SUMMARY OF THE INVENTION An object of the present invention is to provide an information processing program, an information processing method, and an information processing system capable of suppressing the possibility that a battle game lacks strategy.

In order to solve the above problems, the information processing program provides a process of granting the right to play against an opponent in a battle game when a predetermined condition is satisfied, and consuming the right to play against the right to play. A process of executing the battle game with the opponent based on the set battle conditions, and a case where the opponent is defeated within the battle conditions when the battle game is executed by consuming the battle right. , a process of granting the carryover right, a process of setting the match condition for the carryover right, and consuming the carryover right, without consuming the match right, based on the match condition for the carryover right a process of executing the battle game with the opponent by the player, and a process of allowing the player to select whether to consume the battle right or the carryover right when the player has both the battle right and the carryover right. and are performed by the computer.

When the player has a plurality of carryover rights, the computer may further perform a process of allowing the player to select which of the plurality of carryover rights to consume.

A computer may be caused to further perform a process of generating a match record related to the battle game with the opponent, and a process of outputting the match record by any one of a plurality of methods based on the player's operation. good.

The plurality of methods include a method of outputting the match record in a browsable manner within a group to which the plurality of players can belong based on the player's operation, and a method of outputting the match record based on the player's operation. and a method of outputting in a text format so that it can be pasted.

In order to solve the above problems, an information processing method is an information processing method performed by one or more computers, wherein when a predetermined condition is satisfied, a process of granting the right to play against an opponent in a battle game; By consuming the right to play, a process of executing the battle game with the opponent based on the playing conditions set for the right to play, and executing the battle game by consuming the right to play. When the opponent is defeated within the match condition, the match right is granted by a process of granting the carryover right, a process of setting the match condition for the carryover right, and consuming the carryover right. without consuming the battle right, and the battle right when the player has both the battle right and the carryover right. or allowing the player to choose which of the carryover rights to consume.

In order to solve the above problems, an information processing system is an information processing system comprising one or more computers, wherein the computer grants the right to play against an opponent in a battle game when a predetermined condition is met. a process of consuming the battle right to execute the battle game with the opponent based on the battle conditions set for the battle right; and a process of consuming the battle right to execute the battle game. When the opponent is defeated within the battle conditions when executing Without consuming the battle right, when the process of executing the battle game with the opponent based on the battle conditions for the carryover right and having both the battle right and the carryover right, and allowing the player to select whether to consume the competition right or the carryover right.

According to the present invention, it is possible to suppress the risk of poor strategy in a 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. 4A is a diagram illustrating an example of a guild battle screen. FIG. 4B is a diagram illustrating an example of the carryover confirmation screen. FIG. 5A is a first diagram for explaining possible opponents. FIG. 5B is a second diagram for explaining possible opponents. FIG. 5C is a third diagram for explaining possible opponents. FIG. 5D is a fourth diagram for explaining possible opponents. FIG. 6A is a fifth diagram for explaining possible opponents. FIG. 6B is a sixth diagram for explaining possible opponents. FIG. 7A is a diagram illustrating an example of an opponent screen. FIG. 7B is a diagram illustrating an example of a carryover use confirmation screen. FIG. 8A is a diagram illustrating an example of a party formation screen. FIG. 8B is a diagram illustrating an example of a guild battle start confirmation screen. FIG. 9A is a diagram illustrating an example of a result screen. FIG. 9B is a diagram illustrating an example of a damage report screen. FIG. 9C is a diagram illustrating an example of a battle details screen. FIG. 10 is a diagram illustrating an example of text content output when copying to the clipboard. FIG. 11A is a diagram illustrating an example of a mylog screen. FIG. 11B is a diagram illustrating an example of the guild screen. FIG. 12 is a diagram for explaining the configuration of a memory in a player terminal and functions as a computer. FIG. 13 is a diagram for explaining the configuration of a memory in a server and functions as a computer. FIG. 14 is a sequence diagram illustrating basic processing of the player terminal and server. FIG. 15 is a flowchart illustrating an example of login processing in the server. FIG. 16 is a flowchart illustrating an example of terminal-side guild processing in the player terminal. FIG. 17 is a flowchart for explaining an example of terminal-side guild battle screen processing in the player terminal. FIG. 18 is a flowchart illustrating an example of guild battle pre-start processing in the player terminal. FIG. 19 is a flowchart illustrating an example of server-side battle game start processing in the server. FIG. 20 is a flowchart illustrating an example of server-side battle game end processing in the server. FIG. 21 is a flowchart illustrating an example of terminal-side result screen processing in the player terminal. FIG. 22 is a flowchart illustrating an example of terminal-side mylog screen processing in the player terminal. FIG. 23 is a flowchart illustrating an example of terminal-side battle detail screen processing in the player terminal.

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.

<First Embodiment>
(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 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 connected for communication with a plurality of player terminals 1 . 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 (five in this embodiment) from the provided friendly 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 main purpose is for friendly 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.

A menu bar 30 is displayed at the bottom of the display 26 on the home 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 quest screen selection operation section 30c labeled "quest", A gacha screen selection operation section 30d labeled "gacha" and a menu screen selection operation section 30e labeled "menu" are provided.

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. Similarly, when the quest screen selection operation section 30c is tapped, the quest screen shown in FIG. 3C is displayed on the display 26. FIG. Further, when the gacha screen selection operation unit 30d is tapped, a gacha screen (not shown) is displayed on the display 26. FIG. Further, when the menu screen selection operation section 30 e is tapped, a menu screen (not shown) is displayed on the display 26 . Although detailed explanation is omitted, 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. Further, 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.

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 level of the player associated with the player ID, and a stamina display bar 31b indicating the stamina of the player associated with the player ID.

Note that stamina is a parameter required to play at least part of 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 and a maximum number of executions per day. 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, on the home screen, when a guild battle, which will be described later in detail, is being held, a guild battle operation section 32 labeled "Guild Battle" is displayed.

Then, when the guild battle operation unit 32 is tapped, a guild battle screen (FIG. 4A), which will be described later, is displayed on the display 26 . Note that the guild battle operation section 32 may be hidden when the guild battle is not being held.

Also, between the menu bar 30 and the guild battle operation section 32 on the home screen, there is a guild operation section 33 labeled "Guild".

When the guild operation unit 33 is tapped, a guild screen (FIG. 11B), which will be described later, is displayed on the display 26 .

On the teammate character confirmation screen shown in FIG. 3B, all teammate characters (images) 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.

An experience value and a level are stored in association with each ally character. 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 rarity (number of stars) and level. 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. For each piece of equipment, an additional value for attack power, defense power, etc. is set according to the equipment rank indicating the rank of the equipment to be equipped. 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.

On the quest screen shown in FIG. 3C, a plurality of game type selection operation sections 35 indicating the type of provided battle game are displayed. Here, four types of battle games are provided, and four game type selection operation sections 35 are displayed.

The game type selection operation unit 35 includes a main quest selection operation unit 35a labeled "main quest", a guild battle selection operation unit 35b labeled "guild battle", and a 1V1 battle selection operation unit 35b labeled "1V1 battle". An operation unit 35c and a 3V3 battle selection operation unit 35d labeled "3V3 battle" are provided.

When the main quest selection operation section 35a is tapped, a main quest screen (not shown) is displayed on the display 26. FIG. Further, when the guild battle selection operation portion 35b is tapped, a guild battle screen shown in FIG. 4A, which will be described later, is displayed on the display 26.

Further, when the 1V1 battle selection operation section 35c is tapped, a 1V1 battle screen (not shown) is displayed on the display 26. FIG. Further, when the 3V3 battle selection operation section 35d is tapped, a 3V3 battle screen (not shown) is displayed on the display 26. FIG.

A release condition is set for each type of battle game. Release conditions include, for example, that the player level is equal to or higher than a predetermined value, that another predetermined battle game has been cleared, and the like.

FIG. 4A is a diagram illustrating an example of a guild battle screen. FIG. 4B is a diagram illustrating an example of the carryover confirmation screen. As described above, for example, when the guild battle selection operation section 35b is tapped on the quest screen, the guild battle screen shown in FIG. 4A is displayed on the display 26. FIG.

A guild battle is held, for example, once a month for three days. In the battle game of the guild battle, a plurality of players work together to defeat enemy characters. Players who can cooperate are limited to guild members, which will be described later in detail. Specifically, enemy characters have more life points than enemy characters that appear in the main quest battle game. The purpose is to defeat the enemy character.

Here, in the present embodiment, every time a predetermined amount of stamina is consumed in a day, the right to compete in the battle game of the guild battle is added once, and the right to compete is granted up to three times in a day. be done.

For example, every time 300 stamina is consumed in a day, the battle right for the guild battle battle game is added once. ) is given. That is, when a predetermined condition is satisfied, the player is granted the battle right to battle with the opponent in the battle game of the guild battle. It should be noted that, in the present embodiment, the battle right acquired by the player disappears (is cleared) on the day following the date of acquisition.

In this embodiment, a lap consisting of five enemy characters is set in the guild battle. When all five enemy characters belonging to the same round are defeated, the next round is started. Further, in this embodiment, steps are set in which the strength of the enemy character changes. For example, the 1st to 3rd rounds are set in the 1st stage, the 4th to 10th rounds are set in the 2nd stage, the 11th to 30th rounds are set in the 3rd stage, and the 31st round is set. From the 40th round, it is set to the 4th stage, and from the 41st round onward, it is set to the 5th stage.

On the guild battle screen, an opponent operation section 63a and a subjugation notification section 63b are displayed according to predetermined conditions. The opponent operation part 63a is an image corresponding to an enemy character that can be fought against. The subjugation notification section 63b is an image of a treasure chest corresponding to an enemy character that has been subjugated and cannot be fought against.

In this embodiment, when a predetermined condition is satisfied, the opponent operation section 63a corresponding to the enemy character belonging to the next round is displayed. A more specific description will be given below with reference to examples. FIG. 5A is a first diagram explaining possible opponents, FIG. 5B is a second diagram explaining possible opponents, and FIG. 5C is an explanation of possible opponents. FIG. 5D is a fourth diagram explaining possible opponents; FIG. 6A is a fifth diagram explaining possible opponents; Figure 6 is a sixth diagram illustrating possible opponents; As shown in FIG. 5A, for example, when all the first to fifth enemy characters belonging to the first round (first row) are alive, A battle game is set to be executable for all of the first to fifth enemy characters. In this case, the oldest surviving (non-defeated) enemy character is the first enemy character in the first round.

Further, as shown in FIG. 5B, for example, when the first enemy character belonging to the first round (first stage) is defeated from the state shown in FIG. A battle game is set to be executable for the second to fifth enemy characters and the first enemy character belonging to the second round (first stage). In this case, the oldest surviving (not defeated) enemy character is the second one in the first round.

Further, as shown in FIG. 5C, for example, when the third and fourth enemy characters belonging to the first round (first stage) are defeated from the state shown in FIG. A battle game is set to be executable against the first, second, and fifth enemy characters belonging to the first, second, and fifth enemy characters. In this case, the oldest surviving (non-defeated) enemy character is the first enemy character in the first round.

Further, as shown in FIG. 5D, for example, the first enemy character belonging to the third round (first row) has been defeated, and the second to fifth enemy characters belonging to the third round (first row) have been defeated. If they are alive, the battle game is set to be executable against the second to fifth enemy characters belonging to the third round (first row), and the enemy characters belonging to the fourth round (second row). The battle game is not set to be executable. In this case, the oldest surviving (non-defeated) enemy character is the second enemy character in the third round.

Further, as shown in FIG. 6A, for example, the first, third to fifth enemy characters belonging to the first round (first row), and the first enemy character belonging to the second round (first row) are If the second enemy character belonging to the first round (first row) is alive and has been defeated, the battle game is executed only for the second enemy character belonging to the first round (first row). set to enabled. In this case, the oldest surviving (not defeated) enemy character is the second one in the first round.

Further, as shown in FIG. 6B, for example, when the second enemy character belonging to the first round (first stage) is defeated from the state shown in FIG. 6A, the enemy character belonging to the second round (first stage) A battle game is set to be executable for the second to fifth enemy characters and the first enemy character belonging to the third round (first stage). In this case, the oldest surviving (not defeated) enemy character is the second character in the second round.

As described above, in this embodiment, when the oldest surviving (undefeated) enemy character is the N-th character (N is 1 to 5), N-1 characters belonging to the next round It is set so that up to the first living enemy character can fight. In the case of N=1, since there is no N-1th enemy character belonging to the next round, up to five surviving enemy characters in the same round as the oldest surviving enemy character do not exist. It is set to be able to fight. If the number of steps to which the oldest surviving enemy character belongs is different from the number of steps to which the next one belongs, the survival of up to five characters in the same orbit as the oldest surviving enemy character is possible. It is set so that even an enemy character that has

By operating the opponent operation unit 63a, the player selects a desired enemy character (opponent operation unit 63a) from the enemy characters (opponent operation unit 63a) displayed in a selectable manner. It is possible to execute a battle game with a selected enemy character.

Returning to FIG. 4A, a ranking display area 60, an information area 61, and a battle log display area 62 are displayed on the guild battle screen.

The ranking display area 60 displays the current ranking of the guild (group) to which the player belongs. The ranking is derived by comparing the total value of damage inflicted on enemy characters in all guilds at regular intervals (for example, 30 minutes) while the guild battle is being held in the server 100 . Then, in the server 100, the derived ranking is stored in the memory 112, and the ranking of each guild is stored in the guild information described later.

In the information area 61, the current number of laps, the current number of steps, the number of remaining battles indicating the number of battle rights granted to the player, and the remaining carryover number indicating the number of carryover rights granted to the player, which will be described later in detail. is displayed, and the My Log operation section 61a and the confirmation operation section 61b are also displayed.

When the mylog operation unit 61a is operated, a mylog screen (FIG. 11A), which will be described later, is displayed on the display 26. FIG. The guild battle has a function of saving the game result information of the battle game as a personal log and displaying the saved personal log.

When the confirmation operation unit 61b is operated, the carryover confirmation screen shown in FIG. 4B is displayed. In the present embodiment, when the battle right is consumed and a battle game with an enemy character is executed, and a predetermined condition is satisfied, the carryover right is granted. In this embodiment, in a battle game that is executed by consuming the battle right, a time limit (fight time) is set as a battle condition for the battle right. If the opponent's enemy character is defeated within this time limit, the carryover right is granted.

At this time, a time limit (fighting time) for the carryover right is set based on the remaining fighting time when the opponent's enemy character is defeated. In this embodiment, the longer the remaining battle time after defeating the opponent's enemy character, the longer the time limit set for the carryover right is, the more the time limit set for the battle right (for example, 90 seconds). ) is set long within the following range.

In this embodiment, the carryover right is granted when the opponent's enemy character is defeated within the time limit (fight time) set as the battle condition for the battle right. It is not limited to this. For example, when an opponent's enemy character is defeated while the ally character set as a battle condition for the battle right still has physical strength, the carryover right may be granted.

Then, by consuming the granted carry-over right, it becomes possible to play against the opponent in the battle game of the guild battle without consuming the right to play. In this embodiment, one carry-over right can be granted for one battle right. On the other hand, in this embodiment, the carryover right is not further granted to the carryover right. However, in addition to the carryover right, it may be possible to grant the carryover right.

In addition, when consuming the carryover right and playing against an opponent in the battle game of the guild battle, the physical strength of the ally character at the end of the battle game on which the carryover right was granted is taken over, and the carryover right is taken over. A battle game of a guild battle that consumes rights may be performed. Alternatively, a battle game of a guild battle that consumes the carryover right may be performed without taking over the ally character's physical strength at the end of the battle game on which the carryover right was granted.

On the carryover confirmation screen shown in FIG. 4B, the carryover right information display portion 64a is displayed for each carryover right held by the player. The carryover right information display portion 64a displays information relating to the corresponding carryover right. Specifically, the number of times the carryover right was granted on the day, the time limit set for the carryover right, and the battle on which the carryover right was granted Information about the party formation in the game is displayed.

Further, as shown in FIG. 4B, a close operation section 64b is displayed on the carryover confirmation screen. When the closing operation unit 64b is operated, the display of the carryover confirmation screen being displayed is ended.

Also, in the battle log display area 62 shown in FIG. 4A, when the guild members belonging to the guild play a guild battle battle game, the damage dealt to the enemy character at that time is displayed together with the player name. This makes it easy to see how much damage other guild members have dealt.

FIG. 7A is a diagram illustrating an example of an opponent screen. When a selectable enemy character (opponent operation unit 63a) is operated on the guild battle screen (FIG. 4A), the opponent screen shown in FIG. 7A is displayed on the display 26. FIG.

As shown in FIG. 7A, on the opponent screen, respective operation units of a battle operation unit 37, a cancel operation unit 38, and a confirmation operation unit 61b are displayed. In addition, the opponent screen displays a reward obtained when the enemy character selected on the guild battle screen (FIG. 4A) is defeated, and the physical strength of the enemy character.

When the confirmation operation section 61b is operated on the opponent screen, the carryover confirmation screen shown in FIG. 4B is displayed. Further, when the cancel operation unit 38 is operated on the opponent screen, the display of the opponent screen ends.

FIG. 7B is a diagram illustrating an example of a carryover use confirmation screen. When the battle operation unit 37 is operated on the opponent screen (FIG. 7A), the carryover use confirmation screen shown in FIG. 7B is displayed. As shown in FIG. 7B, the carryover use confirmation screen displays a select operation section 65a and a close operation section 64b, which are displayed for each battle right or carryover right held by the player. When the closing operation unit 64b is operated, the display of the carryover use confirmation screen being displayed is ended.

That is, when the player has both the competition right and the carryover right, the player can select whether to consume the competition right or the carryover right. In this way, the player can freely select the competition right or the carry-over right to be consumed, so that the player's options in the battle game are widened, and the strategic nature of the battle game can be improved. Further, when the player has a plurality of carryover rights, the player can select which of the plurality of carryover rights to consume. This makes it possible to further improve the strategic nature of the battle game.

FIG. 8A is a diagram illustrating an example of a party formation screen. When the selection operation section 65a of the carryover use confirmation screen (FIG. 7B) is operated, the party formation screen shown in FIG. 8A is displayed on the display 26. FIG. As shown in FIG. 8A, the party formation screen displays all the friendly characters (images) possessed by the player, and a selected friendly character display area 40 below which displays the selected friendly characters. is displayed.

Note that, in the present embodiment, a teammate character that has been used in a battle game related to one of the battle rights in one day cannot be used in a battle game related to another battle right.

However, in a battle game related to carry-over rights granted to any battle right, it is possible to reuse the teammate character used in the battle game related to the battle right. In this embodiment, as shown in FIG. 8A, friendly characters that can be used in the battle game and friendly characters that cannot be used in the battle game can be identified according to the selection operation unit 65a operated on the carryover use confirmation screen (FIG. 7B). The identification information is additionally displayed on the teammate character (image) so that

When the player operates a selectable ally character displayed on the party formation screen, the operated ally character is displayed in the selected ally character display area 40 . 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.

FIG. 8B is a diagram illustrating an example of a guild battle start confirmation screen. When the battle start operation section 39 on the party formation screen (FIG. 8A) is operated, a guild battle start confirmation screen shown in FIG. 8B is displayed. As shown in FIG. 8B, a cancel operation section 38 and a battle start operation section 39 are displayed on the guild battle start confirmation screen. Also, on the guild battle start confirmation screen, the ally character for use in the battle game that was finally displayed in the ally character display area 40 of the party formation screen (FIG. 8A) is displayed. In addition, on the guild battle start confirmation screen, depending on the selection operation unit 65a operated on the carryover use confirmation screen (FIG. 7B), a warning to the effect that the battle right or the carryover right will be consumed to start the execution of the battle game is called. It may be displayed. Further, when the cancel operation section 38 of the guild battle start confirmation screen is operated, the display of the guild battle start confirmation screen ends.

Then, when the battle start operation section 39 on the guild battle start confirmation screen is operated, the battle game is started. When the battle game is started, a battle-in-progress screen (not shown) is displayed. In the screen during battle, a friend character and an enemy character are displayed on the display 26 . 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 the enemy characters become 0, the player wins (clears). be defeated.

Also, during the battle game, a special move may be used that gives more damage points to the enemy character than a normal attack. Two patterns are provided for the method of using the deathblow. One is a pattern in which the deathblow is used based on the player's operation in the manual state, and a pattern in which the deathblow is automatically used in the auto state.

Then, when the battle game ends normally, a result screen (FIG. 9A) is displayed on the display 26. FIG. FIG. 9A is a diagram illustrating an example of a result screen. On the result screen, at least part of the game result information of the battle game is displayed, and a damage report operation section 66a marked with "damage report", a battle details operation section 66b marked with "battle details", and , a next operation section 66c marked with "next" is displayed.

The game result information includes the friendly character ID (party) of the friendly character, the level of the friendly character, the equipment rank of the friendly character, the rarity of the friendly character (the number of stars), the enemy character ID of the enemy character, and the Remaining status of allied characters and enemy characters (physical strength of opponent and allied characters at the end of the battle game), damage points dealt (total value), damage points received Manual state or auto state, battle log ID, battle Game type, information associated with each battle game type (clear information, battle game hierarchy, etc.), battle time of battle game, remaining time after battle game ends, date and time when battle game was executed, battle It contains various kinds of information related to the battle game, such as the activation timing of the enemy character's and ally character's special moves during the progress of the game. 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 operation unit 66c is operated next on the result screen, the display on the display 26 switches from the result screen to the guild battle screen (FIG. 4A). Note that the screen switched from the result screen may be a predetermined screen such as the home screen. Thus, the battle game ends when the display of the result screen ends.

FIG. 9B is a diagram illustrating an example of a damage report screen. When the damage report operation section 66a is operated on the result screen, the damage report screen shown in FIG. 9B is displayed on the display 26. FIG. The damage report screen displays the damage points (total value) inflicted by the ally character and the enemy character, and also displays an OK operation section 67a labeled "OK". When the OK operation section 67a is operated, the display of the damage report screen ends.

FIG. 9C is a diagram illustrating an example of a battle details screen. When the battle details operation section 66b is operated on the result screen, the battle details screen shown in FIG. 9C is displayed on the display 26. FIG. Damage points dealt by allied characters (total value), allied character level, allied character equipment rank, allied character rarity (number of stars), timing of enemy and allied character special moves during the progress of the battle game. , the battle time of the battle game, the date and time when the battle game was executed, etc. are displayed. A close operation section 64b labeled "Close" is displayed.

When the operation unit 64b for closing the battle details screen is operated, the display of the battle details screen ends. Further, when the posting operation unit 68a is operated, the game result information is posted on the guild screen (FIG. 11B) described later, and at least a part of the information included in the game result information is viewed among the members belonging to the guild. can be made possible. The details of the guild screen will be described later.

FIG. 10 is a diagram illustrating an example of text content output when copying to the clipboard. When the copy operation unit 68b on the battle details screen (FIG. 9C) is operated, at least part of the information (hereinafter referred to as battle timeline information) included in the game result information corresponding to the battle details screen being displayed is converted to text. Copy (output) to the clipboard of the player terminal 1 so that it can be pasted in the format. Here, the text content of the battle timeline information shown in FIG. 10 is copied (output) to the clipboard of the player terminal 1 . That is, based on the player's operation, the battle record is output in a text format so that it can be pasted. The information copied to the clipboard of the player terminal 1 can be pasted into any application such as a so-called SNS (Social networking service) application or mail application. Note that the battle timeline information may be generated in advance, or may be generated based on the player's operation. In this embodiment, the battle timeline information is generated in the terminal-side battle game control process (step P6), which will be described later in detail.

As described above, according to the present embodiment, the first method is to post at least part of the information included in the game result information on the guild screen (FIG. 11B) and output it so that it can be viewed by members belonging to the guild. and the second method of copying (outputting) to the clipboard of the player terminal 1 so that at least part of the information contained in the game result information can be pasted in text format. is possible. This makes it possible to improve convenience for the player. By using the first method, it becomes possible to easily share information among the members belonging to the guild in the game. Further, by using the second method, it is possible to widely share information not only with guild members but also with non-guild members through SNS, e-mail, etc. outside the game. In this embodiment, the player can select one of the first method and the second method, but the player may select from three or more methods.

FIG. 11A is a diagram illustrating an example of a mylog screen. In the guild battle screen shown in FIG. 4A, when the mylog operation unit 61a is operated, the mylog screen shown in FIG. 11A is displayed on the display 26. FIG.

The mylog screen has a function of displaying a mylog corresponding to the game result information of the battle game of the guild battle. The mylog screen displays a list, and mylog selection tabs 66 labeled with 1st, 2nd, 3rd, 4th, and 5th bodies. The mylog screen also displays a mylog display area 69 in which mylogs are displayed based on the type selected on the mylog selection tab 66 .

Note that an upper limit may be set for the number of items that can be saved in My Log. In this case, when a new mylog is saved while the maximum number of mylogs is saved, the mylog with the oldest date may be deleted.

Also, in each my log display area 69, a battle details operation section 66b is displayed. When the battle details operation part 66b of the my log display area 69 is operated, the battle details screen (FIG. 9C) corresponding to the my log display area 69 displaying the operated battle details operation part 66b is displayed on the display 26. .

FIG. 11B is a diagram illustrating an example of the guild screen. In the game of this embodiment, a guild can be formed by a plurality of players. For example, when one player creates a guild, the server 100 stores the guild ID of the guild in association with the player ID of the created player. When another player performs an operation to join a guild, the guild ID of the guild and the player ID of the player who performed the joining operation are associated and stored. The players who form the guild are called guild members.

Various information can be shared among guild members using the guild screen shown in FIG. 11B. A chat display area 70 is displayed on the guild screen, and a message (characters) input to the input unit 70b by the player's operation can be posted.

When a guild member belonging to the same guild displays the guild screen, the posted characters are displayed on the display 26 of the player terminal 1 displaying the guild screen together with the name of the player who posted (player 1, player 2, etc.). be done.

Also, the player can post the game result information of his own battle game to other player terminals 1 . When the player posts the game result information (transmits the game result information from the player terminal 1), the posted game result information is saved in the server 100. FIG. Guild information for each guild ID is stored in the server 100, and the guild information is updated based on the posted game result information. Guild information includes guild IDs, guild member player IDs, information on the survival and subjugation status of opponents in guild battles, information on posted game results, information on posted messages, and information on guild rankings. ing.

Then, when the other player displays the guild screen, the player terminal 1 of the other player sends the posted game result information included in the guild information of the guild ID including the player ID of the other player to the server 100. Get from Then, on the player terminals 1 of the other players, the posted game result information is displayed in the chat display area 70 based on the acquired game result information.

When the post operation unit 68a is operated on the battle detail screen shown in FIG. 9C, the game result information displayed on the display 26 at that time is output (shared) to the chat display area 70. FIG.

When the game result information relating to the battle game of the guild battle is posted, at least part of the posted game result information is displayed as shown in FIG. 11B. In addition, the battle details operation section 66b is also displayed together with at least part of the posted game result information.

Then, when the battle details operation section 66b is operated, the battle details screen (FIG. 9C) corresponding to the game result information on which the operated battle details operation section 66b is displayed is displayed on the display .

Next, the processes of the player terminal 1 and the server 100, and the functional units that perform these processes will be described. In the following, an example of basic communication processing for progressing the game and main communication processing related to guild battles will be described, and description of other processing will be omitted.

(Functional Configuration of Player Terminal 1)
FIG. 12 is a diagram for explaining the configuration of the memory 12 in the player terminal 1 and its function 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, and a display control program . Note that the programs listed in FIG. 12 are only examples, and many other programs are provided in the terminal-side game control program.

The data storage area 12b is provided with a game information storage section 90, a player information storage section 91, and a guild information storage section 92 as storage sections for storing data. 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, and a display control section 82a.

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 and a display control program 82 to function as a battle game execution section 81a and a display control section 82a, respectively.

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 when logging in, for example.

The battle game executing section 81a is responsible for controlling the execution of the battle game. For example, the battle game execution unit 81a controls actions of the ally characters and the enemy characters and derives damage points in the battle game.

The display control unit 82a 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. 13 is a diagram for explaining the configuration of memory 112 in server 100 and its function 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 program includes a game execution control program 180, a battle game execution program 181, and a reward giving program 182. FIG. The programs listed in FIG. 14 are only examples, and many other programs are provided in the server-side game control program.

The data storage area 112b is provided with a game information storage section 190, a player information storage section 191, and a guild information storage section 192 as storage sections for storing data. 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 section 100A includes a game execution control section 180a, a battle game execution section 181a, and a reward giving section 182a.

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 and a reward giving program 182 to function as a battle game executing section 181a and a reward giving section 182a, respectively.

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 sets the player information stored in the player information storage unit 191 so that the player terminal 1 can download the player information.

The battle game execution unit 181a is responsible for controlling the execution of the battle game.

The reward giving unit 182a gives a reward to the player. The reward giving unit 182a gives an item corresponding to the cleared battle game to the player who has cleared the battle game.

(Communication processing between player terminal 1 and server 100)
FIG. 14 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 activates the game application on the player terminal 1 (P1), login information is transmitted from the player terminal 1 to the server 100 .

When receiving the login information, the server 100 performs a login process (S1). FIG. 15 is a flowchart illustrating an example of login processing in the server 100. FIG. The game execution control unit 180a of the server 100 determines whether login information has been received (step S1-1). As a result, if the login information has been received (YES in S1-1), the process proceeds to step S1-2, and if the login information has not been received (NO in S1-1), the login process is executed. finish.

The game execution control unit 180a of the server 100 identifies the player ID associated with the received login information, refers to the player information corresponding to the identified player ID, and determines whether it is the player's first login of the day. Determine (S1-2). As a result, if it is the first login on the day (YES in S1-2), the process proceeds to step S1-3, and if it is not the first login on the day (NO in S1-2), step S1-6. processing moves to.

The game execution control unit 180a of the server 100 resets the competition right information included in the player information corresponding to the identified player ID (S1-3).

The game execution control unit 180a of the server 100 resets carryover right information included in the player information corresponding to the specified player ID (S1-4). The carry-over right information is set and granted (stored) in steps S5-12 to S5-13 in the server-side battle game ending process, which will be described later in detail.

The game execution control unit 180a of the server 100 resets the consumed stamina cumulative value included in the player information corresponding to the identified player ID (S1-5).

The game execution control unit 180a of the server 100 sets the player information corresponding to the specified player ID so that the player terminal 1 can download it from the player information storage unit 191 (S1-6). The player information includes a player ID, a plurality of teammate character IDs, a player's level, a player's stamina, competition right information, carrying over right information, and the like.

When acquiring player information from the player information storage unit 191 of the server 100 , the game execution control unit 80 a of the player terminal stores the acquired player information in the player information storage unit 91 .

Returning to FIG. 14, the player terminal 1 performs terminal-side guild processing (P2). FIG. 16 is a flowchart illustrating an example of terminal-side guild processing in the player terminal 1. FIG. The game execution control unit 80a of the player terminal 1 determines whether the guild operation unit 33 of FIG. 3A or 4A has been operated (P2-1). As a result, if the guild operation unit 33 has been operated (YES at P2-1), the process proceeds to step P2-2, and if the guild operation unit 33 has not been operated (NO at P2-1) , the process moves to step P2-5.

The game execution control unit 80a of the player terminal 1 transmits operation information indicating that the guild operation unit 33 has been operated to the server 100 (P2-2). The operation information includes a player ID. Also, the game execution control unit 80a of the player terminal 1 acquires guild information from the guild information storage unit 192 of the server 100, and stores the acquired guild information in the guild information storage unit 92 of the player terminal 1 (P2-3). . As described above, the guild information includes guild IDs, guild member player IDs, information on survival and subjugation status of opponents in guild battles, posted game result information, information on posted messages, and guild rankings. It contains information.

The display control unit 82a of the player terminal 1 displays the guild screen shown in FIG. 11B on the display 26 based on the guild information acquired and stored in step P2-3 (P2-4).

The game execution control unit 80a of the player terminal 1 determines whether the post operation unit 68a of FIG. 11B has been operated (P2-5). As a result, if the post operation unit 68a has been operated (YES at P2-5), the process proceeds to step P2-6, and if the post operation unit 68a has not been operated (NO at P2-5), , terminates the terminal-side guild processing.

The game execution control unit 80a of the player terminal 1 transmits posted information indicating that the posting operation unit 68a has been operated to the server 100 (P2-6). The posted information includes a player ID, information about a message (characters) input to the input section 70b in FIG. 11B, and the like.

Returning to FIG. 14, the game execution control unit 180a of the server 100 performs server-side guild processing (S2) corresponding to the terminal-side guild processing. In the server-side guild process, the game execution control unit 180a of the server 100, when receiving operation information indicating that the guild operation unit 33 has been operated from the player terminal 1, identifies the player ID associated with the operation information. Then, the guild information corresponding to the specified player ID is set to be downloadable from the guild information storage unit 192 by the player terminal 1 of the player and the player terminals 1 of other players.

Further, when receiving the posted information from the player terminal 1, the game execution control unit 180a of the server 100 identifies the player ID associated with the posted information, and responds to the identified player ID based on the posted information. The guild information stored in the guild information storage unit 192 is updated.

The player terminal 1 performs terminal-side guild battle screen processing (P3). FIG. 17 is a flowchart illustrating an example of terminal-side guild battle screen processing in the player terminal 1. FIG. The game execution control unit 80a of the player terminal 1 determines whether the guild battle operation unit 32 shown in FIG. 3A or the guild battle selection operation unit 35b shown in FIG. 3C has been operated (P3-1). As a result, if the guild battle operation section 32 or the guild battle selection operation section 35b is operated (YES in P3-1), the process proceeds to step P3-2, and the guild battle operation section 32 or the guild battle selection operation section 35b is operated. If the guild battle selection operation unit 35b has not been operated (NO in P3-1), the process proceeds to step P3-6.

The game execution control unit 80a of the player terminal 1 transmits operation information indicating that the guild battle operation unit 32 or the guild battle selection operation unit 35b has been operated to the server 100 (P3-2). The operation information includes a player ID.

Also, the game execution control unit 80a of the player terminal 1 acquires guild information from the guild information storage unit 192 of the server 100, and stores the acquired guild information in the guild information storage unit 92 of the player terminal 1 (P3-3). .

The game execution control unit 80a of the player terminal 1 acquires player information from the player information storage unit 191 of the server 100, and stores the acquired player information in the player information storage unit 91 of the player terminal 1 (P3-4). As described above, the player information includes the player ID, a plurality of teammate character IDs, the player's level, the player's stamina, the competition right information, the carryover right information, and the like.

The display control unit 82a of the player terminal 1 displays the guild battle screen shown in FIG. 4A based on the guild information acquired and stored in step P3-3 and the player information acquired and stored in step P3-4. 26 (P3-5). Here, based on the guild information, as shown in FIG. 5 or 6, bosses that can be fought and bosses that have been defeated are displayed so that the player can identify them. In addition, the opponent operation section 63a is displayed for a boss that can be fought, and the opponent operation section 63a is not displayed for a boss that has been defeated. This allows the player to freely select a boss that the player can fight against. The player has a wider range of options regarding the bosses that the player can fight against, and it is possible to improve the strategic nature of the battle game.

The game execution control unit 80a of the player terminal 1 determines whether or not the confirmation operation unit 61b shown in FIG. 4A or FIG. 7A has been operated (P3-6). As a result, if the confirmation operation section 61b has been operated (YES at P3-6), the process proceeds to step P3-7, and if the confirmation operation section 61b has not been operated (P3-6). NO), the process moves to step P3-10.

The game execution control unit 80a of the player terminal 1 transmits operation information indicating that the confirmation operation unit 61b has been operated to the server 100 (P3-7). The operation information includes a player ID.

Also, the game execution control unit 80a of the player terminal 1 acquires player information from the player information storage unit 191 of the server 100, and stores the acquired player information in the player information storage unit 91 of the player terminal 1 (P3-8). .

The display control unit 82a of the player terminal 1 displays the carryover confirmation screen shown in FIG. 4B on the display 26 based on the player information acquired and stored in step P3-8 (P3-9). Here, based on the carryover right information included in the player information, the information relating to the carryover right is displayed so that the player can identify it.

The game execution control unit 80a of the player terminal 1 determines whether or not the carryover confirmation screen shown in FIG. 4B is being displayed on the display 26 (P3-10). As a result, if the carryover confirmation screen is being displayed (YES at P3-10), the process proceeds to step P3-11, and if the carryover confirmation screen is not being displayed (NO at P3-10), The process moves to step P3-13.

The game execution control unit 80a of the player terminal 1 determines whether or not the operation unit 64b for closing the carryover confirmation screen shown in FIG. 4B has been operated (P3-11). As a result, if the closing operation section 64b is operated (YES at P3-11), the process proceeds to step P3-12, and if the closing operation section 64b is not operated (NO at P3-11). , the process moves to step P3-13.

The display control unit 82a of the player terminal 1 ends the display of the carryover confirmation screen shown in FIG. 4B on the display 26 (P3-12).

The game execution control unit 80a of the player terminal 1 determines whether or not the opponent operation unit 63a of FIG. 4A has been operated (P3-13). As a result, if the opponent operation section 63a has been operated (YES in P3-13), the process proceeds to step P3-14, and if the opponent operation section 63a has not been operated (P3-13). NO), the process moves to step P3-18.

The game execution control unit 80a of the player terminal 1 transmits operation information indicating that the opponent operation unit 63a has been operated to the server 100 (P3-14). The operation information includes opponent information, player ID, etc. corresponding to the opponent operation section 63a operated in step P3-13.

The game execution control unit 80a of the player terminal 1 acquires guild information from the guild information storage unit 192 of the server 100, and stores the acquired guild information in the guild information storage unit 92 of the player terminal 1 (P3-15). Also, the game execution control unit 80a of the player terminal 1 acquires player information from the player information storage unit 191 of the server 100, and stores the acquired player information in the player information storage unit 91 of the player terminal 1 (P3-16). .

The display control unit 82a of the player terminal 1 displays the opponent screen shown in FIG. 7A based on the guild information acquired and stored in step P3-15 and the player information acquired and stored in step P3-16. 26 (P3-17).

The game execution control unit 80a of the player terminal 1 determines whether or not the opponent screen shown in FIG. 7A is being displayed on the display 26 (P3-18). As a result, if the opponent screen is being displayed (YES at P3-18), the process proceeds to step P3-19, and if the opponent screen is not being displayed (NO at P3-18), The terminal-side guild battle screen processing ends.

The game execution control unit 80a of the player terminal 1 determines whether or not the cancel operation unit 38 in FIG. 7A has been operated (P3-19). As a result, if the cancel operation unit 38 has been operated (YES at P3-19), the process proceeds to step P3-20, and if the cancel operation unit 38 has not been operated (NO at P3-19). , the process moves to step P3-21.

The display control unit 82a of the player terminal 1 ends the display of the opponent screen shown in FIG. 7A on the display 26 (P3-20).

The game execution control unit 80a of the player terminal 1 determines whether or not the battle operation unit 37 in FIG. 7A has been operated (P3-21). As a result, if the battle operation section 37 has been operated (YES at P3-21), the process proceeds to step P3-22, and if the battle operation section 37 has not been operated (NO at P3-21). , the terminal-side guild battle screen processing ends.

The game execution control unit 80a of the player terminal 1 transmits operation information indicating that the battle operation unit 37 has been operated to the server 100 (P3-22). The operation information includes opponent information, player ID, etc. corresponding to the opponent operation section 63a operated in step P3-13.

Further, the game execution control unit 80a of the player terminal 1 acquires player information from the player information storage unit 191 of the server 100, and stores the acquired player information in the player information storage unit 91 of the player terminal 1 (P3-23). .

The display control unit 82a of the player terminal 1 displays the carryover use confirmation screen shown in FIG. 7B on the display 26 based on the player information acquired and stored in step P3-22 (P3-24). Here, based on the carryover right information and the matchup right information included in the player information, the information on the carryover right and the matchup right is displayed so that the player can identify it.

Returning to FIG. 14, the game execution control unit 180a of the server 100 performs server-side guild battle screen processing (S3) corresponding to the terminal-side guild battle screen processing. In the server-side guild battle screen processing, when the game execution control unit 180a of the server 100 receives operation information indicating that the guild battle operation unit 32 or the guild battle selection operation unit 35b has been operated from the player terminal 1, , specifies the player ID associated with the operation information, and sets the guild information corresponding to the specified player ID so that the player terminal 1 can download it from the guild information storage unit 192 . Further, the game execution control unit 180a of the server 100 sets the player information corresponding to the specified player ID so that the player terminal 1 can download it from the player information storage unit 191. FIG.

Further, when the game execution control unit 180a of the server 100 receives operation information indicating that the confirmation operation unit 61b has been operated from the player terminal 1, the game execution control unit 180a identifies the player ID associated with the operation information, and identifies the player ID. Player information corresponding to the player ID is set so that the player terminal 1 can download it from the player information storage unit 191 .

Further, when the game execution control unit 180a of the server 100 receives operation information indicating that the opponent operation unit 63a has been operated from the player terminal 1, the game execution control unit 180a identifies the player ID associated with the operation information, Guild information corresponding to the selected player ID is set so that the player terminal 1 can download it from the guild information storage unit 192 . Further, the game execution control unit 180a of the server 100 sets the player information corresponding to the specified player ID so that the player terminal 1 can download it from the player information storage unit 191. FIG.

Further, when the game execution control unit 180a of the server 100 receives the operation information indicating that the battle operation unit 37 has been operated from the player terminal 1, the game execution control unit 180a identifies the player ID associated with the operation information, and identifies the player ID. Player information corresponding to the player ID is set so that the player terminal 1 can download it from the player information storage unit 191 .

The player terminal 1 performs a guild battle pre-start process (P4). FIG. 18 is a flowchart illustrating an example of pre-start guild battle processing in the player terminal 1 . The game execution control unit 80a of the player terminal 1 determines whether or not the carryover use confirmation screen shown in FIG. 7B is being displayed on the display 26 (P4-1). As a result, if the carryover use confirmation screen is being displayed (YES at P4-1), the process proceeds to step P4-2, and if the carryover use confirmation screen is not being displayed (NO at P4-1) , the process moves to step P4-6.

The game execution control unit 80a of the player terminal 1 determines whether or not the operation unit 64b for closing the carryover use confirmation screen shown in FIG. 7B has been operated (P4-2). As a result, if the closing operation unit 64b has been operated (YES at P4-2), the process proceeds to step P4-3, and if the closing operation unit 64b has not been operated (NO at P4-2). , the process moves to step P4-4.

The display control unit 82a of the player terminal 1 ends the display of the carryover use confirmation screen shown in FIG. 7B on the display 26 (P4-3).

The game execution control unit 80a of the player terminal 1 determines whether or not the selection operation unit 65a of the carryover use confirmation screen shown in FIG. 7B has been operated (P4-4). As a result, if the selection operation section 65a has been operated (YES at P4-4), the process proceeds to step P4-5, and if the selection operation section 65a has not been operated (NO at P4-4). , the process moves to step P4-6.

The display control unit 82a of the player terminal 1 displays the party formation screen shown in FIG. 8A on the display 26 (P4-5). Here, based on the player information obtained and stored in P3-23, as shown in FIG. 8A, information on selectable characters and non-selectable characters is displayed so that the player can identify it.

The game execution control unit 80a of the player terminal 1 determines whether or not the party organization screen shown in FIG. 8A is being displayed on the display 26 (P4-6). As a result, if the party organization screen is being displayed (YES at P4-6), the process proceeds to step P4-7, and if the party organization screen is not being displayed (NO at P4-6), The process moves to step P4-13.

The game execution control unit 80a of the player terminal 1 determines whether or not a selectable character selection operation has been performed on the party formation screen shown in FIG. 8A (P4-7). As a result, if a selection operation has been performed (YES at P4-7), the process proceeds to step P4-8, and if no selection operation has been performed (NO at P4-7), the process proceeds to step P4-9. Processing moves.

The display control unit 82a of the player terminal 1 updates the display of the party formation screen based on the player's selection operation on the party selection screen (P4-8).

The game execution control unit 80a of the player terminal 1 determines whether or not the cancel operation unit 38 in FIG. 8A has been operated (P4-9). As a result, if the cancel operation unit 38 has been operated (YES at P4-9), the process proceeds to step P4-10, and if the cancel operation unit 38 has not been operated (NO at P4-9). , the process moves to step P4-11.

The display control unit 82a of the player terminal 1 ends the display of the party organization screen on the display 26 (P4-10).

The game execution control section 80a of the player terminal 1 determines whether or not the battle start operation section 39 of FIG. 8A has been operated (P4-11). As a result, if the battle start operation unit 39 has been operated (YES in P4-11), the process proceeds to step P4-12, and if the battle start operation unit 39 has not been operated (P4-11 NO), the process moves to step P4-13.

The display control unit 82a of the player terminal 1 displays the guild battle start confirmation screen shown in FIG. 8B on the display 26 (P4-12). Here, a guild battle start confirmation screen is displayed as shown in FIG. 8B based on the character selected by the player on the party formation screen.

The game execution control unit 80a of the player terminal 1 determines whether or not the guild battle start confirmation screen shown in FIG. 8B is being displayed on the display 26 (P4-13). As a result, if the guild battle start confirmation screen is being displayed (YES in P4-13), the process moves to step P4-14, and if the guild battle start confirmation screen is not being displayed (NO in P4-13) ), the guild battle pre-start process ends.

The game execution control unit 80a of the player terminal 1 determines whether or not the cancel operation unit 38 in FIG. 8B has been operated (P4-14). As a result, if the cancel operation unit 38 has been operated (YES at P4-14), the process proceeds to step P4-15, and if the cancel operation unit 38 has not been operated (NO at P4-14). , the process moves to step P4-16.

The game execution control unit 80a of the player terminal 1 determines whether or not the battle start operation unit 39 of FIG. 8B has been operated (P4-16). As a result, if the battle start operation unit 39 has been operated (YES in P4-16), the process proceeds to step P4-17, and if the battle start operation unit 39 has not been operated (P4-16 NO), the guild battle pre-start process is terminated.

The game execution control unit 80a of the player terminal 1 transmits start information indicating that the battle start operation unit 39 of FIG. 8B has been operated to the server 100 (P4-17). The start information includes information related to the type of battle game, information indicating the character selected by the player on the party formation screen, and the type of carryover right or battle right corresponding to the selection operation section 65a operated on the carryover use confirmation screen. Information, player ID, etc. are included. Although detailed explanation is omitted, when execution of a battle game related to the main quest, 1V1 battle, or 3V3 battle is selected, start information including information corresponding to the type of the selected battle game is transmitted to the server 100 .

Returning to FIG. 14, the game execution control unit 180a of the server 100 performs server-side battle game start processing (S4). FIG. 19 is a flowchart illustrating an example of server-side battle game start processing in the server 100 . The game execution control unit 180a of the server 100 determines whether or not start information has been received (S4-1). As a result, when the start information is received (YES in S4-1), the process moves to step S4-2, and when the start information is not received (NO in S4-1), the server side battle End the game start process.

The game execution control unit 180a of the server 100 determines whether the received start information is start information related to the main quest battle game (S4-2). As a result, if it is the start information related to the main quest battle game (YES in S4-2), the process proceeds to step S4-3, and if it is not the start information related to the main quest battle game (S4-2 NO), the process proceeds to step S4-10.

The game execution control unit 180a of the server 100 identifies the player ID associated with the received start information, and uses the stamina information included in the player information corresponding to the identified player ID to consume in the main quest battle game to be executed. A stamina subtraction process for subtracting the stamina to be played is executed (S4-3).

The game execution control unit 180a of the server 100 executes consumed stamina accumulation processing for updating the consumed stamina accumulated value for accumulating the stamina value subtracted in step S4-3 (S4-4).

The game execution control unit 180a of the server 100 determines whether or not the accumulated stamina consumption value updated in step S4-4 has reached a predetermined value (S4-5). As a result, if the accumulated stamina consumption value reaches the predetermined value, the process proceeds to step S4-6, and if the accumulated stamina consumption value does not reach the predetermined value, the process proceeds to step S4-10. Processing moves. Note that the predetermined value is set to 300 in this embodiment.

The game execution control unit 180a of the server 100 subtracts a predetermined value from the consumed stamina cumulative value updated in step S4-4 (S4-6).

The game execution control unit 180a of the server 100 determines whether or not the number of times the competition right has been granted on the day is less than 3 (S4-7). As a result, if the number of times the competition right is granted on the day is less than 3 (YES in S4-7), the process proceeds to step S4-8, and if the number of times the competition right is granted on the day is not less than 3 (S4 -7), the process proceeds to step S4-10.

The game execution control unit 180a of the server 100 identifies the player ID associated with the received start information, and increments the number of times of the battle right in the battle right information included in the player information corresponding to the identified player ID. A granting process is executed (S4-8).

The game execution control unit 180a of the server 100 sets the battle game start information so that it can be downloaded by the player terminal 1 (S4-9). It should be noted that the battle game start information includes information related to battle conditions in the battle game. Here, the battle conditions specifically include information about the battle time, information about the opponent, information about the party formation selected by the player, and the like.

The game execution control unit 180a of the server 100 determines whether or not the received start information is start information relating to a guild battle battle game (S4-10). As a result, if the start information is related to the battle game of the guild battle (YES in S4-10), the process proceeds to step S4-11. NO), the server-side battle game start processing ends.

The game execution control unit 180a of the server 100 refers to the information related to the type of carryover right or competition right corresponding to the selection operation unit 65a operated on the carryover use confirmation screen included in the received start information, and confirms carryover use. It is determined whether or not the competition right has been selected on the screen (S4-11). As a result, if the battle right is selected on the carryover use confirmation screen (YES in S4-11), the process moves to step S4-12, and if the battle right is not selected on the carryover use confirmation screen (S4- 11 NO), the process proceeds to step S4-14.

The game execution control unit 180a of the server 100 identifies the player ID associated with the received start information, and determines the battle right to decrement the number of battle rights from the battle right information included in the player information corresponding to the identified player ID. Information update processing is performed (S4-12).

The game execution control unit 180a of the server 100 sets the battle game start information so that it can be downloaded by the player terminal 1 (S4-13). It should be noted that the battle game start information includes information related to battle conditions in the battle game. Here, the battle conditions specifically include information about the battle time, information about the opponent, and party formation selected by the player.

The game execution control unit 180a of the server 100 refers to the information related to the type of carryover right or competition right corresponding to the selection operation unit 65a operated on the carryover use confirmation screen included in the received start information, and confirms carryover use. It is determined whether or not carryover rights have been selected on the screen (S4-14). As a result, if the carryover right is selected on the carryover use confirmation screen (YES in S4-14), the process proceeds to step S4-15, and if the carryover right is not selected on the carryover use confirmation screen (S4- 14 NO), the server-side battle game start processing ends.

The game execution control unit 180a of the server 100 identifies the player ID associated with the received start information, includes the player information corresponding to the identified player ID, and selects the carryover right on the carryover use confirmation screen. Carryover right information update processing for deleting the carryover right information is performed (S4-15). In the present embodiment, the case where the process (S4-15) related to the consumption of the carryover right is executed in the server side battle game start process has been described. It may be stored (held), and the stored (held) carry-over right may be consumed in the server-side battle game end processing.

The game execution control unit 180a of the server 100 sets the battle game start information so that it can be downloaded by the player terminal 1 (S4-16). It should be noted that the battle game start information includes information related to battle conditions in the battle game. Here, the battle conditions specifically include information about the battle time, information about the opponent, and party formation selected by the player.

Returning to FIG. 14, when receiving the battle game start information from the server 100, the player terminal 1 performs a terminal-side battle game start process for starting the battle game (P5). 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 .

After that, terminal-side battle game control processing for controlling the battle game is performed in the player terminal 1 (P6). In the terminal-side battle game control processing, based on the battle game start information, battle time in the battle game is managed, damage points are calculated, and game result information including battle timeline information is derived.

In addition, in the terminal-side battle game control process, an update process for updating various information is repeatedly executed for each frame. 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, terminal-side battle game end processing for ending the battle game is performed in the player terminal 1 (P7). In the terminal-side battle game end processing, game result information generated based on the battle record relating to the battle game with the opponent is transmitted to the server 100 . As described above, the game result information includes battle timeline information and various information related to the battle game. In the terminal-side battle game end processing, player information including reward information and carry-over right information is acquired from the server 100, and the acquired information is stored in the data storage area 12b of the player terminal 1 (game information storage unit 90, player information storage). 91).

The game execution control unit 180a of the server 100 performs server-side battle game end processing (S5) corresponding to the terminal-side battle game end processing. FIG. 20 is a flowchart illustrating an example of server-side battle game end processing in the server 100 . The game execution control unit 180a of the server 100 determines whether or not game result information has been received (S5-1). As a result, if the game result information has been received (YES in S5-1), the process proceeds to step S5-2, and if the game result information has not been received (NO in S5-1), the server End the side battle game end processing.

The game execution control unit 180a of the server 100 determines whether the received game result information is game result information related to the main quest battle game (S5-2). As a result, if the game result information is related to the main quest battle game (YES in S5-2), the process proceeds to step S5-3, and if the game result information is not related to the main quest battle game (S5 -2 NO), the process proceeds to step S5-6.

The game execution control unit 180a of the server 100 performs reward determination processing for determining a reward to be given to the player based on the received game result information (S5-3).

The game execution control unit 180a of the server 100 sets reward information so that the player terminal 1 can download it based on the reward determined in step S5-3 (S5-4).

The game execution control section 180a of the server 100 updates the player information based on the received game result information (S5-5). Here, for example, processing such as giving an experience value is performed.

The game execution control unit 180a of the server 100 determines whether the received game result information is game result information relating to a guild battle battle game (S5-6). As a result, if it is the game result information related to the battle game of the guild battle (YES in S5-6), the process proceeds to step S5-7, and if it is not the game result information related to the battle game of the guild battle (S5 If NO at -6), the server-side battle game end processing is terminated.

The game execution control unit 180a of the server 100 performs guild information update processing for updating the guild information based on the received game result information (S5-7). Here, for example, the physical strength of the opponent is updated based on the game result information.

The game execution control unit 180a of the server 100 performs reward determination processing for determining a reward to be given to the player based on the received game result information (S5-8).

The game execution control unit 180a of the server 100 sets reward information so that the player terminal 1 can download it based on the reward determined in step S5-8 (S5-9).

The game execution control section 180a of the server 100 updates the player information based on the received game result information (S5-10). Here, for example, processing such as giving an experience value is performed.

The game execution control unit 180a of the server 100 determines whether or not the carryover right generation condition is satisfied based on the received game result information (S5-11). As a result, if the carryover right generation condition is satisfied (YES in S5-11), the process proceeds to step S5-12, and if the carryover right generation condition is not satisfied (NO in S5-11), terminates the server-side battle game end processing. It should be noted that the case where the carryover right occurrence condition is established is the case where the battle game is executed by consuming the battle right and the opponent is defeated with the battle time remaining.

Based on the received game result information, the game execution control unit 180a of the server 100 sets a time limit (match time) for the carryover right based on the remaining match time when the enemy character of the opponent is defeated. A condition setting process is performed (S5-12). As described above, in the present embodiment, the longer the remaining battle time after defeating the opponent's enemy character, the longer the time limit set for the carryover right is, the longer the time limit set for the battle right. (For example, 90 seconds) is set long within the following range.

The game execution control unit 180a of the server 100 executes carryover right information update processing for giving carryover rights to the player information (S5-13). Here, based on the received game result information, the battle conditions for the battle game to be executed by consuming the given carry-over right are also set. Here, the battle conditions specifically include information about the battle time, information about the party formation selected by the player in the battle game related to the received game result information, and the like. In addition, when a plurality of players simultaneously execute a battle game against one enemy character and defeat the enemy character at the same time, each player may be given the carryover right, or the enemy character may be defeated. Only one of the plurality of players who defeated the character may be granted the carry-over right, and the battle game may be invalidated for the other players.

The game execution control unit 180a of the server 100 sets the player information including the carry-over right given to the player information in step S5-13 so that the player terminal 1 can download it (S5-14).

Returning to FIG. 14, the player terminal 1 displays the result screen shown in FIG. 9A based on the game result information and the reward information received from the server 100 (P8).

The player terminal 1 performs terminal-side result screen processing (P9). FIG. 21 is a flowchart for explaining an example of terminal-side result screen processing in the player terminal 1. FIG. The game execution control unit 80a of the player terminal 1 determines whether or not the result screen shown in FIG. 9A is being displayed on the display 26 (P9-1). As a result, if the result screen is being displayed (YES in P9-1), the process proceeds to step P9-2, and if the result screen is not being displayed (NO in P9-1), step P9 -11 is processed.

The game execution control section 80a of the player terminal 1 determines whether or not the damage report operation section of the result screen shown in FIG. 9A has been operated (P9-2). As a result, if the damage report operation unit has been operated (YES at P9-2), the process proceeds to step P9-3, and if the damage report operation unit has not been operated (NO at P9-2). , the process moves to step P9-6.

The game execution control unit 80a of the player terminal 1 transmits operation information indicating that the damage report operation unit 66a has been operated to the server 100 (P9-3). The operation information includes opponent information, player ID, and the like displayed on the result screen of FIG. 9A.

The game execution control unit 80a of the player terminal 1 acquires the game result information from the game information storage unit 190 of the server 100, and stores the acquired game result information in the game information storage unit 90 of the player terminal 1 (P9-4). .

The display control unit 82a of the player terminal 1 displays the damage report screen shown in FIG. 9B on the display 26 based on the game result information obtained and stored in step P9-4 (P9-5). The damage report screen may be displayed on the display 26 using the game result information already stored in the game information storage section 90 without acquiring the game result information in step P9-4.

The game execution control unit 80a of the player terminal 1 determines whether or not the operation unit 66c has been operated after the result screen shown in FIG. 9A (P9-6). As a result, if the operation unit 66c is operated next (YES in P9-6), the process proceeds to step P9-7, and if the operation unit 66c is not operated next (P9-6). NO), the process moves to step P9-11.

The game execution control unit 80a of the player terminal 1 then transmits operation information indicating that the operation unit 66c has been operated to the server 100 (P9-7). The operation information includes a player ID and the like.

The game execution control unit 80a of the player terminal 1 acquires guild information from the guild information storage unit 192 of the server 100, and stores the acquired guild information in the guild information storage unit 92 of the player terminal 1 (P9-8).

The game execution control unit 80a of the player terminal 1 acquires player information from the player information storage unit 191 of the server 100, and stores the acquired player information in the player information storage unit 91 of the player terminal 1 (P9-9).

The display control unit 82a of the player terminal 1 displays the guild battle screen shown in FIG. 4A based on the guild information acquired and stored in step P9-8 and the player information acquired and stored in step P9-9. 26 (P9-10). Here, based on the guild information, as shown in FIG. 5 or 6, bosses that can be fought and bosses that have been defeated are displayed so that the player can identify them. In addition, the opponent operation section 63a is displayed for a boss that can be fought, and the opponent operation section 63a is not displayed for a boss that has been defeated.

The game execution control unit 80a of the player terminal 1 determines whether or not the damage report screen shown in FIG. 9B is being displayed on the display 26 (P9-11). As a result, if the damage report screen is being displayed (YES at P9-11), the process proceeds to step P9-12, and if the damage report screen is not being displayed (NO at P9-11), End the terminal side result screen processing.

The game execution control section 80a of the player terminal 1 determines whether or not the OK operation section 67a of the damage report screen shown in FIG. 9B has been operated (P9-12). As a result, if the OK operation section 67a has been operated (YES at P9-12), the process proceeds to step P9-13, and if the OK operation section 67a has not been operated (NO at P9-12). , the terminal-side result screen processing ends.

The display control unit 82a of the player terminal 1 ends the display of the damage report screen shown in FIG. 9B on the display 26 (P9-13).

Returning to FIG. 14, the game execution control unit 180a of the server 100 performs server-side result screen processing (S6) corresponding to the terminal-side result screen processing. In the server-side result screen processing, when the game execution control unit 180a of the server 100 receives operation information indicating that the damage report operation unit has been operated from the player terminal 1, the player ID associated with the operation information, and 9A, and sets the game result information corresponding to the specified information so that the player terminal 1 can download it from the game information storage unit 190. FIG.

Further, when the game execution control unit 180a of the server 100 receives from the player terminal 1 the operation information indicating that the operation unit 66c has been operated to the next result screen shown in FIG. The ID is specified, and the guild information corresponding to the specified player ID is set so that the player terminal 1 can download it from the guild information storage unit 192 . Further, the game execution control unit 180a of the server 100 sets the player information corresponding to the specified player ID so that the player terminal 1 can download it from the player information storage unit 191. FIG.

The player terminal 1 performs terminal-side microlog screen processing (P10). FIG. 22 is a flowchart for explaining an example of terminal-side microlog screen processing in the player terminal 1. FIG. The game execution control unit 80a of the player terminal 1 determines whether or not the mylog operation unit 61a of the guild battle screen shown in FIG. 4A has been operated (P10-1). As a result, if the mylog operation unit 61a has been operated (YES in P10-1), the process proceeds to step P10-2, and if the mylog operation unit 61a has not been operated (NO in P10-1). , the process moves to step P10-5.

The game execution control unit 80a of the player terminal 1 transmits to the server 100 operation information indicating that the mylog operation unit 61a has been operated (P10-2). The operation information includes a player ID and the like.

The game execution control unit 80a of the player terminal 1 acquires microlog information included in the player information from the player information storage unit 191 of the server 100, and stores the acquired microlog information in the player information storage unit 91 of the player terminal 1 (P10 -3).

The display control unit 82a of the player terminal 1 displays the microlog screen shown in FIG. 11A on the display 26 based on the microlog information acquired and stored in step P10-3 (P10-4).

The game execution control unit 80a of the player terminal 1 determines whether or not the mylog screen shown in FIG. 11A is being displayed on the display 26 (P10-5). As a result, if the My Log screen is being displayed (YES at P10-5), the process proceeds to Step P10-6, and if the My Log screen is not being displayed (NO at P10-5), the terminal Terminate the side my log screen processing.

The game execution control unit 80a of the player terminal 1 determines whether or not a switching operation has been performed by operating the mylog selection tab 66 on the mylog screen (P10-6). As a result, if the switching operation has been performed (YES at P10-6), the process proceeds to step P10-7, and if the switching operation has not been performed (NO at P10-6), the terminal side My log screen processing ends.

The display control unit 82a of the player terminal 1 switches the display of the personal log screen based on the player's switching operation on the personal log screen (P10-7).

Returning to FIG. 14, the game execution control unit 180a of the server 100 performs the server side microlog screen (S7) corresponding to the above terminal side microlog screen processing. In the server-side mylog screen processing, when the game execution control unit 180a of the server 100 receives operation information indicating that the mylog operation unit 61a of the guild battle screen shown in FIG. 4A has been operated from the player terminal 1, the operation information is specified, and the player terminal 1 sets the mylog information corresponding to the specified player ID so that it can be downloaded from the player information storage unit 191 .

The player terminal 1 performs terminal-side battle detail screen processing (P11). FIG. 23 is a flowchart for explaining an example of terminal-side battle detail screen processing in the player terminal 1 . The game execution control unit 80a of the player terminal 1 controls the battle details operation unit 66b of the result screen shown in FIG. 9A, the battle details operation unit 66b of the my log screen shown in FIG. 11A, or the battle details operation unit of the guild screen shown in FIG. 11B. 66b is operated (P11-1). As a result, if the battle details operation section 66b has been operated (YES in P11-1), the process proceeds to step P11-2, and if the battle details operation section 66b has not been operated (P11-1). NO), the process moves to step P11-5.

The game execution control section 80a of the player terminal 1 transmits to the server 100 operation information indicating that the battle detail operation section 66b has been operated (P11-2). The operation information includes a battle log ID and the like corresponding to the operated battle details operation section 66b.

The game execution control unit 80a of the player terminal 1 acquires the game result information corresponding to the battle log ID included in the operation information transmitted to the server 100 in step P11-2 from the game information storage unit 190 of the server 100, and acquires the game result information. The game result information obtained is stored in the game information storage section 90 of the player terminal 1 (P11-3).

The display control unit 82a of the player terminal 1 displays the battle detail screen shown in FIG. 9C on the display 26 based on the game result information obtained and stored in step P11-3 (P11-4).

The game execution control unit 80a of the player terminal 1 determines whether or not the battle detail screen shown in FIG. 9C is being displayed on the display 26 (P11-5). As a result, if the battle details screen is being displayed (YES at P11-5), the process proceeds to step P11-6, and if the battle details screen is not being displayed (NO at P11-5), End the battle detail screen processing on the terminal side.

The game execution control section 80a of the player terminal 1 determines whether or not the post operation section 68a of the battle detail screen has been operated (P11-6). As a result, if the post operation unit 68a has been operated (YES at P11-6), the process proceeds to step P11-7, and if the post operation unit 68a has not been operated (NO at P11-6). , the process moves to step P11-8.

The game execution control unit 80a of the player terminal 1 transmits posted information indicating that the posting operation unit 68a has been operated to the server 100 (P11-7). The posted information includes a player ID, information about a message (characters) input to the input section 70b in FIG. 11B, and the like.

The game execution control section 80a of the player terminal 1 determines whether or not the copy operation section 68b of the battle detail screen has been operated (P11-8). As a result, if the copy operation section 68b has been operated (YES at P11-8), the process proceeds to step P11-9, and if the copy operation section 68b has not been operated (NO at P11-8). , the process moves to step P11-10.

The game execution control unit 80a of the player terminal 1 copies at least part of the information included in the game result information corresponding to the battle detail screen being displayed to the clipboard of the player terminal 1 so that it can be pasted in text format ( output) (P11-9). Here, the text content shown in FIG. 10 is copied (output) to the clipboard of the player terminal 1 . That is, based on the player's operation, the battle record is output in a text format so that it can be pasted.

The game execution control unit 80a of the player terminal 1 determines whether or not the operation unit 64b for closing the battle detail screen being displayed has been operated (P11-10). As a result, if the closing operation section 64b has been operated (YES at P11-10), the process proceeds to step P11-11, and if the closing operation section 64b has not been operated (NO at P11-10). , the terminal-side battle detail screen processing ends.

The display control unit 82a of the player terminal 1 ends the display of the battle detail screen on the display 26 (P11-11).

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 should be understood that these also belong to the technical scope of the present invention. be done.

In the above embodiment, the division of processing performed between the player terminal 1 and the server 100 is merely an example. For example, each of the above-described processes may be executed by at least one of the player terminal 1 and the server 100, and the execution timing and execution device are not particularly limited.

Also, the processing of the player terminal 1 and the server 100 in the above embodiment is merely an example. It goes without saying that the processing in the player terminal 1 and the server 100 can be appropriately designed without departing from the object of the present invention.

The information processing program for executing the processes in the above embodiments may be stored in a computer-readable non-temporary storage medium and provided as the non-temporary 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.

1 player terminal (game terminal)
100 Server S Information processing system

In order to solve the above problems, the information processing program provides a process of granting the right to play against an opponent in a battle game when a predetermined condition is satisfied, and consuming the right to play against the right to play. A process of executing the battle game with the opponent based on the set battle conditions, and a case where the opponent is defeated within the battle conditions when the battle game is executed by consuming the battle right. , a process of granting the carryover right, a process of setting the match conditions for the carryover right based on the match conditions at the time the opponent is defeated, and consuming the carryover right to perform the match A process of executing the next battle game based on the battle conditions for the carryover right without consuming the right and allowing the player to choose which of the carryover rights to consume.

In order to solve the above problems, an information processing method is an information processing method performed by one or more computers, wherein when a predetermined condition is satisfied, a process of granting the right to play against an opponent in a battle game; By consuming the right to play, a process of executing the battle game with the opponent based on the playing conditions set for the right to play, and executing the battle game by consuming the right to play. when the opponent is beaten within the battle conditions, a process of granting the carryover right, and setting the battle conditions for the carryover right based on the battle conditions at the time when the opponent is beaten. a process of consuming the carryover right to execute the next battle game based on the match condition for the carryover right without consuming the matchup right, the matchup right and the carryover right and a process of allowing the player to select whether to consume the competition right or the carry-over right, if the player has both.
including.

In order to solve the above problems, an information processing system is an information processing system comprising one or more computers, wherein the computer grants the right to play against an opponent in a battle game when a predetermined condition is met. a process of consuming the battle right to execute the battle game with the opponent based on the battle conditions set for the battle right; and a process of consuming the battle right to execute the battle game. is executed, if the opponent is beaten within the battle conditions, a process of granting the carryover right, and the battle for the carryover right based on the battle conditions at the time of defeating the opponent a process of setting a condition, a process of executing the next battle game based on the battle conditions for the carryover right without consuming the battle right by consuming the carryover right, the battle right and and a process of allowing the player to select whether to consume the competition right or the carryover right when both of the carryover rights are held.

Claims (6)

a process of granting the right to play against an opponent in a battle game when a predetermined condition is met;
A process of executing the battle game with the opponent based on the battle conditions set for the battle right by consuming the battle right;
a process of granting carryover rights when the opponent is defeated within the battle conditions when the battle game is executed by consuming the battle right;
a process of setting the match condition for the carryover right;
a process of executing the battle game with the opponent based on the battle conditions for the carryover right without consuming the battle right by consuming the carryover right;
a process of allowing the player to select whether to consume the competition right or the carryover right when both the competition right and the carryover right are held;
An information processing program that causes a computer to carry out When the player has a plurality of the carryover rights, a process of allowing the player to select which of the plurality of carryover rights to consume,
2. The information processing program according to claim 1, further executed by a computer. a process of generating a battle record relating to the battle game with the opponent;
a process of outputting the battle record by any one of a plurality of methods based on the operation of the player;
3. The information processing program according to claim 1, further executed by a computer. The plurality of methods include:
a method for outputting the match record in a group to which a plurality of the players can belong, based on the operation of the player;
4. The information processing program according to claim 3, further comprising a method of outputting said battle record in a text format so that it can be pasted based on said player's operation. An information processing method performed by one or more computers, comprising:
a process of granting the right to play against an opponent in a battle game when a predetermined condition is met;
A process of executing the battle game with the opponent based on the battle conditions set for the battle right by consuming the battle right;
a process of granting carryover rights when the opponent is defeated within the battle conditions when the battle game is executed by consuming the battle right;
a process of setting the match condition for the carryover right;
a process of executing the battle game with the opponent based on the battle conditions for the carryover right without consuming the battle right by consuming the carryover right;
a process of allowing the player to select whether to consume the competition right or the carryover right when both the competition right and the carryover right are held;
Information processing method including. An information processing system comprising one or more computers,
The computer is
a process of granting the right to play against an opponent in a battle game when a predetermined condition is met;
A process of executing the battle game with the opponent based on the battle conditions set for the battle right by consuming the battle right;
a process of granting carryover rights when the opponent is defeated within the battle conditions when the battle game is executed by consuming the battle right;
a process of setting the match condition for the carryover right;
a process of executing the battle game with the opponent based on the battle conditions for the carryover right without consuming the battle right by consuming the carryover right;
a process of allowing the player to select whether to consume the competition right or the carryover right when both the competition right and the carryover right are held;
Information processing system that carries out

Images