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

Abstract

To provide an information processing program improving operability.SOLUTION: An information processing program causes a computer to execute processing of: displaying a game screen during a play: capable of receiving, from external devices, a plurality of pieces of invitation information of inviting to participate in any of a plurality of types of invitation games; in response to the received invitation information, displaying a notification image capable of identifying a part of game information relating to the invitation games in a state of maintaining the display of the game screen during the play, and when receiving a plurality of pieces of invitation information, displaying a notification image for every invitation information; when a player's operation of selecting a notification image is input, displaying, in a state of discriminating the game screen during the play, a prescribed image including at least detailed game information more than the notification image and an operation section of receiving a participation operation in the invitation game; and when the participation operation is input to the operation section, executing operation for participating in the invitation game.SELECTED DRAWING: Figure 6

Description

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

Conventionally, a communication game in which a plurality of players can participate (hereinafter referred to as multiplayer) is known. In multiplayer, it is necessary to match people who want to participate in the game. For example, Patent Literature 1 proposes a game system in which, when a host player creates a room, invitation information is sent to other players who are playing the game.

According to this game system, the mark indicating the reception of the invitation information is highlighted on the game screen of the player who has received the invitation information. When the player taps this mark, detailed information about the invited game is displayed.

Patent No. 6634534

According to the game system described above, the operation of the player who receives the invitation information may become complicated. Therefore, there is a demand for further improvement in operability.

An object of the present invention is to provide an information processing program, an information processing method, and an information processing system capable of improving operability.

In order to solve the above problem, an information processing program can receive a plurality of pieces of invitation information for inviting participation in one of a plurality of types of invitation games from a display control unit that displays a game screen that is being played, from an external device. A receiving unit, corresponding to the received invitation information, displays a notification image capable of identifying part of the game information related to the invited game while maintaining the display of the game screen being played, and receives a plurality of pieces of invitation information. In this case, when a notification unit that displays a notification image for each invitation information and a player's operation to select a notification image are input, game information more detailed than the notification image and an operation to participate in the invited game are received. A predetermined image display unit that displays a predetermined image including at least an operation unit in a state in which the game screen being played can be identified, and a process for participating in the invitation game when a participation operation is input to the operation unit. and a processing unit that executes a computer to function.

Further, the predetermined image display unit may hide the predetermined image based on the input of the predetermined operation including at least the participation operation.

Further, the invited game may be executed by connecting the player terminals of each of the plurality of players for communication, and the game information may include at least one of the type of the invited game and information about the participating players. good.

Also, when a plurality of notification images are displayed, the invitation games corresponding to the plurality of notification images may be of different types.

In order to solve the above problems, an information processing method includes steps of displaying a screen of a game being played, and receiving a plurality of pieces of invitation information for inviting participation in one of a plurality of types of invitation games from an external device. , corresponding to the received invitation information, displays a notification image that can identify a part of the game information related to the invited game while maintaining the display of the game screen being played, and when multiple pieces of invitation information are received, displaying a notification image for each piece of invitation information; and, when a player's operation for selecting a notification image is input, game information more detailed than the notification image and an operation unit for accepting an operation to participate in the invited game. a step of displaying a predetermined image including a game screen in a state in which the game screen being played can be identified; include.

In order to solve the above problems, an information processing system is an information processing system in which a player terminal and an external device are connected for communication, and the player terminal includes a display control unit for displaying a game screen during play, A receiving unit that can receive a plurality of invitation information inviting participation in any of the invited games from an external device; The game screen being played is displayed while the display is maintained, and when a plurality of pieces of invitation information are received, a notification unit that displays a notification image for each piece of invitation information and a player operation that selects the notification image are input. a predetermined image display unit that displays a predetermined image including at least game information that is more detailed than the notification image and an operation unit that accepts an operation to participate in the invited game in a state in which the game screen being played can be identified; a processing unit that executes processing for participating in the invited game when a participation operation is input to the operation unit.

According to the present invention, operability can be improved.

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 party formation screen. FIG. 3B is a diagram illustrating an example of an information confirmation screen. FIG. 3C is a diagram showing an example of a battle game selection page on the quest screen. FIG. 3D is a diagram illustrating an example of a play content selection page on the quest screen. FIG. 4A is a diagram illustrating an example of a play content selection page when single play is selected. FIG. 4B is a diagram illustrating an example of a battle screen. FIG. 4C is a diagram illustrating an example of a result screen. FIG. 5A is a diagram illustrating an example of a play content selection page when multiplay is selected. FIG. 5B is a diagram illustrating an example of the room selection page. FIG. 5C is a diagram illustrating an example of a subject selection page. FIG. 5D is a diagram illustrating an example of a room details page. FIG. 6A is a diagram illustrating an example of notification of reception of invitation information on a normal screen. FIG. 6B is a diagram illustrating an example of notification of reception of invitation information on the battle screen. FIG. 6C is a diagram illustrating an example of an invitation information image. FIG. 6D is a diagram illustrating an example of a pause screen. FIG. 7A is a diagram for explaining priority points. FIG. 7B is a diagram for explaining the update conditions for priority points. FIG. 8 is a first diagram for explaining list update processing. FIG. 9 is a second diagram for explaining list update processing. FIG. 10 is a third diagram for explaining list update processing. FIG. 11 is a fourth diagram for explaining list update processing. FIG. 12A is a diagram explaining the play state of the player terminal. FIG. 12B is a diagram illustrating the timing of confirmation of receipt of invitation information. FIG. 13 is a sequence diagram illustrating basic processing of the player terminal and server. FIG. 14 is a sequence diagram illustrating processing of the player terminal and the server when multiplay is executed. FIG. 15 is a sequence diagram illustrating the processing of the player terminal and server when it is not possible to participate in multiplay. FIG. 16 is a sequence diagram illustrating processing of the player terminal and the server when participation in multiplay is refused. FIG. 17 is a diagram for explaining the configuration of a memory in a player terminal and functions as a computer. FIG. 18 is a flowchart illustrating an example of terminal-side game processing in the player terminal. FIG. 19 is a flowchart illustrating an example of room creation related processing in the player terminal. FIG. 20 is a flowchart illustrating an example of invitation information reception processing in a player terminal. FIG. 21 is a flowchart illustrating an example of invitation information confirmation processing in a player terminal. FIG. 22 is a first flowchart illustrating an example of post-reception processing of invitation information in the player terminal. FIG. 23 is a second flowchart illustrating an example of post-reception processing of invitation information in the player terminal. FIG. 24 is a flowchart illustrating an example of multiplay end processing in the player terminal. FIG. 25 is a diagram for explaining the configuration of a memory in a server and functions as a computer. FIG. 26 is a flowchart illustrating an example of server-side game processing in the server. FIG. 27 is a flowchart illustrating an example of request information reception processing in the server. FIG. 28 is a flowchart illustrating an example of information update processing in the server. FIG. 29 is a flowchart illustrating an example of multiplay end processing in the server. FIG. 30 is a flowchart illustrating an example of rearrangement processing in the server.

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

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

The player terminal 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 who plays the game. The server 100 also updates the accumulated information and controls the progress of the game based on operations input from the player terminal 1 .

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 an information processing program stored in the memory 12 to control progress of the game. The memory 12 is composed of a ROM (Read Only Memory) or a RAM (Random Access Memory), and stores programs and various data necessary for controlling the progress of the game. Memory 12 is connected to CPU 10 via bus 14 .

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

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

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

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

The output unit 24 includes a display device and a speaker. Note that the output unit 24 may be a device connected (externally attached) to the player terminal 1 . In this embodiment, the player terminal 1 includes a display 26 as the output unit 24 and a touch panel provided as an input unit 22 so as to overlap the display 26 .

(game content)
Next, the content of the game provided by the information processing system S (game device G) of this embodiment will be described using an example. In this embodiment, a so-called battle game is provided in which friendly characters battle enemy characters. Specifically, in the game of this embodiment, a plurality of teammate characters are provided. The player selects a plurality of (here, three) ally characters from the provided ally characters to form a party. Also, the player can play a plurality of types of battle games with different enemy characters and different degrees of difficulty. In other words, in the embodiment, multiple types of battle games are provided. In the battle game, the object is for the player to operate friendly characters organized in a party to defeat enemy characters and obtain rewards.

FIG. 3A is a diagram showing an example of a party formation screen. FIG. 3B is a diagram illustrating an example of an information confirmation screen. FIG. 3C is a diagram showing an example of a battle game selection page on the quest screen. FIG. 3D is a diagram illustrating an example of a play content selection page on the quest screen. The display 26 of the player terminal 1 displays game screens as shown in FIGS. 3A, 3B, 3C, and 3D. In this embodiment, the game screen is roughly divided into a normal screen and a battle screen.

The normal screen is mainly a screen for the player to confirm various settings and information. On the other hand, the battle screen is a screen displayed on the display 26 from the start to the end of the battle game. Here, all screens other than the battle screen are normal screens. The normal screen is roughly divided into four screens: a home screen (not shown), a party formation screen shown in FIG. 3A, an information confirmation screen shown in FIG. 3B, and a quest screen shown in FIGS. 3C and 3D.

The party formation screen and the quest screen are composed of a plurality of pages, and the pages are switched by the player's operation. In the normal screen, a header display area 30 is provided in the upper part of the display 26. FIG. A stamina display bar 32 indicating the stamina of the player is displayed in the header display area 30 .

Note that stamina is a parameter required for playing the battle game. In this embodiment, a plurality of types of battle games are provided, and a stamina consumption value required for playing is set for each battle game. Since the player consumes stamina to play the battle game, the player cannot play the battle game when the stamina is insufficient.

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 32 is displayed so that the current remaining amount of stamina can be visually grasped with respect to the upper limit of stamina.

A notification image 34 is displayed at the left end of the header display area 30 . Although details will be described later, the notification image 34 notifies the player of reception of battle game invitation information or event guide information. The notification image 34 is displayed in a non-notification mode when neither the invitation information nor the guidance information is received. Note that the notification image 34 in the non-notification mode is displayed in a light color as a whole. On the other hand, when at least one of the invitation information and the guide information is received, the notification image 34 is displayed in the notification mode. The notification image 34 in the notification mode is highlighted in a more conspicuous color than in the non-report mode.

Also, on the normal screen, a menu bar 36 is displayed at the bottom of the display 26 . The menu bar 36 is provided with a plurality of operation units that can be operated (tapped) by the player. Here, as an example of the operation unit, the menu bar 36 includes a home screen selection unit 36a marked with "Home", a party organization screen selection unit 36b marked with "Party", and a quest screen marked with "Quest". A selection section 36c and an information confirmation screen selection section 36d marked with "Info" are provided.

When the home screen selection portion 36 a is tapped, the home screen is displayed on the display 26 . Also, when the party organization screen selection portion 36b is tapped, the party organization screen shown in FIG. 3A is displayed on the display 26. FIG. Similarly, when the information confirmation screen selection portion 36d is tapped, the information confirmation screen shown in FIG. 3B is displayed on the display 26, and when the quest screen selection portion 36c is tapped, the quest screen (battle game selection) shown in FIG. page) is displayed on the display 26 .

As described above, the normal screen is roughly divided into four screens. In the menu bar 36, the operation section corresponding to each screen is highlighted so that the screen being displayed on the display 26 can be identified. Note that when the page transitions within the normal screen, or when transitioning to a different normal screen, the stamina display bar 32, the notification image 34, and the menu bar 36 remain displayed. That is, in the screen transition of the normal screen, images other than the header display area 30 and the menu bar 36 are switched.

On the party organization screen shown in FIG. 3A, all teammate characters possessed by the player are displayed. The player can select three friendly characters from the displayed friendly characters to organize one party. Here, up to six parties can be organized and stored. 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 of the upper limit.

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

Furthermore, on the party formation screen, the player can equip (set) equipment such as weapons and protective gears to the ally characters included in the party. Each piece of equipment is set with an additional value for attack power, defense power, and the like. When equipment is equipped, the added value of each equipment is added to the above-mentioned base value, and the fighting power of the ally character can be increased.

On the information confirmation screen shown in FIG. 3B, player information regarding the player is displayed. As the player information, for example, the player name, player experience value, player level, player rank, number of owned characters (number of allied characters owned by the player), number of followers, and number of mutual followers are displayed. In this embodiment, a follower indicates another player who is set as a so-called favorite or comrade-in-arms by the player. Further, in the present embodiment, a mutual follower indicates a player who is set as a follower of each other.

On the battle game selection page of the quest screen shown in FIG. 3C, a plurality of selection tabs 38 indicating the types of provided battle games, that is, battle game names, are displayed. Here, 10 types of battle games are provided, and 10 selection tabs 38 are displayed. Each battle game has its own opening conditions. The unlocking conditions include, for example, that the player experience value, player level, and player rank are equal to or higher than a predetermined value, that another predetermined battle game has been cleared, and the like.

A player can only play a battle game that satisfies the opening conditions. Therefore, on the battle game selection page, the selection tabs 38 of battle games that do not satisfy the opening conditions are displayed with a lock as shown. Also, only the selection tab 38 of the battle game that satisfies the release condition accepts the player's operation (tap).

When the selection tab 38 is tapped on the battle game selection page, a play content selection page shown in FIG. 3D is displayed. On this play content selection page, a party to be used for the battle game can be selected from the parties formed on the party formation screen. In addition, in this embodiment, as play types, single play in which the player plays the battle game alone, and multiplayer in which the battle game is played in cooperation with other players through communication are provided. A single play tab 40a and a multiplay tab 40b are displayed on the play content selection page.

FIG. 4A is a diagram illustrating an example of a play content selection page when single play is selected. FIG. 4B is a diagram illustrating an example of a battle screen. FIG. 4C is a diagram illustrating an example of a result screen. As shown in FIG. 4A, single play starts when the single play tab 40a is operated with the type of battle game and the party to be used in the battle game selected. Note that, hereinafter, a teammate character included in a party used in a battle game, that is, a teammate character operated by a player in a battle game will be referred to as a "player character". In the battle game, the player operates the input unit 22 of the player terminal 1 to move the player character.

During the battle game, a battle screen is displayed as shown in FIG. 4B. A player character and an enemy character are displayed on the display 26 on the battle screen. The player character moves according to the player's operation, and damages the enemy character or receives damage from the enemy character. Also, the enemy character operates under computer control, and inflicts damage on the player character or receives damage from the player 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 the player character, the damage points are subtracted from the life points of the player character. When the life points of the enemy characters become 0, the player wins, and when the life points of all the player characters become 0, the player loses.

Here, on the battle screen, as shown in FIG. 4B, the menu bar 36 displayed on the normal screen is hidden. Also, in the header display area 30, the stamina display bar 32 is hidden, and the life points of each player character are displayed. Furthermore, an operation tab 42 is displayed in the header display area 30 on the battle screen. The display position of the operation tab 42 is the same as the position where at least part of the notification image 34 is displayed on the normal screen in the header display area 30 .

When the operation tab 42 is tapped during the battle game, the battle game is interrupted. At this time, an interruption screen (not shown) is displayed on the display 26 . The interruption screen is provided with a retirement operation section and a restart operation section, and the player can select retirement (end) or restart of the battle game by tapping these operation sections.

When the battle game ends normally (normally ends), a result screen is displayed on the display 26 as shown in FIG. 4C. In the present embodiment, normal termination of the battle game includes three termination patterns: premature termination due to retirement, victory termination in which victory is determined in the battle game, and defeat termination in which defeat is determined in the battle game. FIG. 4C shows the result screen at the end of winning as an example, but the result screen differs for each ending pattern.

The result screen displays an end operation section 44 labeled "Close", and when the end operation section 44 is tapped, the display on the display 26 switches from the battle screen to the normal screen. That is, the result screen is part of the battle screen. Note that the normal screen switched from the result screen may be the screen displayed immediately before switching to the battle screen, or may be a predetermined screen such as the home screen. Thus, the battle game ends when the display of the result screen ends.

FIG. 5A is a diagram illustrating an example of a play content selection page when multiplay is selected. FIG. 5B is a diagram illustrating an example of the room selection page. FIG. 5C is a diagram illustrating an example of a subject selection page. FIG. 5D is a diagram illustrating an example of a room details page. As shown in FIG. 5A, assume that the multiplayer tab 40b is tapped while the type of battle game and the party to be used in the battle game are selected.

In this case, the room selection page of the quest screen is displayed as shown in FIG. 5B. On the room selection page, a room creation tab 46 labeled "Create Room" is displayed. In the present embodiment, a "room" indicates a place where all players participating in multiplay share information, and may also refer to an area secured by the server 100 for multiplay.

The player can create a room by himself/herself by tapping the room creation tab 46 (inputting a request operation) when playing multiplayer. In the following description, the player who created the room in multiplay is called the host player. A player who enters a room created by another player is called a guest player.

When the room creation tab 46 is tapped, a target person selection page of the quest screen is displayed as shown in FIG. 5C. The subject selection page displays a follower tab 48a labeled "Follower", a mutual follower tab 48b labeled "mutual follower", and a random tab 48c labeled "random". A player who creates a room can select a target person (guest player) to be invited to the room created by the player on the target person selection page.

Specifically, when the follower tab 48a is operated, a player set as a follower by the player creating the room is set as a target person who can receive the invitation information. Note that, in the present embodiment, invitation information can be received only by a player who is set as a target person, and a player who is not set as a target person does not receive the invitation information. Also, although the details will be described later, the target person will not receive the invitation information unless certain conditions are met. Therefore, it can be said that the target person is the player who has obtained the right to receive the invitation information.

When the mutual follower tab 48b is operated, a player who is set as a mutual follower by the player creating the room is set as the target person. On the other hand, when the random tab 48c is operated, all players registered in the server 100 are set as targets. The player terminal 1 of the player set as the target person receives the invitation information when communicating with the server 100 . The target person who has received the invitation information can decide whether or not to enter the room, that is, whether or not to participate in the multiplay. In this way, entry into the room is limited to players who have received the invitation information.

For example, as shown in FIG. 5C, when the random tab 48c is tapped, the room details page of the quest screen is displayed as shown in FIG. 5D. Various information (room information) including party information indicating the party selected by the host player is displayed on the room details page. The host player's room detail page also displays a start tab 50 marked "Ready". Multiplay starts when the host player taps the start tab 50 .

FIG. 6A is a diagram illustrating an example of notification of reception of invitation information on a normal screen. FIG. 6B is a diagram illustrating an example of notification of reception of invitation information on the battle screen. FIG. 6C is a diagram illustrating an example of the invitation information image 54. As shown in FIG. FIG. 6D is a diagram illustrating an example of a pause screen. For example, as shown in FIG. 6A, it is assumed that an information confirmation screen is displayed on the display 26 of the player terminal 1 of the target person. In this state, when the player terminal 1 receives the invitation information, the notification image 34 in the header display area 30 switches from the non-notification mode to the notification mode, as shown in the drawing. Although details will be described later, the player terminal 1 can hold up to three pieces of invitation information. The notification image 34 in the notification mode may notify the number of pieces of invitation information held by the player terminal 1 .

A thumbnail display area 52 is also provided on the display 26 . The thumbnail display area 52 is provided above the left end of the display 26 and near the notification image 34 . More specifically, the thumbnail display area 52 is provided below the notification image 34 . The thumbnail display area 52 is usually blank and cannot be identified by the player.

Then, when the player terminal 1 newly receives invitation information, a thumbnail image 52 a is displayed in the thumbnail display area 52 . The thumbnail image 52a is provided for each type of battle game. For example, the thumbnail image 52a corresponding to the type of battle game selected by the host player, that is, the battle game to which the host player is invited is displayed in the thumbnail display area 52. .

That is, when new invitation information is received, the thumbnail image 52 a corresponding to the received invitation information is displayed in the thumbnail display area 52 . Here, enemy characters of the battle game are displayed in the thumbnail image 52a. The player can grasp the type of battle game to which the player is invited from the enemy character displayed in the thumbnail image 52a.

Note that the display content of the thumbnail image 52a is not particularly limited. For example, a name set for each type of battle game may be displayed. Alternatively, if an identification mark is set for each type of battle game throughout the game, the identification mark may be displayed in the thumbnail image 52a. In this way, it is desirable to be able to identify the type of battle game to which the player is invited by the thumbnail image 52a.

However, the thumbnail image 52a is not limited to a mode in which the type of battle game can be identified. For example, the thumbnail image 52a may be configured to identify whether the invited subject is a follower, mutual follower, or random. Alternatively, the thumbnail image 52a may be configured such that some information regarding the host player, such as the host player's name and level, can be identified. In any case, the thumbnail image 52a only needs to be displayed in correspondence with the invitation information, and the display mode and information that can be identified by the player are not particularly limited.

Note that the thumbnail display area 52 is provided within a display area where various game images are displayed on the normal screen and the battle screen. Also, the thumbnail image 52a is displayed while maintaining the display of the game screen being played. That is, the thumbnail image 52a is displayed superimposed on the game screen being played. However, the thumbnail image 52a has a transmittance, so that even when the thumbnail image 52a is displayed, the player can see the game screen being played through the thumbnail image 52a. .

Further, the thumbnail image 52a is automatically erased from the thumbnail display area 52 and becomes non-display after a predetermined time (for example, 10 seconds) has elapsed. That is, the thumbnail image 52a is displayed only for a predetermined period of time after new invitation information is received. However, even after the thumbnail image 52a is hidden, the notification image 34 is displayed in the notification mode. Therefore, the player can recognize that the invitation information has been received even after the thumbnail image 52a is hidden.

Also, for example, as shown in FIG. 6B, it is assumed that a battle screen is displayed on the display 26 of the player terminal 1 of the target person. As described above, on the battle screen, the operation tab 42 is normally displayed in the header display area 30 (see FIG. 4B). , to the notification image 34 of the notification mode.

Further, even while the battle screen is being displayed, if new invitation information is received, the thumbnail image 52a is displayed in the thumbnail display area 52, as is the case with the normal screen being displayed. Note that although the position of the thumbnail display area 52 is common between the normal screen and the battle screen here, the position of the thumbnail display area 52 may be different between the normal screen and the battle screen.

Also, the thumbnail image 52a is common to the normal screen and the battle screen. However, different thumbnail images 52a are provided for the normal screen and the battle screen, and even if the same invitation information is received, different thumbnail images 52a may be displayed depending on the screen being displayed. As an example, the thumbnail image 52a displayed on the normal screen may contain more information than the thumbnail image 52a displayed on the battle screen. As another example, the thumbnail image 52a displayed on the normal screen may have a larger display area than the thumbnail image 52a displayed on the battle screen, and may be easily noticed by the player.

During the display of the battle screen, that is, during the battle game, player operations are frequently requested. Also, depending on the content of the battle game, the timing of the player's operation may be important. On the other hand, the player's operation timing is not important while the normal screen is being displayed. Therefore, during the display of the battle screen, it is often difficult for the player to immediately react to the display of the thumbnail image 52a, or it is difficult to grasp detailed information, compared to the display of the normal screen. be. Therefore, as described above, if the thumbnail image 52a displayed on the battle screen is simpler than the thumbnail image 52a displayed on the normal screen, the player is less likely to be annoyed.

Note that when the thumbnail image 52a that was once hidden is displayed again, the display of the thumbnail image 52a may continue until the invitation information is deleted.

Here, in this embodiment, the player terminal 1 can receive a plurality of pieces of invitation information from the server 100 . Here, the player terminal 1 can simultaneously hold up to three pieces of invitation information. FIG. 6B shows a state in which the player terminal 1 has received three pieces of invitation information. For example, assume that the player terminal 1 newly receives a third piece of invitation information while holding two pieces of invitation information.

In this case, in addition to the thumbnail image 52a corresponding to the newly received invitation information, the thumbnail image 52a corresponding to the previously received invitation information is also displayed at the same time. Thus, when a plurality of pieces of invitation information are received, a thumbnail image 52a is displayed for each piece of invitation information. As a result, the player can easily grasp the number of invitation information received and what kind of battle game the player is invited to.

Here, when new invitation information is received, the thumbnail image 52a corresponding to already received invitation information is displayed. However, when new invitation information is received, only the thumbnail image 52a corresponding to the new invitation information may be displayed.

FIG. 6C shows a state in which the notification image 34 or the thumbnail image 52a is tapped while the battle screen shown in FIG. 6B is being displayed. That is, when the notification image 34 or the thumbnail image 52a is tapped in the state shown in FIG. 6B, the screen transitions to the state shown in FIG. 6C. As shown in FIG. 6C, when the notification image 34 or the thumbnail image 52a is tapped while the battle screen is being displayed, the battle game is interrupted in the same manner as when the operation tab 42 is tapped. At this time, the battle screen at the time of interruption is still displayed, and the entire display 26 is darkened. In addition, in the stop display state of the battle screen, the notification image 34 is switched to the operation tab 42, and the invitation information image 54 is displayed superimposed on the battle screen at the time of interruption.

The invitation information image 54 is displayed for each thumbnail image 52a, that is, for each invitation information. Therefore, three invitation information images 54 are displayed here because three pieces of invitation information have been received. The invitation information image 54 includes a game information display portion 54a and an operation portion 54b. Part or all of the information included in the invitation information is displayed in the game information display portion 54a. Specifically, in the game information display section 54a, the type of battle game is indicated by an image of an enemy character appearing in the battle game (character image on the left side in the drawing).

Here, the image of the enemy character displayed in the game information display section 54a, that is, the image indicating the type of battle game is the same as the image displayed in the thumbnail image 52a. The game information display section 54a also displays information indicating the difficulty level of the battle game (shown as "advanced" or "intermediate" in the drawing). For example, battle games are classified into a plurality of types with different enemy characters, and each type of battle game is further classified into a plurality of game modes with different degrees of difficulty. Therefore, the difficulty level of the battle game is displayed in the game information display section 54a together with the type of the battle game.

Further, the game information display section 54a displays an image of a teammate character participating in the battle game (character image on the right side in the drawing). Here, among allied characters participating in the battle game, allied characters selected by the host player are displayed. Thus, in the game information display portion 54a of the invitation information image 54, game information regarding the battle game corresponding to the thumbnail image 52a is displayed.

More detailed information than the information indicated by the thumbnail image 52a is displayed in the game information display section 54a. Specifically, the player can grasp only the type of battle game from the thumbnail image 52a. On the other hand, the player can grasp the type of the battle game, the difficulty level of the battle game, the types of some teammate characters participating in the battle game, information about the host player, and the like from the game information display section 54a.

The operation unit 54b is provided with a delete tab marked "delete" and a join tab marked "participate". The delete tab accepts a delete operation for deleting the invitation information, and the join tab accepts a join operation for joining the battle game to which the player is invited. The operation section 54b displays the corresponding game information display section 54a in a identifiable manner. When the delete tab is tapped, the corresponding invitation information is deleted from the player terminal 1 and the invitation information image 54 is hidden.

For example, as shown in FIG. 6C, among the upper, middle, and lower operating sections 54b, the delete tab of the upper operating section 54b is tapped. In this case, the invitation information corresponding to the upper invitation information image 54 is deleted, and the upper invitation information image 54 is hidden. However, in this case, the middle and lower invitation information images 54 remain displayed.

Also, when the participation tab is tapped and a participation operation is input, a process for participating in the battle game to which the player is invited is executed. Specifically, when a participation operation is input, participation information is transmitted from the player terminal 1 of the target person to the server 100 . When the participation information is input, the server 100 determines whether or not to enter the invited room.

For example, in the invited room, if multiplayer has already started (playing), if the maximum number of guest players have entered the room (full), or if the room has disappeared (disbanded) , it is determined that it is impossible to enter the room. In this case, the display 26 of the player terminal 1 displays an entry-impossible screen (not shown) informing that entry into the room is impossible.

On the other hand, it is assumed that server 100 determines that entry to the room is possible. In this case, the player information of the target person who sent the participation information is added to the room, and the room information is updated. In this way, when the participation operation is performed and the room can be entered, the target person is set as a guest player. Then, when the room information is updated, the host player and all guest players receive the updated room information.

At this time, a room details page (not shown) is displayed on the player terminal 1 of the guest player (hereinafter referred to as "guest terminal"). With the updated room information, the player information of the host player and the player information of all guest players are displayed on the room details page. As described above, the start tab 50 is provided on the room details page displayed on the player terminal 1 of the host player (hereinafter referred to as "host terminal"). On the other hand, the room details page displayed on the guest terminal does not have the start tab 50 . Therefore, only the host player can start multiplay.

Note that the room details page displayed on the guest terminal does not include an operation unit for receiving an operation to exit the room. In other words, the guest player cannot formally leave the room in which he or she has entered. This prevents the guest player from repeatedly entering and leaving the room, and realizes an early start of the multi-play. However, an operation unit for leaving the room may be provided on the room details page of the guest terminal so that the guest player can leave the room. Further, the room detail page displayed on the host terminal may be provided with an operation unit for intentionally disbanding the room.

As described above, when participating in the invited battle game by inputting the participation operation to the participation tab of the operation unit 54b, more specifically, when entering the invited room, all invitation information is deleted.

On the other hand, if the player is unable to enter the room, the original game screen is displayed after being notified that the room cannot be entered. At this time, the invitation information selected by the player is deleted, and the invitation information image 54 with the participation tab tapped is hidden. However, in this case, since the other invitation information is not deleted, the invitation information image 54 corresponding to the invitation information not selected by the player can be displayed.

As shown in FIG. 6C, when an area other than the invitation information image 54 is tapped while the invitation information image 54 is displayed, the interrupted battle game is resumed. In this case, the invitation information image 54 is hidden, and the battle screen is displayed as shown in FIG. 6B. However, when the battle game is resumed after being interrupted, the thumbnail image 52a is hidden.

As described above, the thumbnail image 52a remains displayed for 10 seconds after receiving the invitation information, and is automatically hidden after 10 seconds. Further, when the notification image 34 or the thumbnail image 52a is tapped while the thumbnail image 52a is being displayed and the invitation information image 54 is displayed, the thumbnail image 52a is also hidden.

For example, assume that the invitation information image 54 is displayed by tapping the notification image 34 or the thumbnail image 52a immediately after the invitation information is received and the thumbnail image 52a is displayed. After that, when the battle game is immediately restarted, the thumbnail image 52a may be displayed if 10 seconds have not passed since the invitation information was received. Alternatively, when the battle game is restarted after the invitation information image 54 is displayed, the thumbnail image 52a may be displayed for a predetermined time after the battle game is restarted. Furthermore, when the invitation information image 54 is displayed, the thumbnail image 52a may be displayed at the same time.

As described above, when the invitation information is received during the battle game, the notification image 34 is displayed in the notification mode, and the thumbnail image 52a is displayed superimposed on the battle screen. The thumbnail image 52a disappears after 10 seconds have passed, but the notification image 34 remains displayed in the notification mode. In this way, even when the notification image 34 displayed in the notification mode is tapped after the thumbnail image 52a is hidden, as shown in FIG. An invitation information image 54 is superimposed and displayed.

Further, when the operation tab 42 is tapped in the state shown in FIG. 6C, a pause screen is displayed as shown in FIG. 6D. On the pause screen, a pause dialog 56 is displayed superimposed on the battle screen at the time of interruption. The pause dialog 56 displays information about the suspended battle game. The pause dialog 56 is also provided with an operation tab 42 . When the operation tab 42 is tapped while the pause dialog 56 is being displayed, the pause dialog 56 frames out toward the left side of the display 26 and the battle game is resumed.

Note that when the invitation information is not received, an operation tab 42 is displayed on the upper left of the display 26 while the battle screen is being displayed. If the operation tab 42 is tapped at this time, an interruption screen provided with a retirement operation section and a restart operation section is displayed as described above when the battle game is interrupted. Thus, when the operation tab 42 is tapped during the battle game, the interruption screen is displayed. If it is, a pause screen different from the interruption screen is displayed.

However, a common screen may be displayed when the operation tab 42 is tapped during the battle game and when the operation tab 42 is tapped while the invitation information image 54 is being displayed. Also, the pause dialog 56 may be provided with a retirement operation section and a restart operation section.

As described above, since the invitation information image 54 displays detailed information about the battle game to which the invitation is invited, the display of the invitation information image 54 can be said to be the opening of the invitation information. That is, the invitation information is opened by tapping the notification image 34 or the thumbnail image 52a in the notification mode. On the other hand, when the thumbnail image 52a is displayed, the invitation information is not opened.

Further, after the invitation information image 54 is displayed, if the battle game is restarted without tapping the operation unit 54b, or if the pause screen is displayed, the invitation information remains held. there is In other words, after the invitation information image 54 is displayed, an operation to transition the screen without deleting the invitation information is a pending operation, and when the pending operation is input, participation in the invited battle game is suspended. state.

Next, a method of extracting a target person in the server 100 will be described, and then a method of receiving and notifying the invitation information in the player terminal 1 will be described.

(Target extraction method)
FIG. 7A is a diagram for explaining priority points. FIG. 7B is a diagram for explaining the update conditions for priority points. The server 100 stores player information for each player (player ID). Player information includes, for example, player experience, player level, player rank, possessed characters, followers, mutual followers, party information, and various other information necessary to play the game.

The player information also includes priority information as information for extracting the target person to receive the invitation information. The server 100 accumulates player information including priority information in the storage unit 118 for each player, and updates the priority information according to preset update conditions.

In this embodiment, priority points are provided as priority information. As shown in FIG. 7A, the priority points are set to have a maximum value of 999 points and a minimum value of 0 points, and are updated within a range of 0 to 999. An initial value of 100 points is set for the priority points, and when a predetermined update condition is satisfied, the priority points are updated to the initial value.

When the random tab 48c is tapped when creating a room, the server 100 randomly extracts target persons who can receive invitation information from all the players. At this time, the server 100 preferentially sets a player with a high priority point as a target person. Therefore, a player with a higher priority point is more likely to receive invitation information.

The priority point update conditions are set as shown in FIG. 7B. Specifically, when the invitation information is received as a target person, "4" is subtracted from the priority points of the target person. Further, when the invitation information image 54 is displayed by tapping the notification image 34 or the thumbnail image 52a after the target person receives the invitation information, the target person's priority point is increased by "1".

Also, when the target person taps the participation tab of the operation unit 54b to perform the participation operation, but cannot participate in the multiplay, the target person's priority points are added by "4". In addition, there are two cases in which the player cannot participate in the multi-play: the room cannot be entered during play or because the room is full, and the room is disbanded before the multi-play starts after entering the room. In this case, the target person's priority points are added when he/she cannot participate in the multiplayer. may

Also, it is assumed that the multiplayer battle game ends normally (including premature termination due to retirement, victory termination, and defeat termination). At this time, if the guest player's priority points at the end of the battle game are greater than the initial value, the guest player's priority points are reset to the initial value.

Also, when a room is created by the host player, "4" is subtracted from the priority points of the host player. Also, at this time, if the random tab 48c is tapped to randomly extract the target person to receive the invitation information, the priority point of the host player is added by "1". Also, when multi-play is started, the host player's priority point is added by "1".

In addition, when the multiplayer battle game ends in victory or defeat, priority points are given to all players whose damage dealt to the enemy character (hereinafter referred to as "damage dealt") is 20% or more of the total damage. is incremented by "3".

According to the above update conditions, for example, if the target person tried to participate in multiplayer but was unable to participate, receiving invitation information (-4), opening invitation information (+1), and not being able to participate Due to (+4), the priority point is increased by "1" with reference to before the reception of the invitation information. This makes it easier for players who tried to participate in multiplay but were unable to participate to receive the invitation information. Also, when the battle game by multiplay ends normally with the priority points exceeding the initial value, the priority points are reset to the initial value. This gives many players an equal opportunity to receive the invitation information.

Also, for guest players who participated in multiplayer, if the damage dealt is 20% or more of the total damage, the reception of invitation information (-4), the opening of invitation information (+1), and the damage dealt by 20% or more (+3) , Prioritized points will be plus or minus zero based on before participating in multiplayer. On the other hand, guest players who dealt damage less than 20% of the total damage received invitation information (-4) and opened invitation information (+1), based on before participating in multiplayer, the priority point is "3". ' is subtracted. In other words, a guest player who is uncooperative in multiplay has a lower priority and is less likely to be set as a target player. In this way, by changing the priority points based on the game results during the communication game, it becomes relatively easier for cooperative players to be set as target players.

Also, the priority points of the host player are deducted by "4" when the room is created, but the priority points are not reduced when the multiplay is started and the damage dealt becomes 20% or more of the total damage. Specifically, when the target is randomly selected, room creation (-4), random selection of the target (+1), multiplayer start (+1), damage dealt is 20% or more (+3), The priority point increases by "1" with reference to before the creation of the room. Also, if the target person is set as a follower or a mutual follower, priority points will be given based on the room creation (-4), multiplayer start (+1), damage dealt 20% or more (+3) is plus or minus zero. As a result, if the host player properly starts the multiplay and plays cooperatively, the host player is considered to be a good player, and an opportunity to participate in the multiplay as a guest player is secured.

On the other hand, when a room is created but multiplay is not started, for example, by creating a room (-4) and randomly extracting a target person (+1), priority is given to the room before creation. Points are reduced by "3". Also, even if the damage dealt by the host player is less than 20% of the total damage, for example, by creating a room (-4), randomly selecting a target person (+1), and starting multiplayer (+1), Based on this, priority points are reduced by "2". As a result, a player who leaves the room or intentionally dissolves the room, or a non-cooperative player, is less likely to participate in the multiplay as a guest player.

According to the present embodiment in which the update conditions are set as described above, it becomes easier for invitation information to reach a player who is considered to be cooperative or excellent, and suitable matching can be realized. Below, the processing of the server 100 when setting the target person from all the players will be described.

(List update process of server 100)
FIG. 8 is a first diagram for explaining list update processing. The storage unit 118 of the server 100 is provided with a player information storage unit 160 (see FIG. 25) that stores player information for each player. In the server 100 , player information update processing for updating player information in the player information storage unit 160 is performed each time communication with the player terminal 1 is performed. Further, the storage unit 118 is provided with an extraction list. In the server 100, based on the player information in the player information storage unit 160, list update processing for updating the extraction list is constantly performed.

For example, in the extraction list provided in the storage unit 118, as shown in FIG. 8, each of a large number of storage areas with addresses has a player (player ID), invitation information (room number), status flag and wait time. is set. Note that the extraction list shown in FIG. 8 and the information set in the extraction list are merely examples. For example, priority points and player rank are not essential as information set in the extraction list, and the information set in the extraction list can be designed as appropriate. Also, in FIG. 8, the numbers assigned to the addresses correspond to the priority order, and the smaller the number of the storage area, the higher the priority order.

Also, an extraction list is provided for each player rank. For example, a plurality of extraction lists are provided, such as an extraction list listing players with player ranks 1 to 10 and an extraction list listing players with player ranks 11 to 20. Here, a description will be given using an extracted list in which players with player ranks of 11 to 20 are listed.

In the extraction list, a player with a higher priority point is listed in a storage area assigned an address with a higher priority. For example, it is assumed that among players with player ranks of 11 to 20, the highest priority point value is "165". It is also assumed that there are five players with the highest priority points. In this case, the player information of the player whose priority points are "165" is set in the storage areas of addresses 1-5. If there are a plurality of players with the same priority points, the addresses (priority order) are determined according to predetermined conditions. In this way, in the list update process, based on the player information in the player information storage unit 160, the process of listing up the players in the extraction list in descending order of priority points is performed.

FIG. 9 is a second diagram for explaining list update processing. For example, assume that any player terminal 1 transmits request information requesting the creation of a room and the sending of invitation information. The request information is identifiably provided for each of the follower tab 48a, the mutual follower tab 48b, and the random tab 48c. Upon receiving the request information, the server 100 performs room setting processing for creating and setting a room. At this time, if the received request information is request information for the random tab 48c, the target person is set as follows in the list update process.

That is, as shown in FIG. 9, the invitation information is set up to a predetermined number (here, 100) of the storage areas in order from the storage area with the highest priority address. However, the storage area in which the invitation information is set is determined based on the status flag.

Specifically, the status flag identifies the reception status of the invitation information. Receivable", 6 reception statuses are identified. "Received 1", "Received 2", and "Received 3" in the reception status indicate that the target user's terminal has received the invitation information. More specifically, "reception 1" indicates that one piece of invitation information has been received, "reception 2" indicates that two pieces of invitation information have been received, and " Received 3” indicates that three pieces of invitation information have been received.

As described above, one player terminal 1 can receive and hold up to three pieces of invitation information. Therefore, the reception statuses of "reception 1" and "reception 2" indicate that new invitation information can be set. On the other hand, the reception status "Received 3" indicates that new invitation information cannot be set.

The reception status "settable" indicates that the invitation information can be set. In the storage area, if the area where the status flag is stored is blank (when the status flag is off), the reception status is "settable". In addition, "receivable" in the reception status permits reception of the set invitation information when there is reception confirmation from the player terminal 1 set as the target person (hereinafter referred to as "target person terminal"). indicates that In addition, "receivable" in the reception status indicates that reception of the set invitation information is restricted when reception confirmation is received from the target user's terminal.

The server 100 sets the invitation information by sequentially retrieving the storage areas with the reception statuses of "received 1", "received 2", and "settable" from the storage areas assigned the addresses with the highest priority. For example, in the state shown in FIG. 8, the status flags are blank in all storage areas with addresses 1-100. In this state, when the request information for the random tab 48c is received from the player terminals 1 of the players whose player ranks are 11 to 20, the invitation information is set in the memory areas of addresses 1 to 100 as shown in FIG. .

Also, a status flag is set in the storage area where the invitation information is set. At this time, a status flag indicating "receivable" is set in the memory area with the highest priority point among the memory areas in which the invitation information is set. In addition, status flags indicating "unreceivable" are set in other storage areas in which invitation information is set. Furthermore, a wait time is set for each storage area for which the "unreceivable" status flag is set.

This wait time is the time until the reception status is switched from "unreceivable" to "receivable". That is, when the status flag of "unreceivable" is set, the status flag is switched to "receivable" after the wait time has elapsed. Each storage area is grouped by priority point, and the same wait time is set for the storage areas classified into the same group. Also, the wait time is set shorter for a group with relatively high priority points than for a group with relatively low priority points.

In the example shown in FIG. 9, the wait time is set to 5 seconds for the group with priority points of "164", and the wait time is set to 10 seconds for the group with priority points of "163". Thus, the wait time becomes shorter as the priority point becomes higher, and becomes longer as the priority point becomes lower.

FIG. 10 is a third diagram for explaining list update processing. Assume that, for example, 5 seconds have elapsed after the invitation information, status flag, and wait time were set as shown in FIG. As described above, the memory areas of addresses 6 to 99 are set with a wait time of 5 seconds. When this wait time of 5 seconds elapses, as shown in FIG. 10, the status flags in the storage areas of addresses 6 to 99 are switched to "receivable". Since 10 seconds was initially set as the wait time in the memory area of address 100, the reception status remains "unreceivable" and the wait time has been updated to 5 seconds.

As described above, when the reception status is "unreceivable", the player terminal 1 cannot receive the invitation information even though the invitation information is set. That is, even if the player terminal 1 confirms the reception while the invitation information is set, the player terminal 1 does not receive the invitation information. In this way, the server 100 enables a player with a higher priority point to receive the invitation information earlier when the target person is set by setting the invitation information. This makes it easier for a player with a higher priority to participate in multiplay.

In the above state, it is assumed that another player terminal 1 newly transmits request information for the random tab 48c. In this case, as shown in FIG. 10, the invitation information is set in the storage areas of addresses 101-200. It should be noted that the storage areas of addresses 101 to 200 all have 163 priority points. Therefore, here, the status flag of "receivable" is set in all of the storage areas of addresses 101-200.

FIG. 11 is a fourth diagram for explaining list update processing. For example, in the state shown in FIG. 10, it is assumed that reception of invitation information has been confirmed from the target person terminal set as the target person in the storage areas of address 1 and address 3 . In this case, the target person terminals of both players receive the invitation information set in the storage area. When the invitation information is received, the server 100 switches the status flag from "reception possible" to "reception 1" as shown in the upper diagram of FIG.

Also, as described above, when the target receives the invitation information, the target's priority points are subtracted by "4". The server 100 updates the priority points to "161" in the storage areas of addresses 1 and 3. FIG. After that, the server 100 performs sorting processing based on the priority points. As a result of this sorting process, the information stored in the storage areas of addresses 1 and 3 is moved to addresses (storage areas) of lower priority, as shown in the lower diagram of FIG.

The server 100 counts the number of receptions of invitation information for each player terminal 1 . Then, as described above, the player terminals 1 with status flags of "reception 1" and "reception 2" can further receive the invitation information. For example, when new invitation information is set to the player terminal 1 whose status flag is "receiving 1", the status flag is updated to "receivable" or "receivable". After that, when the newly set invitation information is received, the number of receptions of the invitation information is updated to "2" and the status flag is updated to "received 2".

Further, in the player terminal 1, when the delete tab of the operation unit 54b is tapped after receiving the invitation information, the delete information is transmitted to the server 100. FIG. Upon receiving the deletion information, the server 100 deletes the invitation information set in the player terminal 1 that transmitted the deletion information. The invitation information is also deleted when the invitation information becomes invalid, such as when the multiplayer ends or when the room disappears.

When the invitation information is deleted, the number of receptions of the invitation information is decremented by "1". For example, when deletion information is received from the player terminal 1 whose status flag is "reception 2", the status flag is updated to "reception 1". Further, when the deletion information is received from the player terminal 1 whose status flag is "receipt 1", the status flag is updated to blank.

Although details will be described later, when the request information for the follower tab 48a is transmitted, the invitation information is set in the storage area of the player set as the follower. Also, when the request information for the mutual follower tab 48b is transmitted, the invitation information is set in the memory area of the player set as the mutual follower.

According to the above-described list update process, a player who is highly motivated to participate in multiplay can easily receive invitation information. A player who is highly motivated to participate receives the invitation information, thereby shortening the time until the start of the multiplay.

Furthermore, in the present embodiment, the invitation information is received according to the game play status of the player terminal 1 . Specifically, when the player is playing a battle game (single play) or when it is considered that the player is watching the screen to play the game, the reception of the invitation information is notified. That is, in the player terminal 1, the reception of the invitation information is notified under the condition that the willingness to participate in the multi-play is high and the responsiveness to the invitation is considered to be high. As a result, the time required for the players participating in the multiplay to gather can be shortened, and the time required for the start of the multiplay can be shortened.

(Play state of player terminal 1)
FIG. 12A is a diagram for explaining the play state of the player terminal 1. FIG. FIG. 12B is a diagram illustrating the timing of confirmation of receipt of invitation information. The player terminal 1 updates the play state based on the game play state and the reception state of the invitation information. Note that the player terminal 1 is provided with three state storage units, a first state storage unit 82, a second state storage unit 84, and a third state storage unit 86, which will be described later.

In the player terminal 1, when the invitation information is received, one of the three state storage units is assigned to the received invitation information. In the player terminal 1, the invitation information is stored in the assigned state storage unit. Further, each state storage unit stores a play state. In each state storage unit, the play state is updated separately based on whether the invitation information is assigned or not.

As described above, the thumbnail display area 52 displays up to three thumbnail images 52a. In other words, the thumbnail display area 52 has three display positions where the thumbnail images 52a are displayed. Each of the three state storage units is associated with one display position in the thumbnail display area 52 where the thumbnail image 52a is displayed.

For example, the first state storage section 82 is associated with the first display position at the top of the thumbnail display area 52 . In addition, the second display position in the center of the thumbnail display area 52 is associated with the second state storage section 84 . Further, the third display position, which is the lowest position in the thumbnail display area 52, is associated with the third state storage section 86. As shown in FIG. If, when the invitation information is received, the first state storage unit 82 is assigned to this invitation information, the thumbnail image 52a will be displayed at the first display position.

As shown in FIG. 12A, in the player terminal 1, there are four play states managed by each state storage unit: ready-to-receive state, unopened state, opened state, and participation state. That is, in the state storage unit, the play state is set to one of the four play states. The player terminal 1 executes processing related to reception of the invitation information based on the set play state.

Whether or not new invitation information can be assigned is associated with each play state in the state storage unit. The player terminal 1 can receive the invitation information from the server 100 when there is a state storage unit in which the play state is set to the ready-to-receive state. In other words, among the play states, the receivable state can be said to be a permitted state in which allocation of new invitation information is permitted.

On the other hand, no invitation information is assigned to the state storage units in which the play state is set to the unopened state, the opened state, or the participating state. In other words, among the play states, the unopened state, the opened state, and the participating state can be said to be states in which invitation information cannot be assigned.

Therefore, if the play state is any of the unopened state, opened state, and participating state in all three state storage units, the player terminal 1 cannot receive the invitation information. On the other hand, if the play state in at least one of the three state storage units is the receiveable state, the player terminal 1 can receive the invitation information.

For example, assume that a player is set as a target person in the server 100 and invitation information for the player is set in the server 100 . At this time, the player terminal 1 receives the invitation information from the server 100 if the player terminal 1 has a state storage section in which the play state is set to the receiveable state.

On the other hand, even if the invitation information is set in the server 100, the player terminal 1 receives the invitation from the server 100 if the play state is set to the unopened state, the opened state, or the participating state in all the state storage units. do not receive information. In other words, the player terminal 1 does not confirm receipt of the invitation information when the play state is set to any one of the unopened state, the opened state, and the participation state in all the state storage units.

Although detailed explanation is omitted, even if the play state is the permitted state, the player terminal 1 may not receive the invitation information depending on the set invitation information. For example, assume that the player taps the delete tab of the operation unit 54b to delete the invitation information. In other words, assume that the player refuses to participate in the battle game to which he or she has been invited. In this case, the invitation information for inviting participation in the battle game of the same type as the battle game for which participation has been refused is not received for a predetermined period of time after the deletion information is transmitted.

In this way, by not receiving invitation information that the player is unlikely to participate in, the possibility of giving the player annoyance is reduced. As described above, when the play state is the permitted state, in principle, invitation information can be received, but depending on the contents of the invitation information, reception of part of the invitation information may be restricted.

As shown in FIG. 12A, setting conditions are provided for each of the above play states. The player terminal 1 determines whether or not the setting condition is satisfied, and sets the play state for each state storage section based on the determination result.

In the ready-to-receive state, the setting conditions are that the invitation information is not stored and that the user has not entered the multiplayer room.

The setting conditions for the unopened state are that the invitation information is stored, that the invitation information image 54 is not displayed, and that the invitation information is unopened. Note that the valid time is set in advance in the invitation information. After the invitation information is received, the invitation information is deleted from the player terminal 1 when the effective time elapses. When the valid time elapses while the play state remains unopened, the invitation information is deleted and the play state is updated to the ready-to-receive state.

In the unsealed state, it is provided as a setting condition that the invitation information is stored and that the invitation information image 54 has been displayed. Note that the unsealed state is set when the invitation information image 54 is being displayed and when the invitation information image 54 is not displayed after the hold operation is input. The pending operation is an operation to hide the invitation information image 54 after the invitation information image 54 is displayed without operating the join tab and the delete tab of the operation unit 54b.

In addition, even after the play status has been updated from unopened to opened, if the valid time elapses without the participation tab and delete tab being operated, the invitation information will be deleted in the same way as above. be done. In this case, the play state is updated from the opened state to the ready-to-receive state in the state storage unit in which the deleted invitation information was stored.

The setting condition for the participation state is that the player is in a multiplay room.

Here, the above play state is updated for each state storage unit, but the participation state is commonly set in the three state storage units. For example, when two pieces of invitation information are received but the invitation information image 54 is not displayed, the play state is the unopened state in the two state storage units, and the play state is the ready-to-receive state in one state storage unit. becomes.

In this state, when the notification image 34 or the thumbnail image 52a of the notification mode is tapped, two invitation information images 54 are displayed, and the play state is updated to the opened state in the two state storage units. Assume that a participation operation is input to the operation portion 54b of one of the invitation information images 54 and the player enters the multiplay room. In this case, the play state is updated to the participation state in all three state storage units. After that, when the multi-play ends, the play state is updated to the ready-to-receive state in all the three state storage units.

In this way, among the play states, the participation state is always set simultaneously in all three state storage units. On the other hand, if the play state of the three state storage units is not the participation state, the play state of the three state storage units is set to any of the ready-to-receive state, the unopened state, and the opened state. Become.

When the play state of at least one state storage unit is set to the permitted state, that is, when there is even one state storage unit whose play state is set to the receiveable state, the player terminal 1 asks the server 100 to Confirm receipt of invitation information. At this time, if the invitation information for itself is set, the player terminal 1 receives the set invitation information.

Then, when the invitation information is received, if there is a state storage unit in which the play state is set to the receivable state, the state storage unit is assigned to the received invitation information. As a result, the play state of the state storage unit to which the invitation information is assigned is updated from the ready-to-receive state to the unopened state.

Among the three state storage units, the first state storage unit 82 has the highest priority for allocation of invitation information, and the third state storage unit 86 has the lowest priority for allocation of invitation information. Therefore, for example, when the invitation information is received when all the play states in the three state storage units are set to the ready-to-receive state, the invitation information is assigned to the first state storage unit 82 .

Here, reception confirmation of the invitation information in the player terminal 1 is performed as shown in FIG. 12B. That is, when the battle screen is displayed on the display 26 of the player terminal 1, reception of the invitation information is confirmed at intervals of 15 seconds. However, when transitioning from the normal screen (screen other than the battle screen) to the battle screen on the display 26, the timing for first confirming receipt of the invitation information after the screen transition is randomly selected between 1 and 15 seconds. It is determined.

Also, when a normal screen (a screen other than the battle screen) is displayed on the display 26 of the player terminal 1, reception of the invitation information is confirmed at intervals of 10 seconds. However, on the display 26, if the battle screen transitions to the normal screen, if the normal screen transitions to another normal screen, or if the page transitions within the normal screen, the invitation information is first received after the screen transition. The timing of confirmation is randomly determined by lottery between 1 and 10 seconds.

As described above, by randomly determining the timing of first confirming reception of invitation information after the screen transition, it is possible to prevent the player from changing the screen just to receive the invitation information. This suppresses unnecessary communication with the server 100 and reduces the load on the server 100 .

Also, while the battle screen is being displayed, the interval for confirming receipt of the invitation information is set to be longer than during the normal screen being displayed. As a result, execution of an unnecessary battle game for the purpose of receiving invitation information is suppressed, and an increase in load on the server 100 can be suppressed.

Next, communication processing between the player terminal 1 and the server 100 for executing the multiplay will be described. Here, basic communication processing for progressing the game and an example of main communication processing relating to multi-play will be described, and description of other processing will be omitted.

(Communication processing between player terminal 1 and server 100)
FIG. 13 is a sequence diagram illustrating basic processing of the player terminal 1 and the server 100. FIG. In the following description, when the host terminal, guest terminal, and target terminal are not distinguished, the processing in the player terminal 1 is 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 identifies the player terminal 1 and performs login processing (S1). Here, the server 100 enables the player terminal 1 to download the player information corresponding to the identified player terminal 1 from the storage unit 118 .

In addition, if there is a state storage unit in which the play state is set to a state in which reception is possible, the player terminal 1 confirms reception of the invitation information at predetermined time intervals (P2). Here, the player terminal 1 transmits reception confirmation information to the server 100 . When receiving the reception confirmation information, the server 100 searches the extraction list for presence of invitation information of the player terminal 1 (S2). At this time, if the invitation information is set and the reception status is set to "receivable", the player terminal 1 receives the invitation information. Upon receiving the invitation information, the player terminal 1 displays the notification image 34 in a notification mode and also displays the thumbnail image 52a to notify that the invitation information has been received (P3).

Also, it is assumed that the single play tab 40a is tapped from the play content selection page (see FIG. 4A) on the player terminal 1 to perform a single play start operation (P4). In this case, start information is transmitted from the player terminal 1 to the server 100 . The start information includes party information selected by the player, battle game type information, and the like. In the server 100, by inputting the start information, battle game start processing necessary for starting the battle game is performed (S3).

Here, for example, an area of the memory 112 for progressing the battle game is secured, information input from the player terminal 1 is stored, and a predetermined program is read from the storage unit 118 to the memory 112 . The server 100 also sets the player terminal 1 so that it can receive data necessary for executing the battle game.

Then, the battle game start processing necessary for starting the battle game is also performed on the player terminal 1 (P5). Here, for example, an area of the memory 12 for progressing the battle game is secured, game play information is stored, and programs and image data downloaded from the server 100 are stored in the memory 12 . Note that the programs and the like required for the battle game may be read from the storage unit 18 to the memory 12 .

When preparations for the battle game are completed as described above, both the player terminal 1 and the server 100 concurrently perform battle game control processing for controlling the single-play battle game (P6, S4). In this battle game control process, an update process for updating various information is repeatedly executed on a frame-by-frame basis. The number of frames is not particularly limited. For example, the number of frames per second is 30-60. Therefore, during the battle game, information is updated in the player terminal 1 and the server 100 at intervals of about 16 ms (milliseconds) to 33 ms.

Also, in the update process, update information is transmitted and received between the player terminal 1 and the server 100 . Here, update processing and transmission/reception of update information are performed in frame units, but update processing and transmission/reception of update information may be performed in a shorter or longer cycle than in frame units. Further, even during the single-player battle game, confirmation of receipt of invitation information on player terminal 1 (P7), retrieval of invitation information on server 100 (S5), and notification of receipt of invitation information on player terminal 1 (P8) are performed periodically. can be executed to

Then, when the conditions for ending the battle game are met, the player terminal 1 and the server 100 each perform end processing for ending the battle game (P9, S6). In the ending process (P9) of the player terminal 1, for example, a result screen is displayed on the display 26. FIG. In addition, in the end processing (S6) of the server 100, for example, various player information such as items obtained in the battle game, player experience value, character experience value, etc. are updated.

FIG. 14 is a sequence diagram illustrating processing of the player terminal 1 and the server 100 when multiplay is executed. In the following description, HPn (n is an arbitrary integer) denotes processing in the host terminal, and GPn (n is an arbitrary integer) denotes processing in the subject terminal and the guest terminal.

Suppose that the room creation tab 46 is tapped on the player terminal 1 (host terminal) and a request operation is input (HP 10). When the request operation is input, the player terminal 1 (host terminal) transmits to the server 100 request information requesting creation of a room and sending of invitation information. The request information includes information related to the party selected by the player, information indicating the type of battle game, information indicating the tapped operating unit, and the like.

When the server 100 receives the request information, the player information storage unit 160 performs a point update process (shown as UPDATE in the figure) for updating the priority points. Here, "4" is subtracted from the priority points of the host player who sent the request information. Also, although the details will be described later, when the point update process is performed in the player information storage unit 160 , the priority points in the extraction list are also updated in the same way as the player information storage unit 160 . Also, the extraction list is sorted based on the updated priority points.

Further, when receiving the request information, the server 100 performs room setting processing for creating and setting a room (S10). Here, a processing area for executing multiplay, that is, a room is secured, and various types of information included in the request information are stored in this room. Also, the room number of the created room is set. The host terminal receives the room setting information set in the room setting process and displays the room details page on the display 26 (HP11).

The server 100 also sets a target person (S11). Here, the invitation information, the status flag, and the counter value of the wait counter are set in the extraction list, and the target person is set. After that, when the target person's terminal confirms the reception of the invitation information (GP10), the reception confirmation information is transmitted to the server 100 . When receiving the reception confirmation information, the server 100 searches whether the invitation information is set for the target person (S12). Here, since the invitation information is set, the server 100 updates the target person's reception status (status flag) to "received". In addition, the server 100 performs point update processing, and subtracts "4" from the priority points of the target person who has received the invitation information.

When the invitation information is received, the target person's terminal displays the notification image 34 in the notification mode, displays the thumbnail image 52a, and notifies that the invitation information has been received (GP11). In addition, the target person's terminal determines a state storage unit to be assigned to the received invitation information, and stores the invitation information. Also, at this time, the play state in the state storage unit storing the invitation information is updated to the unopened state (GP12). After that, when the target person taps the notification image 34 or the thumbnail image 52a, the target person terminal displays the invitation information image 54 (GP13). Further, when the invitation information image 54 is displayed, opening information is transmitted to the server 100 . When the server 100 receives the opening information, the server 100 performs point update processing. Here, "1" is added to the priority points of the target person. Also, in the target user's terminal, the play state in the state storage unit to which the invitation information is assigned is updated to the opened state (GP14).

After that, when the participation tab in the operation part 54b of the invitation information image 54 is tapped on the target person's terminal, the participation information is transmitted from the target person's terminal to the server 100 (GP15). The participation information includes information related to the party set by the target person. When the server 100 receives the participation information, it determines whether or not it is possible to enter the room, and if it is possible to enter the room, it updates the room information (S13). Here, the server 100 is set so that updated room information (room update information) is received by the host terminal and the subject terminal.

Although only one target person terminal (guest terminal) is shown in FIG. 14, the same processing is performed by a plurality of target person terminals (guest terminals) for one room. Therefore, when any player enters the room, the player terminals 1 of all players entering the room receive the room update information.

When the host terminal receives the room update information from the server 100, it updates and displays the room details page (HP12). The subject terminal also receives the room update information. Here, the player terminal 1 (target person terminal) after receiving the room update information is called a guest terminal. Upon receiving the room update information, the guest terminal updates the play state of all state storage units to the participation state (GP16), and displays the room details page on the display 26 (GP17).

After that, when the start tab 50 of the room details page is tapped on the host terminal and an operation to start multiplay is input (HP 13 ), start information is transmitted to the server 100 . In the server 100, point update processing is performed by inputting the start information. Here, "1" is added to the priority points of the host player.

Then, the host terminal, the server 100, and the guest terminals each perform the above-described battle game start processing (not shown), and thereafter, the multiplay control processing for controlling the multiplay is performed in parallel (HP14, S14, GP18). In this multiplay control process, an update process for updating various information is repeatedly executed in units of frames. In this update process, update information is transmitted and received among the host terminal, guest terminal, and server 100 . Then, when the conditions for ending the battle game are satisfied, end processing for ending the battle game is performed in each of the host terminal, the guest terminal, and the server 100 (HP15, S15, GP19).

At the end of the multiplay, the server 100 calculates the damage dealt out of all the damage for each player who participated in the multiplay (S16). Then, point update processing is performed based on the calculated damage. Here, "3" priority points are added to the player whose damage dealt is 20% or more of the total damage. On the other hand, in the guest terminal, when the multiplay ends, the invitation information is deleted from all the state storage units, and the play state is updated to the ready-to-receive state (GP20).

FIG. 15 is a sequence diagram illustrating the processing of player terminal 1 and server 100 when it is not possible to participate in multiplay. In addition, in FIG. 15, the processing until participation information is input from the target person's terminal is the same as that in FIG. 14, so the description is omitted. As described above, when a participation operation is input on the target person's terminal, participation information is transmitted to the server 100 (GP15). When the server 100 receives the participation information, it determines whether or not it is possible to enter the room. At this time, if it is impossible to enter the room, the server 100 sets participation impossibility information indicating that it is impossible to enter the room. At this time, the server 100 performs point update processing and adds "4" to the priority points of the target person.

When receiving the participation-impossible information, the target person's terminal displays an entry-impossible screen on the display 26 and hides the invitation information image 54 for which the participation operation has been performed (GP22). In addition, the target user terminal deletes the invitation information for which the participation operation has been performed, and updates the play status of the status storage unit from which the invitation information has been deleted to the receivable status (GP23).

FIG. 16 is a sequence diagram illustrating the processing of player terminal 1 and server 100 when participation in multiplay is refused. In addition, in FIG. 16, the processing up to the input of deletion information from the subject terminal is the same as in FIG. 14, so the description is omitted. When the deletion tab of the operation unit 54b in the invitation information image 54 is tapped on the target terminal, deletion information is transmitted from the target terminal to the server 100 (GP24). In addition, in the subject terminal, the invitation information is deleted in the status storage unit to which the deleted invitation information is assigned, and the play status is updated to the ready-to-receive status (GP25).

When receiving the deletion information, the server 100 updates the reception status (status flag) of the target user terminal that transmitted the deletion information (S17). Here, the number of receptions of the invitation information is decremented, and the status flag is updated from "reception 1" to blank, or from "reception 3" to "reception 2", for example.

Next, the functional configuration of the player terminal 1 and specific processing in the player terminal 1 will be described. In addition, below, the structure and process which concern on invitation information are demonstrated, and description is abbreviate|omitted about the structure and process unrelated to invitation information.

(Functional Configuration of Player Terminal 1)
FIG. 17 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. The CPU 10 stores a terminal-side game control program (module) in the program storage area 12a at the start of the multiplay or in advance before the start of the multiplay.

The terminal-side game control program includes a game execution program 60, a battle game execution program 62, a request information transmission program 64, a play state update program 66, an invitation information reception program 68, a notification program 70, an invitation information image display program 72, a process A program 74 and a timer program 76 are included. Note that the programs listed in FIG. 17 are only examples, and many other programs are provided in the terminal-side game control program.

In the data storage area 12b, a game information storage section 80, a first state storage section 82, a second state storage section 84, and a third state storage section 86 are provided 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 unit 1A includes a game execution unit 60a, a battle game execution unit 62a, a request information transmission unit 64a, a play state update unit 66a, an invitation information reception unit 68a, a notification unit 70a, an invitation information image display unit 72a, and a processing unit. 74a, including a timer 76a.

Specifically, the CPU 10 operates the game execution program 60 to cause the computer to function as the game execution section 60a. Similarly, the CPU 10 operates a battle game execution program 62, a request information transmission program 64, a play status update program 66, an invitation information reception program 68, a notification program 70, an invitation information image display program 72, a processing program 74, and a timer program 76. function as a battle game execution unit 62a, a request information transmission unit 64a, a play state update unit 66a, an invitation information reception unit 68a, a notification unit 70a, an invitation information image display unit 72a, a processing unit 74a, and a clock unit 76a, respectively.

The game execution unit 60a controls the progress of games other than the battle game, such as formation of a party, strengthening of allied characters, etc., based on the player's operation. The game execution unit 60 a updates the game screen every time an operation is input to the player terminal 1 and transmits information corresponding to the operation to the server 100 . Further, the game execution unit 60a updates the information in the game information storage unit 80 when the information related to the game is updated.

The battle game executing section 62a is in charge of all controls for executing the battle game. For example, the battle game execution unit 62a transmits information to the server 100 and receives various information from the server 100 based on operations input to the player terminal 1. FIG. Also, the battle game execution unit 62 a updates the battle screen based on the operation input to the player terminal 1 and the information received from the server 100 . That is, the battle game executing section 62a executes single play or multi-play with another player terminal 1. FIG. Also, the battle game execution unit 62a updates the information in the game information storage unit 80 when the battle game ends normally.

That is, the game execution unit 60a and the battle game execution unit 62a function as display control units that display the game screen during play.

When any one of the follower tab 48a, mutual follower tab 48b, and random tab 48c is tapped, the request information transmission unit 64a transmits a request signal corresponding to the operation unit to the server 100. FIG.

The play state update unit 66a updates the play states of the first state storage unit 82, the second state storage unit 84, and the third state storage unit 86 based on the invitation information reception status, the game play status, and the like. .

The invitation information reception unit 68a confirms reception of the invitation information at a timing set for each screen displayed on the display 26 when there is a state storage unit in which the play state is set to the permitted state. Specifically, the invitation information receiving unit 68 a transmits reception confirmation information to the server 100 and receives invitation information set in the server 100 . Further, the invitation information receiving unit 68a stores the invitation information in one of the first state storage unit 82, the second state storage unit 84, and the third state storage unit 86. FIG.

In other words, the invitation information receiving unit 68a functions as a receiving unit capable of receiving a plurality of pieces of invitation information for inviting participation in one of a plurality of types of invitation games from an external device.

The notification unit 70a displays the notification image 34 in the notification mode and the thumbnail image 52a when the invitation information is received. In addition, the notification unit 70a notifies based on whether or not the invitation information is stored in the first state storage unit 82, the second state storage unit 84, and the third state storage unit 86, that is, whether or not the invitation information is received. The image 34 is switched between the notification mode and the non-report mode.

That is, the notification unit 70a displays the thumbnail image 52a as the notification image corresponding to the received invitation information while maintaining the display of the game screen being played. Further, the notification unit 70a functions as a notification unit that displays a thumbnail image 52a for each piece of invitation information when receiving a plurality of pieces of invitation information.

The invitation information image display unit 72a displays the invitation information image 54 when the notification image 34 in the notification mode or the thumbnail image 52a is tapped.

That is, when the player's operation to select the thumbnail image 52a as the notification image is input, the invitation information image display unit 72a displays the game information on the invitation game corresponding to the thumbnail image 52a and the operation to participate in the invitation game. It functions as a predetermined image display section that displays a predetermined image including at least an operation section that receives an input.

The processing unit 74a functions as a processing unit that executes processing for participating in the invited game when a participation operation is input to the participation tab of the operation unit 54b in the invitation information image 54. FIG. Further, the processing unit 74 a deletes the invitation information and transmits the deletion information to the server 100 when a delete operation is input to the delete tab of the operation unit 54 b in the invitation information image 54 .

The clocking unit 76a clocks the effective time of the invitation information, the elapsed time after the deletion operation is input, the time after the screen transition, and the like.

(Specific processing of player terminal 1)
FIG. 18 is a flowchart illustrating an example of terminal-side game processing in the player terminal 1. FIG. In the terminal-side game processing, the game execution unit 60a performs game progress processing and controls the progress of games other than the battle game (P100). In addition, the battle game executing section 62a performs control for executing a single-play or multi-play battle game (P101). In the terminal-side game processing, the terminal-side game control unit 1A also executes room creation-related processing (P110), invitation information reception processing (P120), invitation information post-reception processing (P130), and multi-play end processing (P140). .

FIG. 19 is a flowchart illustrating an example of room creation related processing in the player terminal 1. FIG. When the quest screen is displayed on the display 26 (YES in P110-1), when the room creation tab 46 is tapped and a request operation is input (YES in P110-2), the request information transmitting unit 64a requests The information is sent to the server 100 (P110-3). At this time, the terminal-side game control section 1A displays a predetermined standby screen on the display 26 (P110-4).

Further, when the terminal-side game control section 1A receives the room setting information (YES in P110-5), it displays the room details page on the display 26 (P110-6). Further, when the terminal-side game control section 1A receives the room update information (YES in P110-7), it updates the display of the room details page based on the received room update information (P110-8).

Further, when the start tab 50 is tapped and a start operation is input (YES in P110-9), the terminal-side game control section 1A transmits start information to the server 100 (P110-10), and multiplay is started. (P110-11). When the multiplay can be started, the battle game is controlled by the multiplay in the battle game execution process (P101).

FIG. 20 is a flowchart illustrating an example of invitation information reception processing in the player terminal 1. FIG. When the screen of the display 26 changes (YES in P120-1), the clock section 76a confirms the screen being displayed on the display 26 (P120-2), and determines the initial counter value by lottery (P120-3). It should be noted that the initial counter value indicates the interval for confirming receipt of the invitation information. Here, if the normal screen is displayed, a value corresponding to 1 to 10 seconds is determined as the initial counter value, and if the battle screen is displayed, it corresponds to 1 to 15 seconds. A value is determined as the initial counter value. The timer unit 76a stores the determined initial counter value in a predetermined storage unit of the data storage area 12b, and also sets it in the reception standby counter (P120-4).

Also, if the play state is the unopened state or the opened state in any of the first state storage unit 82, the second state storage unit 84, and the third state storage unit 86 (YES in P120-5), the clock unit 76a decrements the counter value of the effective time counter that counts the effective time of the invitation information (P120-6).

If there are a plurality of state storage units whose play state is the unopened state or the opened state, the processing from P120-6 to P120-8 is executed for the plurality of state storage units. Therefore, a valid time counter is provided for each state storage unit. When the counter value of the effective time counter is updated to 0 (YES in P120-7), the play state updating unit 66a deletes the invitation information in the state storage unit corresponding to this effective time counter and receives the play state. Update to the possible state (P120-8).

Also, although illustration is omitted, if the play state is not the ready-to-receive state in all the state storage units until the play state is updated to the ready-to-receive state at P120-8, the display Based on the screen being displayed in 26, the initial counter value is determined and set in the reception standby counter.

In addition, if the play state in any one of the first state storage unit 82, the second state storage unit 84, and the third state storage unit 86 is the state in which reception is possible (YES in P120-9), the timer unit 76a The counter value of the standby counter is decremented (P120-10). Then, when the counter value of the reception standby counter reaches 0 (YES in P120-11), the timer 76a again sets the initial counter value stored in the initial value storage unit to the reception standby counter. In addition, the invitation information receiving unit 68a executes an invitation information confirmation process (P121).

FIG. 21 is a flowchart illustrating an example of invitation information confirmation processing in the player terminal 1. FIG. The invitation information receiving section 68a transmits reception confirmation information to the server 100 (P121-1). If receivable (unreceived) invitation information is set in the server 100 (YES in P121-2), the invitation information receiving unit 68a receives the invitation information set in the server 100, and receives the received invitation information. is stored in one of the first state storage unit 82, the second state storage unit 84, and the third state storage unit 86 (P121-3).

If a predetermined time has not passed since the deletion operation was input, the invitation information receiving unit 68a does not receive the invitation information related to the battle game of the same type as the deleted invitation information. Therefore, in this case, the invitation information receiving unit 68a performs processing assuming that there is no receivable invitation information.

However, if the predetermined time has not passed since all the invitation information was received and the deletion operation was input, the invitation information reception unit 68a detects that the received invitation information is of the same type as the deleted invitation information. It may be determined whether At this time, if the received invitation information is of the same type as the deleted invitation information, the invitation information may be discarded without being stored.

In addition, the play state update unit 66a updates the play state in the state storage unit storing the invitation information to the unopened state (P121-4). In addition, the timer 76a sets a predetermined value in the effective time counter (P121-5). In addition, the notification unit 70a displays the notification image 34 in the notification mode, and executes notification processing for displaying the thumbnail image 52a (P121-5). Here, the timer 76a sets the display time of the thumbnail image 52a to the timer. Although detailed description is omitted, the timer set here is decremented every frame, and when the timer reaches 0, the thumbnail image 52a is hidden.

FIG. 22 is a first flowchart illustrating an example of post-reception processing of invitation information in the player terminal 1 . FIG. 23 is a second flowchart illustrating an example of post-reception processing of invitation information in the player terminal 1 . When the thumbnail image 52a or the notification image 34 is tapped (YES at P130-2) while the invitation information is stored (YES at P130-1), the invitation information image display unit 72a displays the invitation information on the display 26. The image 54 is displayed (P130-3). At this time, if there is a state storage unit in which the play state is set to unopened (YES in P130-4), the processing unit 74a transmits the unopened information to the server 100 (P130-5). In addition, the play state update unit 66a updates the play state to the unsealed state in all the state storage units in which the invitation information is stored (P130-6).

Further, when the participation tab is tapped and a participation operation is input while the invitation information is stored and the invitation information image 54 is displayed (YES on P130-1, NO on P130-2, P130- 7 YES, P130-8 YES), the processing unit 74a transmits the participation information to the server 100 (P130-9).

Thereafter, the processing unit 74a waits until it receives room update information or participation impossibility information (P130-10). Then, when the room update information is received from the server 100 (YES in P130-11), the play state update section 66a updates the play state to the participating state (P130-12). In addition, the processing unit 74a displays the room details page on the display 26 (P130-13). Further, here, the notification unit 70a switches the notification image 34 to the non-display mode, and the invitation information image display unit 72a makes the invitation information image 54 non-display.

On the other hand, when the participation impossible information is received from the server 100 (NO in P130-11), the processing unit 74a displays the entry impossible screen on the display 26 (P130-14), is deleted (P130-15). The invitation information image display unit 72a also hides the invitation information image 54 corresponding to the deleted invitation information (P130-16). Further, the play state update unit 66a updates the play state in the state storage unit from which the invitation information has been deleted to the ready-to-receive state (P130-17).

Further, when the delete tab is tapped and a delete operation is input while the invitation information is stored and the invitation information image 54 is displayed (YES on P130-1, NO on P130-2, P130- 7 YES, P130-8 NO, P130-18 YES in FIG. Update to a receivable state (P130-20). The processing unit 74a also transmits deletion information to the server 100 (P130-21).

In addition, the invitation information image display unit 72a ends the display of the invitation information image 54 corresponding to the deleted invitation information (P130-22). In addition, the processing unit 74a sets a predetermined time in a deletion counter that counts the time that has elapsed since the deletion operation was input (P130-23). Note that the counter value of the deletion counter set here is decremented every frame until it reaches zero. If the counter value of the deletion counter is not 0, it is determined in P121-2 whether the receivable invitation information is of the same type as the deleted invitation information.

Further, when the hold operation is input while the invitation information is stored and the invitation information image 54 is displayed (YES on P130-1, NO on P130-2, YES on P130-7, P130- 8 NO, P130-18 NO, P130-28 YES), the invitation information image display unit 72a terminates the display of the invitation information image 54 (P130-29).

FIG. 24 is a flowchart illustrating an example of multiplay end processing in the player terminal 1. FIG. When the multi-play ends (YES in P140-1), the battle game executing section 62a displays the result screen on the display 26 (P140-2). At this time, if the player participates in the multi-play as a guest player (YES in P140-3), the invitation information receiving section 68a erases the invitation information from all status storage sections (P140-4). In addition, the play state update unit 66a updates the play state to the receivable state in all state storage units (P140-5).

Next, the functional configuration of server 100 and specific processing in server 100 will be described. In addition, below, the configuration and processing related to the setting of the target person who can receive the invitation information will be described, and the description of the other configuration and processing will be omitted.

(Functional Configuration of Server 100)
FIG. 25 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. The CPU 110 stores a server-side game control program (module) in the program storage area 112a at the start of the multiplay or in advance before the start of the multiplay.

The server-side game control program includes a player information update program 140, a list update program 142, a terminal setting program 144, and a game execution program 146. FIG. The programs listed in FIG. 25 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 player information storage unit 160, an extraction list storage unit 162, a game information storage unit 164, and a room information storage unit 166 as storage units 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 (computer) to function as the server-side game control section 100A by operating each program stored in the program storage area 112a. The server-side game control unit 100A includes a player information update unit 140a, a list update unit 142a, a terminal setting unit 144a, and a game execution unit 146a.

Specifically, the CPU 110 operates the player information update program 140 to cause the computer to function as a player information update unit 140a. Similarly, the CPU 110 operates a list update program 142, a terminal setting program 144, and a game execution program 146 to function as a list update section 142a, a terminal setting section 144a, and a game execution section 146a, respectively.

The player information update unit 140a updates the player information for each player accumulated in the player information storage unit 160 each time communication with the player terminal 1 is performed. The player information update unit 140a also performs point update processing for updating the priority points in the player information storage unit 160. FIG.

The list update unit 142 a updates the extraction list stored in the extraction list storage unit 162 based on the player information (priority points) stored in the player information storage unit 160 . For example, the list updating unit 142a executes sorting processing for replacing storage areas in which player information is stored. In addition, the list update unit 142a updates the invitation information, the status flag, and the wait counter of the extraction list.

Based on the input of the request information, the terminal setting unit 144a sets the invitation information, the status flag, and the counter value of the wait counter in the extraction list. That is, the terminal setting unit 144a sets the target person in the extraction list.

The game execution unit 146a controls the progress of all games including the battle game based on information input from the player terminal 1. FIG. In addition, the game execution unit 146a stores various information updated during the game in the game information storage unit 164. FIG. Here, the game execution unit 146a stores the damage given to the enemy character in the game information storage unit 164 for each player in the multiplay. However, the information stored in the game information storage unit 164 is not limited to this, and can be appropriately set based on the content of the game.

(Specific processing of server 100)
FIG. 26 is a flowchart illustrating an example of server-side game processing in the server 100. FIG. In the server-side game processing, the game execution unit 146a performs battle game execution processing for executing a battle game (S100). Also, the player information update unit 140 a updates the player information in the player information storage unit 160 based on the information input from the player terminal 1 . In addition, the server-side game control unit 100A executes request information reception processing (S110), information update processing (S120), multiplay end processing (P130), and rearrangement processing (S140) in the server-side game processing.

FIG. 27 is a flowchart illustrating an example of request information reception processing in the server 100. FIG. When a follower is selected as the person to be invited to the room, that is, when request information for the follower tab 48a is received (YES in S110-1, YES in S110-2), the terminal setting unit 144a selects the following in the extraction list: The invitation information, the status flag, and the counter value of the wait counter (hereinafter referred to as "invitation information, etc.") are set in the follower storage area (S110-3).

When a mutual follower is selected as the person to be invited to the room, that is, when the request information for the mutual follower tab 48b is received (YES in S110-1, NO in S110-2, YES in S110-4), terminal settings are performed. The unit 144a sets the invitation information and the like in the mutual follower storage area in the extraction list (S110-5).

Note that when setting invitation information to a follower or a mutual follower, it is not essential to set the counter value of the wait counter. That is, when a follower or a mutual follower is set as a target person, all the target persons may receive the invitation information at the same time. Moreover, the counter value of the weight counter may be set based on the priority points, as in the case where the target person is set at random.

When it is selected to randomly extract the target person to be invited to the room, that is, when the request information for the random tab 48c is received (YES in S110-1, NO in S110-2, NO in S110-4) , the terminal setting unit 144a sets the invitation information and the like in the storage areas of the top 100 persons whose reception statuses are "reception 1", "reception 2", and "settable" in the extraction list (S110-6).

Also, when the target person is set at random, the player information update unit 140a adds "1" to the host player's priority points in the player information storage unit 160 (S110-8). When request information is received (YES in S110-1), the server-side game control section 100A performs room setting processing for setting a room (S110-8). Here, a room (predetermined storage area) is set in the room information storage unit 166, and information relating to the host player is stored in the room based on the request information. Also, here, the server-side game control unit 100A sets the room information so that the host terminal can receive it. Further, the player information update unit 140a subtracts "4" from the priority points of the host player in the player information storage unit 160 regardless of the type of request information (S110-9).

FIG. 28 is a flowchart illustrating an example of information update processing in the server 100. FIG. When the reception confirmation information is received from the player terminal 1 (YES in S120-1), the server-side game control unit 100A searches the extraction list to see if the invitation information for this player terminal 1 is set (S120-1). 2). At this time, if the invitation information is set (YES in S120-3) and the reception status (status flag) is set to "receivable" (YES in S120-4), the server-side game control unit 100A Invitation information output processing is performed (S120-5). Here, the invitation information is set to be receivable by the player terminal 1 that has transmitted the reception confirmation information.

Also, the player information update unit 140a subtracts "4" from the target person's priority points stored in the player information storage unit 160 (S120-6). Also, the list updating unit 142a updates the number of receptions of invitation information for the player who received the invitation information (S120-7). In addition, the list updating unit 142a updates the reception status (status flag) of the target person terminal to one of "reception 1", "reception 2", and "reception 3" in the extraction list based on the updated number of receptions. .

When opening information is received from the player terminal 1 (target person terminal) (YES in S120-8), the player information update unit 140a changes the target person's priority points stored in the player information storage unit 160 to "1". Add (S120-9).

Further, when participation information is received from the player terminal 1 (target person terminal) (YES in S120-10), if it is possible to enter the room (YES in S120-11), the server-side game control unit 100A receives the room information The room information in the storage unit 166 is updated (S120-12). The server-side game control unit 100A also performs room update information output processing. Here, the server-side game control unit 100A sets the room update information so that it can be received by the host terminal and all guest terminals (including the target user terminal that transmitted the participation information) (S120-13).

On the other hand, if the room cannot be entered (NO in S120-11), the player information update unit 140a adds "4" to the priority points of the target person who sent the participation information in the player information storage unit 160 (S120-14). ). In addition, the server-side game control unit 100A sets this target person to be able to receive the participation-impossible information (S120-15).

Also, when the start information is received from the host terminal (YES in S120-16), the player information updating unit 140a adds "1" to the priority points of the host player in the player information storage unit 160 (S120-17). Then, the server-side game control section 100A executes a battle game start process for starting a multiplayer battle game (S120-18).

FIG. 29 is a flowchart illustrating an example of multiplay end processing in the server 100. FIG. In the battle game execution process (S100), if the multi-play ends normally other than midway termination (retirement) (YES in S130-1, NO in S130-2), the server-side game control unit 100A determines that the total damage dealt is 20%. % or more is specified (S130-3). In the battle game execution process (S100), the damage dealt to each player is stored in the game information storage unit 164 during execution of multiplayer.

The player information update unit 140a adds "3" to the priority points of the identified player in the player information storage unit 160 (S130-4). Also, the player information update unit 140a resets the priority points of all players whose priority points exceed the initial value to the initial value (sets to 100) at the end of the multiplay (S130-5).

FIG. 30 is a flowchart illustrating an example of rearrangement processing in the server 100. FIG. The list update unit 142a updates the priority points of the extraction list stored in the extraction list storage unit 162 to the priority points stored in the player information storage unit 160 (S140-1). Also, the list updating unit 142a performs a sorting process for changing the priority based on the priority points of the extraction list (S140-2). As a result, the player priority is updated based on the priority points.

The list update unit 142a also performs list information update processing for updating the information of the extraction list (S140-3). For example, the list updating unit 142a updates the counter value of the wait counter, and updates the status flag of the storage area whose counter value has been updated to 0 from "receivable" to "receivable". In addition, the list updating unit 142a updates the status flag of the target person who has received the invitation information from "receivable" to "receiving 1", "receiving 2", and "receiving 3". Furthermore, the list updating unit 142a updates the invitation information, the status flag, and the wait counter from the extraction list when the multiplayer ends, when the room is disbanded, or when a predetermined time has passed since the invitation information was set. .

Although one aspect of the embodiment has been described above with reference to the accompanying drawings, it goes without saying that the present invention is not limited to the above embodiment. It is obvious that a person skilled in the art can conceive of various modifications or modifications within the scope of the claims, and it is understood that these also belong to the technical scope of the present invention. be done.

The technical matters described in the above embodiments are applicable to all game fields. Therefore, for example, the display contents of the game screen on which the thumbnail image 52a and the invitation information image 54 are displayed are not particularly limited.

Further, in the above-described embodiment, a case where an invitation to participate in a multiplayer battle game has been described. That is, the invitation game of the above embodiment is executed with the player terminals 1 of each of the plurality of players connected for communication. However, the content of the invitation game in which participation is invited is not particularly limited. For example, the invitation game may be a content in which the invited player challenges the quest alone.

Further, in the above embodiment, the server 100 is provided as an external device, and a plurality of player terminals 1 can execute multiplay via the server 100, which is an external device. However, the external device is not limited to the server 100 . For example, the player terminals 1 may have the above-described functions of the server 100, and one of the player terminals 1 may function as an external device.

Further, in the above embodiment, the thumbnail image 52a is displayed as the notification image. However, the display mode of the notification image is not limited to this. It is only necessary to display a notification image corresponding to the received invitation information and capable of identifying part of the game information related to the invitation game while maintaining the display of the game screen being played. Also, when a plurality of pieces of invitation information are received, the notification image may be displayed for each piece of invitation information.

Further, in the above embodiment, when the thumbnail image 52a is tapped, the invitation information images 54 corresponding to all the invitation information are displayed. However, for example, only the invitation information image 54 corresponding to the tapped thumbnail image 52a may be displayed. Further, in the above-described embodiment, the invitation information image 54 has been described as an example of the predetermined image displayed when the operation of selecting the notification image is input. However, when the player's operation to select the notification image is input, the predetermined image includes at least game information that is more detailed than the notification image and an operation unit that accepts the operation to participate in the invitation game, and the game being played. The specific display content is not limited as long as it is displayed while the display on the screen is maintained.

Further, in the above-described embodiment, when the invitation information image 54 is displayed, the battle screen at the time of interruption is stopped and displayed while the entire display 26 is darkened. However, the display state of the game screen when the invitation information image 54 is displayed is not limited to this. For example, the game screen when the invitation information image 54 is displayed may be the same as the pause state when the game is in progress or when the operation tab 42 is tapped. In any case, the invitation information image 54 only needs to be displayed in such a way that the game screen being played can be identified.

Further, in the above-described embodiment, when the participation tab of the operation unit 54b is tapped, the processing unit 74a executes processing necessary for participating in the invited game, such as transmitting participation information. However, the processing to be executed when a participation operation is input is not limited to this. For example, the processing unit 74a may display a screen for selecting a character or party for participating in the invitation game before transmitting the participation information.

Further, in the above-described embodiment, the invitation information image 54 is hidden based on the input of the join operation, the input of the delete operation, and the hold operation. However, the operation to hide the invitation information image 54 is not limited to this. In any case, the invitation information image 54 should be hidden based on the input of a predetermined operation including at least a participation operation.

Further, in the above-described embodiment, invitation information having the same type of battle game as the invitation information stored in the state storage unit may not be received. That is, the player terminal 1 can hold a plurality of pieces of invitation information, but the pieces of invitation information that can be held at the same time may be limited to invitation games of different types. In addition, if the invitation information that can be held at the same time in the player terminal 1 is limited to those of different types of invitation games, all of the invitation information is received, and then the thumbnail image 52a and the invitation information image 54 are transferred to the It may be displayed.

In this way, if the invitation information that can be held at the same time is limited to invitation games of different types, the invitation games corresponding to the plurality of notification images are of different types.

Further, in the above-described embodiment, for example, when a plurality of pieces of invitation information having the same type of invitation game are held, only the thumbnail image 52a corresponding to any one of the plurality of pieces of invitation information is displayed. may be displayed. With this configuration, when a plurality of notification images are displayed, the invitation games corresponding to the plurality of notification images are of different types. As a result, it is possible to prevent the invitation games of the same type from being displayed, thereby increasing the player's range of selection.

In each of the above-described embodiments and various modifications, the information processing system S, which is a client-server system, performs each of the above-described information processes. However, only the player terminal 1 in the above embodiments and modifications may be provided as a game terminal device. The game terminal device is not limited to a smartphone, and may be a dedicated game device as long as it has a communication function. Also, only the server 100 in the above embodiments and modifications may be provided as a server device.

Further, the programs in each of the above embodiments and various modifications may be stored in a computer-readable storage medium and provided as the storage medium. Furthermore, it may be provided as a game terminal device or a server device including this storage medium. Further, the above-described embodiment and modifications may be an information processing method that implements each function and the steps shown in the flowchart.

1 Player terminal 52a Thumbnail image 54 Invitation information image 54a Game information display unit 54b Operation unit 60a Game execution unit 62a Battle game execution unit 68a Invitation information reception unit 70a Notification unit 72a Invitation information image display unit 74a Processing unit 100 Server

In order to solve the above problem, an information processing program can receive a plurality of pieces of invitation information for inviting participation in one of a plurality of types of invitation games from a display control unit that displays a game screen that is being played, from an external device. A receiving unit, corresponding to the received invitation information, displays a notification image capable of identifying part of the game information related to the invited game while maintaining the display of the game screen being played, and receives a plurality of pieces of invitation information. In this case, when a notification unit that displays a notification image for each invitation information and a player's operation to select a notification image are input, game information more detailed than the notification image and an operation to participate in the invited game are received. A predetermined image display unit that displays a predetermined image including at least an operation unit in a state in which the game screen being played can be identified, and a process for participating in the invitation game when a participation operation is input to the operation unit. and a processing unit that causes the computer to function, and the notification unit hides the notification image when a predetermined time elapses from the start of display of the notification image, receives invitation information, and then receives new invitation information. In this case, the notification image corresponding to the relatively earlier received invitation information is displayed in addition to the notification image corresponding to the newly received invitation information.
In order to solve the above problem, an information processing program can receive a plurality of pieces of invitation information for inviting participation in one of a plurality of types of invitation games from a display control unit that displays a game screen that is being played, from an external device. a receiving unit, a holding unit that holds the received invitation information within the range of the upper limit number, and a notification image corresponding to the received invitation information and capable of identifying part of the game information related to the invited game, on the game screen during play. , and when a plurality of pieces of invitation information are received, a notification image is displayed for each piece of invitation information; a predetermined image including at least more detailed game information and an operation unit for accepting an operation to participate in the invitation game and an operation to delete the held invitation information is displayed in a state in which the game screen being played can be identified. a predetermined image display unit, a processing unit that executes processing for participating in the invited game when a participation operation is input to the operation unit, and a deletion when a delete operation is input to the operation unit The computer is caused to function as a deletion unit that deletes the invitation information corresponding to the predetermined image including the operation unit to which the operation is input .

In order to solve the above problems, an information processing method includes steps of displaying a screen of a game being played, and receiving a plurality of pieces of invitation information for inviting participation in one of a plurality of types of invitation games from an external device. , corresponding to the received invitation information, displays a notification image that can identify a part of the game information related to the invited game while maintaining the display of the game screen being played, and when multiple pieces of invitation information are received, displaying a notification image for each piece of invitation information; and, when a player's operation for selecting a notification image is input, game information more detailed than the notification image and an operation unit for accepting an operation to participate in the invited game. a step of displaying a predetermined image including a game screen in a state in which the game screen being played can be identified; In the step of displaying the notification image, the notification image is hidden when a predetermined time has passed since the start of display of the notification image, and if new invitation information is received after the invitation information is received, the newly received invitation information is received. In addition to the notification image corresponding to the invitation information, the notification image corresponding to the invitation information received relatively earlier is displayed.
In order to solve the above problems, an information processing method includes steps of displaying a screen of a game being played, and receiving a plurality of pieces of invitation information for inviting participation in one of a plurality of types of invitation games from an external device. , a step of holding the received invitation information within the range of the upper limit number, and a notification image corresponding to the received invitation information and capable of identifying part of the game information related to the invited game, and maintaining the display of the game screen during play. a step of displaying a notification image for each piece of invitation information when a plurality of pieces of invitation information is received; a step of displaying a predetermined image including at least information and an operation unit for accepting an operation to participate in the invitation game and an operation to delete the held invitation information in a state in which the screen of the game being played can be identified; a step of executing a process for participating in the invited game when a participation operation is input to the operation unit; and deleting the invitation information corresponding to the predetermined image .

In order to solve the above problems, an information processing system is an information processing system in which a player terminal and an external device are connected for communication, and the player terminal includes a display control unit that displays a game screen during play, A receiving unit that can receive a plurality of invitation information inviting participation in any of the invited games from an external device; The game screen being played is displayed while the display is maintained, and when a plurality of pieces of invitation information are received, a notification unit that displays a notification image for each piece of invitation information and a player operation that selects the notification image are input. a predetermined image display unit that displays a predetermined image including at least game information that is more detailed than the notification image and an operation unit that accepts an operation to participate in the invited game in a state in which the game screen being played can be identified; a processing unit that executes a process for participating in the invitation game when a participation operation is input to the operation unit ; is hidden, and when new invitation information is received after receiving invitation information, in addition to the notification image corresponding to the newly received invitation information, the notification image corresponding to the invitation information received relatively earlier display.
In order to solve the above problems, an information processing system is an information processing system in which a player terminal and an external device are connected for communication, and the player terminal includes a display control unit that displays a game screen during play, a receiving unit that can receive a plurality of pieces of invitation information for inviting participation in one of the invitation games from an external device; a holding unit that holds the received invitation information within the upper limit; , Display a notification image that can identify part of the game information related to the invited game while maintaining the display of the game screen during play, and display the notification image for each invitation information when multiple invitation information is received. and an operation to receive game information more detailed than the notification image, an operation to participate in the invitation game, and an operation to delete the held invitation information when the operation of the player to select the notification image is input. a predetermined image display unit for displaying a predetermined image including at least a part in a state in which the game screen being played can be identified; and a deletion unit that, when a delete operation is input to the operation unit, deletes the invitation information corresponding to the predetermined image including the operation unit to which the delete operation has been input .

Claims (6)

a display control unit that displays the game screen being played;
a receiving unit capable of receiving a plurality of pieces of invitation information for inviting participation in one of a plurality of types of invitation games from an external device;
A notification image corresponding to the received invitation information and capable of identifying part of the game information related to the invitation game is displayed while maintaining the display of the game screen being played, and a plurality of the invitation information are received. a notification unit that displays the notification image for each of the invitation information when
When the player's operation to select the notification image is input, a predetermined image including at least the game information more detailed than the notification image and an operation unit for accepting an operation to participate in the invitation game is displayed to the player during play. a predetermined image display unit that displays the game screen in an identifiable state;
a processing unit that executes a process for participating in the invitation game when the participation operation is input to the operation unit;
An information processing program that enables a computer to function. The predetermined image display unit
hiding the predetermined image based on the input of a predetermined operation including at least the participation operation;
The information processing program according to claim 1. The invitation game is executed with player terminals of each of a plurality of players connected for communication,
The game information includes at least one of the type of the invitation game and information about participating players.
3. The information processing program according to claim 1 or 2. when a plurality of notification images are displayed, the invitation games corresponding to the plurality of notification images are of different types;
The information processing program according to any one of claims 1 to 3. displaying a screen of a game being played;
a step of receiving a plurality of pieces of invitation information for inviting participation in one of a plurality of types of invitation games from an external device;
A notification image corresponding to the received invitation information and capable of identifying part of the game information related to the invitation game is displayed while maintaining the display of the game screen being played, and a plurality of the invitation information are received. a step of displaying the notification image for each of the invitation information, if
When the player's operation to select the notification image is input, a predetermined image including at least the game information more detailed than the notification image and an operation unit for accepting an operation to participate in the invitation game is displayed to the player during play. displaying the game screen in an identifiable state;
executing a process for participating in the invitation game when the participation operation is input to the operation unit;
Information processing method including. An information processing system in which a player terminal and an external device are connected for communication,
The player terminal is
a display control unit that displays the game screen being played;
a receiving unit capable of receiving a plurality of pieces of invitation information for inviting participation in one of a plurality of types of invitation games from the external device;
A notification image corresponding to the received invitation information and capable of identifying part of the game information related to the invitation game is displayed while maintaining the display of the game screen being played, and a plurality of the invitation information are received. a notification unit that displays the notification image for each of the invitation information when
When the player's operation to select the notification image is input, a predetermined image including at least the game information more detailed than the notification image and an operation unit for accepting an operation to participate in the invitation game is displayed to the player during play. a predetermined image display unit that displays the game screen in an identifiable state;
a processing unit that executes a process for participating in the invitation game when the participation operation is input to the operation unit;
An information processing system comprising

Images